Ana sayfa / Rehberler

DebugView hiçbir şey göstermediğinde GA4 ayıklama

Debug akışı neden boş kalır, bir /g/collect isteği gerçekte ne taşır ve debug modunu açmadan canlı sitede GA4 nasıl doğrulanır.

Yayınlandı 10 Ağustos 2026

Google bu iş için DebugView'ı veriyor ve çalıştığında doğru cevap odur: baktığınız mülkte GA4'ün işleyip aldığı veriyi gösterir. Sorun, site event'leri gayet düzgün gönderirken DebugView'ın hiçbir şey göstermemesinin kaç ayrı yolu olduğu.

DebugView neyi gösterir, neyi gösteremez

DebugView; tek bir mülkte, debug modu açık tek bir cihazın, Google veriyi kabul ettikten sonraki görünümü. Hem değerini hem sınırlarını bu cümle açıklıyor.

• Event'in ulaştığını doğrular. Tarayıcı tarafında hiçbir şey bunu söyleyemez.
• Yalnızca GA4'ü gösterir. Sayfadaki Meta, TikTok, LinkedIn, Criteo ve diğerleri görünmez.
• Debug modu ister; bu da onu bir hazırlık ortamı aracı yapar. Kontrol etmediğiniz canlı bir ödeme akışına ya da müşteri sitesine, önce o siteyi değiştirmeden yöneltemezsiniz.
• Gönderileni değil, alınanı gösterir. İkisi ayrıştığında — uzun olduğu için düşen bir parametre, sunucu container'ının yeniden adlandırdığı bir event — DebugView ikincisini gösterir, birincisini gizler.

Akış neden boş kalır

Kabaca sebep çıkma sıklığına göre:

1. Debug modu aslında açık değildir. GTM Preview açar, GA Debugger eklentisi açar, config'teki debug_mode parametresi açar. Başka hiçbir şey açmaz; başka bir sekmede süresi dolan Preview oturumu da hiçbir şey söylemeden kapatır.
2. Yanlış mülke bakıyorsunuzdur. Sayfa bir ölçüm kimliğine gönderiyor, DebugView başkasında açık. Hazırlık ve canlı mülkün birlikte bulunduğu her yerde sık görülür.
3. Consent Mode depolamayı reddediyordur. İstekler çerezsiz ping olarak yine çıkar ama DebugView'ın dayandığı cihaz tanımlaması zayıflar ve cihaz listede hiç görünmeyebilir.
4. İsteği bir şey durdurmuştur. İçerik engelleyici, kurumsal proxy ya da www.google-analytics.com'a izin vermeyen bir Content Security Policy. Tag çalıştı; çıkan olmadı.
5. Araya giren bir sunucu container'ı. Server-side GTM'de client yanlış yapılandırıldıysa istekler kendi uç noktanıza ulaşıp orada kalır; bu da tıpkı tag'in hiç ateşlenmemesi gibi görünür.

İlk üçünü Google'ın kendi arayüzlerinden eleyebilirsiniz. Son ikisini eleyemezsiniz — GA4 henüz hiçbir şey görmeden önce olurlar ve istek düzeyinde bir görünümün tek tanık olduğu yer tam olarak burasıdır.

Bir /g/collect isteğini okumak

Her GA4 event'i /g/collect'e giden bir istektir ve event'in tamamı sorgu dizesindedir. Bunu okuyabildiğinizde ne gönderildiğini bilmek için debug moduna ihtiyacınız kalmaz:

• tid — ölçüm kimliği. Veri yanlış mülke düşüyorsa önce buraya bakın.
• en — event adı, GA4'ün saklayacağı haliyle.
• ep.<ad> metin, epn.<ad> sayısal event parametresidir. Sayı olması gereken bir değerin ep.value olarak gelmesi gerçek ve sık bir hatadır.
• up.<ad> ve upn.<ad> — kullanıcı özellikleri.
• cid istemci kimliği, sid oturum kimliği. İki sayfa arasında değişen bir cid, tek kişinin iki kişi sayılması demektir.
• _p ve _s — sayfa yüklenme kimliği ve o yükleme içindeki istek sayacı. Hiç ulaşmamış bir isteği _s dizisindeki boşluktan yakalarsınız.
• dl, dr, dt — adres, yönlendiren, başlık.
• _et — milisaniye cinsinden etkileşim süresi.
• gcs ve gcd — isteğin gönderildiği andaki izin durumu.
• _dbg — debug modu açık. Yokluğu, "DebugView neden boş" sorusunun en hızlı cevabıdır.
• cu ve pr1, pr2… — para birimi ve e-ticaret ürünleri; her ürün id, nm, pr, qt gibi alanlarla tek bir parametreye paketlenir. Üç ürünlük sepetin bir ürünle gittiğini pr parametrelerini sayarak görürsünüz.

Sıra neden bozuk görünüyor

GA4 her event için ayrı istek göndermez. Arka arkaya ateşlenen event'ler gruplanır ve grup, GET yerine gövdesinde her satırda bir event olan bir POST olarak çıkar. Sayfadan ayrılırken taşıma sendBeacon'a geçer. Yani istek zaman çizelgesi ile event zaman çizelgesi aynı şey değildir: bir purchase, ağ kaydında kendisinden sonra gerçekleşen bir sayfa görüntülemeden sonra belirebilir.

Event'leri sebeplerine varış zamanına göre eşlemek bu yüzden yanlış cevap verir; eşleme event adı ve içerikle yapılmak zorundadır.

DebugView'ın gösteremeyeceği hata

GA4'ün en pahalı hataları eksik event'ler değildir. Sağlıklı görünüp yanlış içerik taşıyan event'lerdir. dataLayer üç ürün ve 1648,25 TRY push etti; tag bir ürün ve para birimi olmadan gönderdi. DebugView size o tek ürünü gösterir ve düzgün görünür, çünkü DebugView sayfanın ne yapmak istediğini bilmez.

Bu hata sınıfını bulmak iki yarıyı yan yana koymayı gerektirir: site ne push etti ve tarayıcıdan gerçekte ne çıktı. Bu eklenti tam olarak bu karşılaştırma için var.

Canlıda işleyen bir rutin

1. Paneli açıp sayfayı yenileyin. Debug modu açık olsun olmasın her GA4 isteği görünür.
2. İlk isteğin tid'ine bakın. Yanlış mülk, bulunması en ucuz ve gözden kaçması en kolay hatadır.
3. Hunide ilerleyin. _s'nin boşluksuz arttığını ve cid'in sabit kaldığını izleyin.
4. Dönüşümde push ile isteği karşılaştırın: ürün sayısı, tutar, para birimi, sipariş kimliği.
5. Bir istek eksikse tag'in hiç ateşlenip ateşlenmediğini belirleyin. Hiç çalışmamış bir tag ile engellenmiş bir istek raporda birbirinin aynısı, burada tamamen farklı görünür.

DebugView'ın hâlâ doğru araç olduğu yer

Soru "Google veriyi kabul etti mi" olduğunda onu kullanın. İstekler tarayıcıdan düzgün çıkıyor ama raporlar hâlâ uyuşmuyorsa sorun çizginin Google tarafındadır — bir dahili trafik filtresi, veri akışı yapılandırması, raporlama kimliği ayarı — ve hiçbir tarayıcı aracı bunları göremez. İki görünüm farklı sorulara cevap verir; inatçı bir sorun genelde ikisini birden ister.

İlgili rehberler

• Meta Pixel ve CAPI: satışlar neden iki kez sayılıyor
• Preview modu olmadan GTM ayıklama
• TikTok, Snap, UET ve beş platform için Test Events