1. Dönüşüm takibi doğru çalışıyor mu, nasıl anlarım?
Kısa cevap: “Çalışıyor” demek için 3 şeyi aynı anda görmelisiniz: 1. GTM Preview’da ilgili aksiyonda doğru tag ateşlendi, 2. GA4 DebugView’da event parametreleriyle birlikte göründü, 3. Raporlarda aynı event mantıklı sayıda ve doğru kaynakla görünüyor (özellikle cross-domain/referral sapması yok). Debug akışına başlamadan önce GTM Preview ile dönüşüm hatası tespiti için gereken temel tag, trigger, variable ve conversion mantığını netleştirmek işleri hızlandırır. Çünkü SEM stratejisi içinde dönüşüm kalite kontrolü, reklam optimizasyonunun veri doğruluğu katmanıdır. Aşağıda “en kısa doğrulama” akışı var:
60 saniyelik hızlı kontrol (pazarlama ekibi için)
- •Siteyi aç → ilgili aksiyonu yap (form/rezervasyon/telefon/WhatsApp)
- •GA4 DebugView’da event’i gör → event adı doğru mu?
- •Raporlarda “kayıt var mı?” diye hemen karar verme; önce debug sırasını bitir.
5 dakikalık teknik kontrol (ajans/tech için)
- •GTM Preview: trigger + tag ateşledi mi?
- •GA4 DebugView: event + params geldi mi?
- •Tag Assistant: aynı event iki farklı tag’den gidiyor mu?
- •Cross-domain: booking engine referral olarak görünmeye devam ediyor mu?
☑ Mini Check
- • Event adı ve conversion adı “tek sözlükte” net mi?
- • Debug testini “aynı cihaz + aynı tarayıcı” ile tekrar edebiliyor musun?
- • Aynı aksiyon iki kez event üretiyor mu?
- • Rezervasyon motoru varsa referral/sesli “direct” şişmesi var mı?
Ne yapmalıyım?
- • “Önce GTM, sonra GA4” kuralını sabitle.
- • Bir test senaryosu yaz: giriş → aksiyon → doğrulama.
- • Çift sayımı ve cross-domain’i kontrol etmeden rapora güvenme.
- • Debug’u aylık ritme bağla (bakım).
2. Yaygın dönüşüm takibi hataları (en hızlı teşhis tablosu)
Bu bölüm, “hata → sebep → çözüm” ile pratik ilerler. Aşağıdaki sorunlar otel projelerinde en sık görülür: yanlış tetikleme, çift sayım, yanlış sayfa, booking engine referral, isim/parametre uyuşmazlığı. Eğer sorun tek bir event’i aşmışsa, çift sayılan dönüşüm ve benzeri hataları daha sistematik audit mantığıyla ele almak gerekir; ayrıca bot, iç trafik ve test rezervasyonları gibi kaynaklar için otellerde dönüşüm datası kalite kontrolü perspektifi şarttır.
Hata–Sebep–Çözüm Tablosu
| Belirti | Muhtemel Sebep | Hızlı Test | Kalıcı Çözüm |
|---|---|---|---|
| Dönüşüm 0 görünüyor | Tag ateşlenmiyor / yanlış trigger | GTM Preview’da aksiyonu yap | Trigger koşulunu düzelt, tek kaynak tag kullan |
| Dönüşüm iki kat sayılıyor | Double fire / iki ayrı tag gönderiyor | Tag Assistant + Preview | Tek event kuralı + dedup (event_id/transaction_id) |
| Yanlış sayfada event geliyor | Trigger çok geniş (contains vs regex) | Preview’da sayfa değiştir | URL koşulunu daralt, dataLayer event kullan |
| Booking engine referral görünüyor | Cross-domain/referral exclusion eksik | Kaynak/medium akışına bak | Cross-domain + doğru hariç tutma + test planı |
| Event adı GA4’te farklı | GTM’de yanlış event name | DebugView’de event adı | GA4 sözlüğüyle eşleştir, isim standardı koy |
| Parametreler boş | Variable yanlış / DOM’dan çekemiyor | Preview variables | DLV/DOM variable düzelt, fallback tanımla |
☑ Mini Check
- • Her dönüşüm için “tek tetikleyici” kuralı var mı?
- • Bir event birden fazla tag tarafından gönderiliyor mu?
- • Booking engine varsa referral sorunu var mı?
- • Event isim sözlüğü (naming convention) yazılı mı?
Ne yapmalıyım?
- • Önce “çift sayım” riskini kapat.
- • Sonra “0 dönüşüm” gibi kritik kesintileri çöz.
- • En son parametre kalitesi ve attribution doğruluğunu iyileştir.
- • Tabloyu ekip içi SOP (standart operasyon) yap.
Dönüşüm Hataları & Debug Checklist’ini İndir — SEM / Dönüşüm Takibi & Tag Manager (v1.0)
Bu checklist, otel dönüşüm ölçümünde en sık görülen hataları (0 kayıt, çift sayım, yanlış sayfa, referral/cross-domain sapması, isim/parametre uyumsuzluğu) standart bir debug sırası ile hızlıca yakalamanızı sağlar. Amaç, rapor güvenilirliğini artırmak ve smart bidding/optimizasyon kararlarının yanlış veriye dayanmasını engellemektir.
Kim Kullanır?
Otel pazarlama/performans ekibi + ajans + (gerektiğinde) developer.
Nasıl Kullanılır?
- Aşağıdaki checklist’i ayda 1 kez (ve her büyük site değişikliğinden sonra) uygulayın.
- Her sorun için “Preview → DebugView → Tag Assistant” sırasını izleyin.
- Düzeltme sonrası “3 adımlı test senaryosu” ile doğrulayıp kayıt altına alın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Dönüşüm sözlüğü güncel mi? (event adları + conversion seti)
- ▢ ✅ GTM Preview’da kritik aksiyonlarda doğru tag ateşliyor mu?
- ▢ ✅ GA4 DebugView’da event’ler parametreleriyle görünüyor mu?
- ▢ ✅ Aynı aksiyon “tek sefer” mi sayılıyor? (double fire yok)
- ▢ ✅ Yanlış sayfada event çalışıyor mu? (trigger dar mı?)
- ▢ ✅ Tag Assistant’ta çakışan tag/container var mı?
- ▢ ✅ Cross-domain/referral sapması var mı (booking engine)?
- ▢ ✅ Parametre mapping’i doğru mu (placement/page_type vb.)
- ▢ ✅ Değişiklik sonrası QA notu/kanıtı alındı mı?
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
3. GTM Preview/Debug Mode nasıl kullanılır? (adım adım)
GTM Preview, “hangi tag neden ateşlendi?” sorusunun tek doğru yeridir. Pazarlama ekibi için basit kural: Raporlara bakmadan önce Preview’a bak. Teknik ekip için de kural: Her değişiklik Preview testinden geçmeden yayın yok. Özellikle buton class değişimi, form submit yapısı, SPA/Ajax davranışı veya script yüklenme sırası gibi sorunlarda kök neden çoğu zaman web sitesi teknik yapısında dönüşüm takibi sorunları tarafına uzanır.
Adım adım GTM Preview (pratik)
- GTM’de Preview’a bas → site URL’ini gir → bağlan
- Test senaryosunu uygula: ör. “form gönder” / “rezervasyona git” / “telefon tıkla”
- Sol panelde event akışında doğru noktayı seç (click, form submit, page view)
- Sağ panelde: • Tags Fired: Ateşlenen tag’ler • Tags Not Fired: Ateşlenmeyen (neden?) • Variables: koşulları sağlayan değişken değerleri
- Sorunu bul: “hangi koşul yanlış?” veya “hangi tag fazla ateşliyor?”
En sık yapılan 4 Preview hatası
- •Aynı anda birden çok tab/test akışı açmak (veri karışır)
- •SPA sitelerde route değişimini page_view sanmak
- •“Just Links” yerine “All Elements” ile fazla tetiklemek
- •Debug’da gördüğünü yayına almadan önce “başka bir cihazda” tekrar test etmemek
☑ Mini Check
- • Test senaryosu yazılı mı? (3 satır yeter)
- • Tag ateşlenmesi “tek sefer” mi?
- • Trigger koşulu “dar” mı (gereksiz sayfalarda çalışmıyor)?
- • Preview sonucu ekran görüntüsü / kısa not alındı mı?
Ne yapmalıyım?
- • Her dönüşüm için 1 test adımı + 1 beklenen sonuç yaz.
- • Trigger’ı daralt (URL/selector).
- • Double fire görürsen “önce bunu kapat”.
- • Yayın öncesi QA: farklı cihaz + farklı tarayıcı ile tekrar et.
4. GA4 DebugView ile event’ler nasıl kontrol edilir?
Preview “ateşleme”yi gösterir; DebugView ise event’in GA4’e “ulaştığını” ve hangi parametrelerle geldiğini gösterir. İkisini birlikte kullanmazsanız, “tag ateşledi ama GA4’e düşmedi” gibi vakaları kaçırırsınız.
DebugView’da neye bakmalıyım?
- •Event adı (tam yazım)
- •Parametreler (özellikle conversion için kritik olanlar)
- •Aynı event’in ardışık iki kez gelip gelmediği (double fire sinyali)
Pazarlama ekibi için “minimum doğru” kontrol
- •Event adı doğru mu? (örn. purchase, booking_complete, form_submit)
- •Event sayısı mantıklı mı? (tek işlemde tek event)
- •Kaynak/medium testinde garip sıçrama var mı? (özellikle booking engine)
☑ Mini Check
- • DebugView’da event’i görüyor musun?
- • Event parametreleri boş mu/dolu mu?
- • Aynı aksiyonda iki event var mı?
- • Debug testinde “tek kullanıcı” kuralına uyuldu mu?
Ne yapmalıyım?
- • Preview’da ateşleyen tag’i bul.
- • DebugView’da event’i doğrula.
- • Parametreler boşsa variable mapping’i düzelt.
- • Double fire varsa trigger ve tag sayısını azalt.
5. Tag Assistant ve Chrome DevTools ile kontrol (ileri teşhis)
Bazı hatalar Preview + DebugView ile görülür; bazıları ise tarayıcı katmanında (network, console, storage) daha net anlaşılır. Bu bölüm, “geliştirici gibi konuşmadan” pratik kullanım verir.
Tag Assistant ne zaman gerekir?
- •Aynı sayfada birden fazla ölçüm tag’i var mı?
- •Farklı container/ID’ler çakışıyor mu?
- •Platform tag’leri beklenmedik şekilde iki kez mi çalışıyor?
DevTools ile 3 pratik kontrol
- Network: event isteği gidiyor mu? (GA4 endpoint/collect çağrıları)
- Console: hata var mı? (özellikle custom script/dataLayer)
- Storage/Cookies: cross-domain ve ölçüm kimliği davranışı tutarlı mı?
☑ Mini Check
- • Aynı anda iki ayrı ölçüm sistemi/ID var mı?
- • Network’te event çağrısı görünüyor mu?
- • Console’da tekrar eden hata var mı?
- • Cross-domain geçişinde “kaynak” bozuluyor mu?
Ne yapmalıyım?
- • Önce tag çakışmasını temizle (tek kaynak gerçeği).
- • Network’te event çağrısını görmeden “çalışıyor” deme.
- • Console hatalarını kapat (sessiz hatalar ölçümü bozar).
- • DevTools bulgularını ekip SOP’una ekle.
6. Yanlış event isimleri ve parametreler (GA4 sözlüğü kuralları)
Dönüşüm takibinde “isim ve parametre standardı” yoksa, ekip büyüdükçe raporlar parçalanır: aynı şey 3 farklı isimle ölçülür, conversion seti şişer, optimizasyon sinyali bozulur.
Otel için önerilen naming convention
- •click_to_call
- •click_whatsapp
- •form_submit
- •booking_start
- •booking_complete veya purchase (tekini seç)
Parametre standardı (minimum):
- •placement (header/footer/sticky/room)
- •page_type (home/room/offer/blog)
- •language (çok dilli yapı varsa)
- •Rezervasyon tamamlandıysa: transaction_id, value, currency (varsa)
En sık parametre hataları
- •DOM’dan çekilen değerler boş geliyor (selector kırılmış)
- •Variable mapping yanlış (DLV yerine yanlış değişken)
- •Aynı parametre farklı isimle gönderiliyor (rapor parçalanır)
☑ Mini Check
- • Event sözlüğü tek sayfa doküman mı?
- • Conversion seti “az ama güçlü” mü?
- • Parametre isimleri tutarlı mı?
- • Selector/variable değişince QA tetikleniyor mu?
Ne yapmalıyım?
- • Event sözlüğünü kilitle (1 sayfa).
- • Conversion setini sade tut.
- • Parametreleri “raporda işine yarayan kadar” kullan.
- • Her site güncellemesinden sonra mini QA koş (10 dk).
7. Cross-domain ve referral sorunları (otel rezervasyon motoru vakası)
Otel projelerinde en sık görülen “attribution bozulması” kaynaklarından biri, rezervasyon motorunun ayrı domain/subdomain olmasıdır. Sonuç: booking engine domain’i referral gibi görünür, direct/other şişer, kampanya kredisi kayar. Bu tür sapmalar yalnız medya raporunu değil, hatalı dönüşüm verisini satış raporundan ayıklamak ihtiyacını da doğurur; sorun çözüldüğünde ise temiz dönüşüm verisiyle veri analizi yapmak çok daha anlamlı hale gelir.
Bu sorunu nasıl fark edersin?
- •Dönüşümlerin büyük kısmı “direct” görünmeye başlar
- •“Referral” raporunda booking engine domain’i üst sıralara çıkar
- •Kampanya performansı ile back-office rezervasyon raporu tutarsızlaşır
Debug yaklaşımı (saha pratiği)
- •Önce “booking_complete” event’i tekil mi kontrol et (double fire?)
- •Sonra cross-domain geçişte oturum bölünüyor mu bak
- •Sonra referral kaynaklı sapmayı düzeltmek için ölçüm mimarisini güncelle
☑ Mini Check
- • Booking engine referral olarak görünüyor mu?
- • Oturum bölünmesi var mı?
- • Rezervasyon event’i tekil mi?
- • Düzeltme sonrası tekrar test yapıldı mı?
Ne yapmalıyım?
- • Önce double fire’ı kapat.
- • Sonra cross-domain geçişi test et.
- • Referral sapmasını düzelt.
- • Her değişiklikte “3 adımlı test”i tekrarla (Preview → DebugView → rapor).
Kapanış – Debug bir “ritim”dir, tek seferlik iş değildir
GA4 ve GTM arayüzleri, tarayıcı davranışları ve site kodu zamanla değişir. Bu yüzden debug’ü “ayda 1 bakım” gibi konumlandırın: 30–60 dakikalık rutin, yıl boyunca binlerce TL/€ bütçe hatasını engeller.
8. Sonuç: Debug kültürü olmadan dönüşüm verisine güvenmek zordur
GA4 DebugView, GTM Preview ve teknik kontrol akışını düzenli işletmek; yalnızca hatayı bulmak için değil, reklam optimizasyonunun sağlıklı çalışması için de gereklidir. Eğer bu yapıyı daha sistemli kurmak istiyorsanız oteller için dönüşüm takibi ve Tag Manager kurulumu sayfasından genel çerçeveyi inceleyebilir, karar aşamasında ise dönüşüm takibi ve Tag Manager hakkında sık sorulan sorular bölümüne geçebilirsiniz.
En iyi sonuç, debug’ü tek seferlik bir kriz çözümü değil; aylık kalite kontrol ritmi olarak konumlandırdığınızda gelir. Böylece eksik, fazla veya yanlış ölçülen dönüşümler kampanya kararlarını geç bozmadan yakalanır.
Bir Sonraki Adım
Yanlış/eksik/çift sayılan dönüşümler yaşayan oteller ve ajans ekipleri için, hatayı hızlıca bulup kalıcı düzeltme planı çıkarır.
Sık Sorulan Sorular
Dönüşüm hataları nasıl tespit edilir?▾
Tag Manager debug modu nasıl kullanılır?▾
GA4 DebugView ile event’ler nasıl kontrol edilir?▾
Çift sayılan dönüşümler nasıl tespit edilir?▾
Booking engine referral olarak görünüyor, ne yapmalıyım?▾
Yanlış event isimleri neden problem yaratır?▾
Debug’u ne sıklıkla yapmalıyım?▾
İlgili İçerikler
- → Tag Manager debug
- → SEM stratejisi içinde dönüşüm kalite kontrolü
- → GTM Preview ile dönüşüm hatası tespiti
- → çift sayılan dönüşüm
- → otellerde dönüşüm datası kalite kontrolü
- → web sitesi teknik yapısında dönüşüm takibi sorunları
- → hatalı dönüşüm verisini satış raporundan ayıklamak
- → temiz dönüşüm verisiyle veri analizi yapmak
- → dönüşüm takibi ve Tag Manager hakkında sık sorulan sorular
İlgili Yazılar