Ana sayfa / GA4 debugger

İsteği gösteren GA4 debugger

GA4'ün DebugView'ı var. Sahibi olduğunuz bir mülkte, debug mode açıkken, Google Analytics'in aldığını gösteriyor. Hatalar o noktadan öncesinde yaşıyor.

DebugView bir rapor. Event'leri GA4 onları aldıktan ve işledikten sonra, erişiminiz olan bir mülk için ve yalnızca oturum debug olarak işaretliyken gösteriyor. Bu onu tek bir soru için doğru araç yapıyor — GA4 bunu kabul etti mi — ve insanların genelde sorduğu soru için yanlış araç: tarayıcı aslında ne gönderdi.

Tag Master doğrudan /g/collect'i okuyor. Her parametre, çıktığı sırayla, herhangi bir sayfada, debug mode olmadan ve mülk erişimi olmadan.

DebugView'ın gösteremedikleri

• GA4 dokunmadan önceki istek. Sınırı aşan parametreler, hiç tanımlanmamış özel boyutlar, kırpılan değerler — GA4 bunları sessizce düşürür ve DebugView size hayatta kalanı gösterir. Gönderilip atılanı göstermez.
• Debug mode olmadan hiçbir şey. DebugView oturumun işaretlenmesini ister; bu da bir eklenti, GTM preview ya da debug_mode: true demek. O işaret sayfanın davranışını değiştirir ve gerçek trafiğiniz böyle ölçülmez.
• Sahibi olmadığınız mülkler. Rakip yok, sözleşme öncesi müşteri yok, devralmak üzere olduğunuz bir siteye hızlı bakış yok.
• Sayfadaki diğer her şey. GA4 kılığındaki bir hata çoğu zaman aynı pantolonu giymiş bir Meta ya da TikTok sorunudur — paylaşılan bir dataLayer anahtarı, ikisini birden vuran bir consent kapısı.

Onun yerine gördükleriniz

Çözülmüş isteğin kendisi: event adı, metin ve sayısal biçimlerine ayrılmış event parametreleri, istemci ve oturum kimlikleri, gönderildiği hâliyle sayfa adresi ve referrer, yanında giden consent sinyali ve isteğin kendi partisinin ilki olup olmadığını söyleyen sıra numarası.

Ecommerce ürünleri, açılmış hâlde

GA4 ürün dizisini sıkışık, konuma dayalı bir biçimde paketler — pr1, pr2, her biri iki harfli anahtarlardan oluşan bir dizi. Teknik olarak okunabilir ve kimse okumaz. Panel her ürünü alanlarına geri açar; böylece eksik bir ürün kimliği ya da sıfır adet, elle çözmek yerine bir bakışta görünür.

Çoğu ecommerce raporlama sorunu buradan çıkar: çalışmayan bir tag değil, bir sayfa geride kalmış bir dataLayer'dan kurulmuş ürün dizisiyle çalışan bir tag. DebugView ile uzun karşılaştırma her birinin neye yaradığını tek tek işliyor.

Her istekte consent

Consent Mode altında reddedilmiş bir istek yine de çıkar; işaretlenmiş olarak çıkar. "İstek yok" ile "Google'a bunu reklam için kullanma diyen bir istek" arasındaki fark DebugView'da görünmez ve biri neden dönüşümler düştü diye sorduğunda belirleyicidir. Her istek kendi consent durumunu taşır ve bu durum tek başına değil, default-sonra-update sırasının yanında okunur.

DebugView'ın hâlâ kazandığı yer

GA4'ün isteği aldıktan sonra yaptığı her şey. Event doğru oturuma atfedildi mi, bir kullanıcı özelliği tuttu mu, bir kitle eşleşti mi, tanımladığınız bir özel boyutu GA4 kabul etti mi — bunların hepsi Google tarafında olur ve hiçbir tarayıcı eklentisi göremez. Önce isteği gönderin, sonra vardığını doğrulayın. İki yarı, iki ayrı araç.

Sorular

DebugView olmadan GA4 debug edebilir miyim?

GA4 isteği alana kadarki her şey için evet. /g/collect isteğini okumak; event adını, parametreleri, kimlikleri ve consent sinyalini tarayıcının gönderdiği hâliyle gösterir, debug mode ve mülk erişimi gerekmeden.

debug_mode ya da GA Debugger eklentisi gerekiyor mu?

Hayır. Onlar oturumu DebugView göstersin diye işaretlemek için var. Ağı okumak ikisini de istemez; bu aynı zamanda sayfanın gerçek trafikteki gibi davranması demek.

Ecommerce ürünlerini çözüyor mu?

Evet. GA4 ürünleri sıkışık, konuma dayalı bir biçimde gönderir; panel her birini alanlarına geri açar, böylece eksik bir ürün kimliği ya da sıfır adet elle çözmeden görünür.

Her isteğin Consent Mode durumunu gösteriyor mu?

Evet. Her istek kendi consent sinyalini taşır ve default-sonra-update sırasının yanında gösterilir — reddedilmiş bir isteği hiç olmamış bir istekten böyle ayırırsınız.

DebugView'ın yerini tutar mı?

Hayır, öyle bir iddiası da yok. GA4'ün isteği aldıktan sonra ne yaptığının tek görünümü DebugView: oturum atfı, kullanıcı özellikleri, kitleler. Bu ise tarayıcının ne gönderdiğini gösteriyor. Çoğu hata ayıklama ikisini de, bu sırayla ister.

Rehberler

İnsanları yanıltan kısımların uzun hâli.

• 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.
• Consent Mode V2 ayıklama: gcs, gcd ve kimsenin yakalamadığı ihlaller — İzin parametrelerini doğrudan isteklerden okuyun, varsayılanı güncellemeden ayırın ve banner ne derse desin ateşlenen platformları bulun.
• Server-side GTM nasıl ayıklanır — Proxy’lenen isteklerin çoğu araçta neden kaybolduğu, sGTM kurulumunu ele veren dört sinyal ve sunucu önizleme oturumuna nasıl bağlanılacağı.
• GA4 trafiğin başka yerden geldiğini söylediğinde — Kampanya parametreleri tıklama ile istek arasında sanılandan sık kayboluyor. Kaybolduğu altı yer ve yanlış kaynağı taşıyan isteği okuma yolu.
• Google Tag Gateway: gerçekten çalıştığını doğrulamak — Tag Gateway, Google'ın script'lerini kendi alan adınızdan sunar. İstekte ne değişir, server-side GTM'den farkı nedir ve sessizce yarım çalışmasının dört yolu.
• TikTok, Snap, UET ve beş platform için Test Events — DebugView ve Tag Assistant'ı herkes biliyor. Diğer platformların da aynısı var; neredeyse hiçbir yerde belgelenmemiş bir çerezle açılıyor. İşte tam liste.

Diğer ikisi: GTM debugger, dataLayer inceleyici