1. Dönüşüm takibi projelerinde en sık 10 hata
Net liste
- Yanlış/eksik scope belirleme
- Measurement plan olmadan başlamak
- Dev ve pazarlama ekibinin ayrı çalışması
- Naming standardı olmadan event üretmek
- GA4’te event–conversion ilişkisinin kurulmaması
- Test ortamı ile prod ortamını karıştırmak
- Test/debug sürecini atlamak (Preview/DebugView yok)
- Cross-domain/referral sorunlarını yok saymak
- Canlıya alındıktan sonra takibi bırakmak (bakım yok)
- Dokümantasyon bırakmamak (proje hafızası yok)
Teknik not (sheet ile uyumlu): Başlangıçta biraz daha fazla zaman alan planlama ve test adımları, uzun vadede yeniden iş yükü ve yanlış veri maliyetini önemli ölçüde düşürür.
| Hata | Etki | Kontrol | Çözüm |
|---|---|---|---|
| Yanlış/eksik scope | Proje büyür, beklentiler dağılır | Scope tek sayfa mı? | Kickoff’ta scope onayı + change request akışı |
| Measurement plan yok | Çok event, az anlam | Hedef–KPI–event haritası var mı? | Measurement plan + event sözlüğü kilitle |
| Dev–pazarlama kopukluğu | Yanlış payload, eksik parametre | Ortak sözlük ve owner var mı? | DataLayer + event dictionary + onay akışı |
| Test/debug atlandı | 0 dönüşüm / double counting / yanlış tetik | Preview ve DebugView kanıtı var mı? | QA checklist + kanıt paketi |
| Cross-domain/referral göz ardı edildi | Oturum kırılır, funnel bozulur | Booking engine ayrı domain mi? | Cross-domain ve referral exclusion kontrolü |
| Dokümantasyon yok | Proje hafızası kaybolur, yeniden iş artar | Tek kaynak gerçek doküman var mı? | Measurement plan + QA paketi + versiyon notları |
| Bakım ritmi yok | Site değişince ölçüm bozulur | Aylık bakım takvimi var mı? | 30 gün izleme + aylık bakım SOP |
Mini Check
- • Projede scope dokümanı var mı?
- • Measurement plan onaylı mı?
- • Test planı ve QA kanıtı var mı?
- • Dokümantasyon teslim edildi mi?
Ne yapmalıyım?
- • İlk 10 hatayı “kickoff checklist” yap.
- • Projeyi teknik değil “süreç” olarak yönet: onay, QA, doküman.
- • Canlı sonrası bakım ritmini planla (aylık).
- • Tek kaynak gerçek doküman oluştur (measurement plan + event sözlüğü).
2. Hata 1 — Yanlış veya eksik scope belirleme
Scope; “ne ölçülecek, hangi platformlara gidecek, hangi ortamlarda test edilecek, kim sorumlu?” sorularının cevabıdır. Scope net değilse proje büyür, iş dağılır, herkes farklı şey bekler.
Tipik scope hataları
- •“Sadece GA4 kuralım” denir; Ads, Meta, call tracking sonra istenir
- •Rezervasyon motoru ayrı domain olduğu unutulur
- •Telefon/WhatsApp kapanışı işin dışına itilir
- •Staging/prod ayrımı planlanmaz
Çözüm: Scope’u 1 sayfa “kilitle”
Scope dokümanında şu satırlar zorunlu olsun:
- •Macro conversions (rezervasyon, form, lead)
- •Micro events (funnel teşhis)
- •Platformlar (GA4, Ads, Meta vb.)
- •Ortamlar (staging/prod)
- •Teslimatlar (doküman, test kanıtı, versiyon notu)
Mini Check
- • Scope tek sayfada yazılı mı?
- • Rezervasyon motoru ve call center scope’ta mı?
- • Staging/prod ayrımı scope’ta var mı?
- • Teslimat listesi net mi?
Ne yapmalıyım?
- • Scope’u yazmadan kurulum sprint’ine başlamayın.
- • “Sonradan ekleme” isteklerini change request olarak yönetin.
- • Scope’u measurement plan ile bağlayın.
- • Ajans–otel onayını kayıt altına alın.
3. Hata 2 — Measurement plan olmadan başlamak
Measurement plan olmadan başlayan projeler, genelde “çok event, az anlam” üretir. Çünkü hedef–KPI–event ilişkisi net değildir; herkes kendi ihtiyacına göre event ister, rapor parçalanır.
Belirti
- •“Bu event neyi ölçüyor?” sorusuna kimse net cevap veremez
- •Conversion seti şişer
- •Funnel raporları tutarsızlaşır
Çözüm
- •Hedef–KPI–event–sayfa tablosu
- •Event sözlüğü (naming)
- •Test planı (Preview → DebugView → rapor)
Bu içerik, measurement plan blogu ile birlikte “proje başlangıç ritüeli” olarak okunmalı.
Mini Check
- • Hedef–KPI–event haritası var mı?
- • Macro conversion seti 2–5 aralığında mı?
- • Mikro event’ler teşhis amaçlı mı?
- • Event sözlüğü kilitli mi?
Ne yapmalıyım?
- • Measurement plan olmadan yeni event eklemeyin.
- • Event sözlüğünü tek kaynak gerçek yapın.
- • Conversion setini sade tutun.
- • Ölçüm planını 365 gün refresh ile güncelleyin.
4. Hata 3 — Dev ve pazarlama ekibinin ayrı çalışması
En sık yaşanan problem: pazarlama “şunu ölçelim” der, dev “bunu yaptım” der, ama ikisi aynı şeyi kastetmez. Sonuç: yanlış tetiklenen event, eksik parametre, raporda anlamsızlık.
Çözüm: Ortak sözlük + brif
- •DataLayer sözlüğü (alan adı–kaynak–format)
- •Event sözlüğü (event adı–tetik–parametre)
- •Sahiplik (owner): kim sorumlu, kim onaylar?
Mini örnek
- •Pazarlama: “rezervasyon geliri ölçülsün”
- •Dev: “booking_complete var”
- •Eksik: value/currency/transaction_id yok → gelir ölçümü aslında yok
Mini Check
- • DataLayer sözlüğü var mı?
- • Event isimleri ve parametreler brif’te yazıyor mu?
- • Owner ve onay mekanizması var mı?
- • Bir değişiklik olduğunda change log tutuluyor mu?
Ne yapmalıyım?
- • Dev–marketing alignment dokümanı oluştur (tek sayfa).
- • Her event için “beklenen payload”ı yaz.
- • Değişiklikleri versiyonla ve test kanıtı ekle.
- • Haftalık 15 dk “ölçüm sync” toplantısı koy (projede).
5. Hata 4 — Test ve debug sürecinin atlanması
Kurulum “yayına alındı” demek, doğru çalışıyor demek değildir. Debug atlanınca şu olur:
- •Tag ateşlenmez (0 dönüşüm)
- •İki kez ateşler (double counting)
- •Yanlış sayfada çalışır
- •Cross-domain/referral bozulur
Minimum debug sırası (kural)
- GTM Preview: tag/trigger doğru mu?
- GA4 DebugView: event + parametre geliyor mu?
- Rapor tutarlılığı: 24–72 saat izleme
Çözüm: QA checklist + kanıt
Her kritik event için 3 test senaryosu + screenshot kanıtı. Bu, proje sonunda “kanıt paketi” olarak teslim edilir.
Mini Check
- • Preview ekran kanıtı var mı?
- • DebugView kanıtı var mı?
- • Double-fire kontrol edildi mi?
- • Publish sonrası izleme yapıldı mı?
Ne yapmalıyım?
- • Debug’u opsiyon değil “giriş şartı” yapın.
- • Kritik event’ler için test senaryosu yazın.
- • Yayın sonrası izleme olmadan “tamamlandı” demeyin.
- • Debug rehberini SOP’a bağlayın (aylık bakım).
6. Hata 5 — Canlıya alındıktan sonra takibi bırakmak & dokümantasyon eksikliği
Otel sitesi değişir, rezervasyon motoru güncellenir, kampanyalar değişir. Bu yüzden ölçüm “bakım ister”. Dokümantasyon yoksa yeni ekip geldiğinde her şey yeniden keşfedilir ve risk artar.
Çözüm: “Kurulum sonrası bakım” paketini standartlaştır
- •Aylık: data hygiene + debug kontrol
- •Çeyreklik: event sözlüğü temizlik/önceliklendirme
- •Yıllık: measurement plan revizyonu (365)
Proje sonunda bırakılması gereken dokümanlar (minimum)
- •Measurement plan v1.0
- •Event + dataLayer sözlüğü
- •QA kanıt paketi (test senaryoları + screenshot)
- •GTM versiyon notları + rollback playbook
- •Rapor okuma rehberi (kısa)
Mini Check
- • Kurulum sonrası bakım ritmi var mı?
- • Dokümanlar tek yerde mi ve güncel mi?
- • Yeni ekip geldiğinde “tek kaynak gerçek” ne?
- • 365 refresh kuralı işletiliyor mu?
Ne yapmalıyım?
- • Proje teslimini “doküman + kanıt” olmadan kabul etmeyin.
- • Aylık bakım ritmini takvime bağlayın.
- • Değişiklikleri change log ile izleyin.
- • Ekip yapısı değiştikçe checklist’i güncelleyin.
7. Dönüşüm Takibi Proje Sağlık Kontrol Listesi (hızlı kontrol)
- •Scope tek sayfa mı?
- •Measurement plan var mı?
- •Event/dataLayer sözlüğü kilitli mi?
- •Staging/prod ayrımı net mi?
- •Debug kanıtı var mı?
- •GTM versiyon notu/rollback var mı?
- •Rapor okuma rehberi var mı?
- •Aylık bakım planı var mı?
8. Dönüşüm Takibi Proje Checklist & Template’ini İndir
Dönüşüm Takibi Proje Checklist & Template’ini İndir — SEM / Project Governance (v1.0)
Bu checklist, otel dönüşüm takibi projelerinde en sık yapılan süreç hatalarını proje başında yakalamak ve kurulum sonrası “yeniden iş” maliyetini azaltmak için tasarlanmıştır. Scope, measurement plan, dev–marketing hizalaması, test/QA ve dokümantasyon adımlarını tek dokümanda kilitleyerek projenin dağılmasını önler.
Kim Kullanır?
Otel pazarlama yöneticisi + ajans proje/performance lideri + developer/QA (ortak kontrol dokümanı).
Nasıl Kullanılır?
- Kickoff’ta checklist’i birlikte doldurun ve scope’u onaylatın.
- Kurulum sprint’i boyunca test kanıtlarını ve versiyon notlarını ekleyin.
- Go-live sonrası 30 gün izleme + aylık bakım ritmini plana bağlayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Ölçüm & Önceliklendirme checklist’i (Kickoff)
- ▢ ✅ Measurement plan: hedef–KPI–event–sayfa haritası hazır ve onaylı
- ▢ ✅ Makro conversion seti 2–5 aralığında kilitlendi
- ▢ ✅ Mikro event seti teşhis için seçildi (10–20 aralığı)
- ▢ ✅ Dev–pazarlama ortak sözlüğü: dataLayer + event dictionary hazır
- ▢ ✅ Staging/prod ayrımı net (property/stream/etiket)
- ▢ ✅ Naming standardı (tag/trigger/event/parametre) kilitli
- ▢ ✅ Test planı (Preview → DebugView → rapor) yazılı
- ▢ ✅ Sorumluluk matrisi: kim uygular, kim onaylar, kim publish eder
- ▢ ✅ Dokümantasyon teslim kriteri tanımlı (proje kapanış şartı)
- ▢ ✅ 14 günlük sprint planı (Gün 1–14)
- ▢ ✅ Deliverables listesi (Proje kapanış paketi)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
9. Kapanış – En büyük hatalar genelde süreçten çıkar
Dönüşüm takibinde teknik hatalar düzeltilebilir; ama süreç hataları tekrar tekrar aynı problemi üretir. Scope, measurement plan, QA ve dokümantasyon disiplinini kurduğunuzda, proje hem daha hızlı ilerler hem daha doğru ölçer.
Bir Sonraki Adım
Süreç kaynaklı ölçüm sorunlarını tespit edip projeyi toparlamak isteyen oteller ve ajans ekipleri için.
Sık Sorulan Sorular
Dönüşüm takibi projelerinde en sık yapılan hatalar nelerdir?▾
Measurement plan olmadan kurulum yapmak neden riskli?▾
Test süreci nasıl kurgulanmalı?▾
Dokümantasyon neden bu kadar önemli?▾
Test ortamı ile prod ortam karışırsa ne olur?▾
Dev ve pazarlama ekibi nasıl hizalanmalı?▾
Proje canlıya alındıktan sonra ne yapılmalı?▾
İlgili İçerikler