Ana sayfa / Rehberler

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.

Yayınlandı 10 Ağustos 2026

Tag Gateway, Google ölçümünün teslimatını kendi alan adınıza taşır. Tarayıcı gtag.js'i googletagmanager.com'dan çekip google-analytics.com'a göndermek yerine, ikisi de sizin sunucunuzdaki bir ölçüm yolundan geçer — example.com/metrics/… gibi — ve CDN'iniz bunu Google'a iletir.

Bu, server-side GTM değil ve fark önemli

İkisi sürekli karıştırılıyor, oysa tamamen farklı biçimlerde bozuluyorlar.

• Server-side GTM, tag çalıştırmasını sizin işlettiğiniz bir container'a taşır. Tarayıcı sunucunuza tek bir istek gönderir; neyi kime ileteceğine sunucunuz karar verir. Event'leri orada yeniden yazabilir, zenginleştirebilir ya da düşürebilirsiniz.
• Tag Gateway yalnızca taşımayı taşır. Tag'ler yine tarayıcıda çalışır, içerik değişmez ve altyapınız katılımcı değil, borudur.

İkisini birden, birini ya da hiçbirini çalıştırıyor olabilirsiniz. Eksik bir event'i ayıklarken hangisinin devrede olduğunu bilmek, şüpheyi container yapılandırmasına mı yoksa yönlendirme kuralına mı çevireceğinizi söyler.

İstekte ne değişir

İçeride hiçbir şey. tid, en, cid, event parametreleri, ürünler, izin bayrakları — hepsi aynı. Değişen, ana bilgisayar adı ve yol öneki. Bu tek olgu, pek çok ayıklama aracının neden bomboş kaldığını açıklıyor: Google isteklerini ana bilgisayar adından tanıyorlar ve o ad artık sizin.

Bunun yerine yoldan okumak — herhangi bir sunucuda, herhangi bir yerdeki bir /g/collect — istekleri görünür tutar; server-side GTM isteklerini okunur kılan da aynı yöntemdir.

Yarım çalışmasının dört yolu

1. Script birinci taraf ama istekler değil. Yarım bir yapılandırma gtag.js'i sizin alan adınızdan sunarken toplamayı Google'a bırakır. Raporlarda her şey yolunda görünür ve bu işe girişme sebebiniz olan dayanıklılığın hiçbiri elinizde olmaz. Ana bilgisayar adına script'te değil, /g/collect isteğinde bakın.
2. Ölçüm yolu bir uygulama rotasıyla çakışır. Uygulamanız o önekte zaten cevap veriyorsa ya da yönlendiricinizde bir yakala-hepsini kuralı varsa, CDN kuralına sıra hiç gelmez ve istekler sizin 404 sayfanızla döner. Bir collect isteğindeki 404, GA4'te bulacağınız bir izleme hatası değildir; yalnızca ağda görünür.
3. Bir önbellek kuralı uç noktayı yakalar. Ölçüm yolları sayfalarınızla aynı alan adında durur, dolayısıyla geniş bir önbellek kuralı onlara da uygulanabilir. Önbelleğe alınmış bir collect yanıtı isteği kaybetmez — istek yine çıkar — ama önbelleğe alınmış bir gtag.js, TTL süresince ziyaretçileri eski bir yapılandırmaya çakabilir.
4. İzin değişmez ama değiştiği sanılır. Birinci taraf teslimat; neyi toplayabileceğinizi, Consent Mode sinyallerinin ne zaman okunacağını ya da banner gerekip gerekmediğini değiştirmez. gcs ve gcd parametreleri eskisi gibi yol alır ve kontrol edilecek şey de onlardır.

Bilerek karar verilmesi gereken kısım

Birinci taraf sunumun bildirilen kazancının bir bölümü, bir içerik engelleyicinin Google alan adında durduracağı ama sizinkinde durdurmadığı isteklerden gelir. Bu gerçek bir etki ve sonradan keşfetmek yerine baştan anlamaya değer: izlemeyi engellemeyi seçmiş ziyaretçilere nasıl davranacağınıza dair bir karardır ve izin uygulamanızın doğru olup olmadığından ayrı bir konudur.

Bir rutin

1. Bir sayfa açın ve gtag.js isteğini bulun. Ana bilgisayar adını not edin.
2. Bir /g/collect isteği bulun. Onun da adını not edin. İkisi uyuşmuyorsa yapılandırma yarımdır.
3. Durum koduna bakın. Bir gateway yönlendirme hatası 404 ya da yönlendirme olarak görünür, raporda eksik veri olarak asla.
4. İsteği açıp tid, event adı ve gcs'nin geçişten önceki hâliyle aynı olduğunu doğrulayın. İçerik dokunulmamış olmalı.
5. Bir dönüşümü baştan sona yürüyün ve eski kurulumu kapatmadan önce sayıları karşılaştırın.

İlgili rehberler

• GA4 trafiğin başka yerden geldiğini söylediğinde
• Gömülü bir widget'ın içindeki izleme
• Server-side GTM nasıl ayıklanır