Google Tag Artık GTM Container: Destinations Modeli ve Denetlemen Gereken Container ID

Google Marketing Live’da (21 Mayıs 2026) duyurulan ve 20 Mayıs tarihli destek sayfasıyla detaylanan güncelleme, GTM tarafının yıllardır en büyük mimari değişikliği. Özet net: Google Tag’ler tam yetkili birer Google Tag Manager container’ına yükseltiliyor; container içinde her Google destination (GA4, Ads, Floodlight) kendi tag’ini alıyor ve container veriyi bu Destinations’a doğrudan gönderiyor.¹

Üç noktayı baştan ayırmak gerekiyor: bu güncelleme otomatik veri toplama eklemiyor, Google ürünlerini kullanmaya zorlamıyor ve container mevcut haliyle çalışmaya devam ediyor. Upgrade opt-in bir tercih; preview, workspace testi ve gerektiğinde rollback ile geri alınabiliyor. Kazanç tarafı net olsa da güncelleme yeni bir denetim aksiyonu doğuruyor; bu yazı hem değişen mimariyi hem de o aksiyon noktasını ele alıyor.

Ne Değişiyor: Google Tag Artık GTM Container

Şimdiye kadar Google Tag ile GTM birbirine yakın ama ayrı geliştirilen iki üründü; GTM görece duraklarken Google Tag tarafı hızla gelişti. İki ürünün geliştirme hattının birleştirilmesi, GTM güncellemelerinin Google Tag öncelikleriyle çakışmadan ilerlemesini sağlıyor.

Pratik karşılığı: yalnızca Google Tag kullanan siteler artık GTM’in arayüz tabanlı tag yönetimine, debugging’ine ve version control’üne erişebiliyor. Upgrade, tag’lerin in-page davranışını değiştirmiyor; her Google destination kendi tag’ini koruyor, mevcut trigger ve otomasyon event kurulumları olduğu gibi kalıyor.¹

Destinations: gtag.js Yüklemesi Neden Kalkıyor

Asıl performans kazancı burada. Eski akışta GTM, her Google destination’a veri göndermek için ek bir JavaScript dosyası (gtag.js) yüklüyordu; bu da ölçüm iletiminde gecikmeye yol açabiliyordu. Destinations modelinde veri doğrudan container JS üzerinden gönderiliyor, böylece destination başına ek kütüphane yüklemesi ortadan kalkıyor. Sonuç: daha az bant genişliği, daha az tarayıcı kaynağı tüketimi.¹

İkinci kazanç yönetim tarafında. Container geneli Google Tag ayarları yeni bir Settings tab’ında merkezileşiyor ve container’a eklenen tüm destination’lara uygulanıyor. Bir destination için ayar override etmek hâlâ mümkün, ama varsayılan davranış Google’ın tagging ürünleri arasında tutarlılığı artırıyor. Eski akışı, yani ayrı ayarlar ve ek kütüphane yüklemelerini sürdürmek isteyenler legacy Google Tag’leri kullanmaya devam edebiliyor.

Bir başka teknik ayrıntı: yeni deployment snippet’leri artık gtag config command’ı içermiyor. Google, başlatma davranışının gtm init trigger ile kurgulanmasını öneriyor; bu trigger, legacy kurulumu korumak isteyenler için tag’i config command’ı bekleyecek şekilde de yapılandırabiliyor.¹

Tek Snippet, İki ID: Denetim Aksiyonu

Güncellemenin en kolay gözden kaçan ama en kritik tarafı bu. Bundan sonra tüm Google Tag’ler GTM container snippet’iyle deploy edilecek ve her biri hem bir GTM container ID’si hem de bir ürün ID’si (G-XXXXXX, AW-XXXXXX vb.) taşıyacak.²

Buradaki ayrım davranışı belirliyor:

• Snippet GTM container ID ile deploy edilirse container tam yetkili bir GTM container’ı gibi çalışıyor.
• Snippet ürün ID ile deploy edilirse yalnızca Google’ın tag’lerini deploy etmek için kullanılabiliyor.

Çoğu kurulum tam GTM işlevini isteyecektir. Ancak bazı organizasyonlarda, özellikle GTM’in kötüye kullanılması (yetkisiz custom HTML tag’leri, veri sızdırma riski) endişesi varsa, kapsamı bilinçli olarak ürün ID’siyle daraltmak mantıklı olabiliyor. Bu yüzden snippet’teki ID, yeni mimaride düzenli denetlenmesi gereken bir aksiyon noktası haline geliyor: sitedeki container snippet’i hangi ID ile yayında, bu container’ın yetki kapsamı ne?

sGTM ve Custom dataLayer Kullananlar İçin Ne Değişiyor

Server-side GTM kurulumu olan bir yapıda en çok merak edilen soru, ek gtag.js isteklerinin kalkmasının server-side akışı bozup bozmadığı. Kısa cevap: bozmuyor.

sGTM: Her şey destination’ları yükleyen master container’a gömülü olduğundan, container sGTM üzerinden yüklense bile product tag’lerde server_container_url ayarı eskisi gibi kullanılmaya devam ediyor. Container’a bir GA4 Destination ve onun yeni GA4 product tag’i eklenip server_container_url ile yapılandırıldığında, GA4 hit’leri yine ilgili sGTM endpoint’ine gönderiliyor. Yani server-side dispatch mantığı aynen korunuyor; değişen tek şey istemci tarafında kütüphane teslimatının konsolide olması.

Custom dataLayer adı: Özel bir dataLayer adı kullanılıyorsa, bu container snippet’inde doğru implement edildiği sürece yeni modelde ek bir değişiklik gerekmiyor. Hedeflenen son durum sitede tek bir container snippet’i; tüm ads ürünleri o container’ın destination’ları olarak yükleniyor.

Service worker: Bu güncelleme kütüphane teslimatı ve konsolidasyonuyla ilgili. Bireysel event istekleri ve ping’ler bu değişiklikten etkilenmiyor, dolayısıyla service worker operasyonları eskisi gibi sürüyor.

UI Değişiklikleri ve Visual Tagging

Arayüz tarafında üç değişiklik öne çıkıyor:

• Overview redesign: Az kullanılan Overview sayfası, yeni container + ürün mimarisini destekleyecek şekilde elden geçiriliyor; container geneli ayarlar ve destination’lara giden veri akış haritası burada toplanıyor.
• Advanced menüsü: Yan menüdeki bazı öğeler (Triggers, Variables, Templates, Folders) bir collapsible Advanced sekmesinin arkasına taşınıyor. Karmaşayı azaltıyor ama power user’lar için normal akışa bir tık ekliyor.
• Visual tagging: Tag Assistant üzerinden çalışan, sitede gerçek bir dönüşüm akışını gezerek tag, trigger ve variable’ları otomatik üreten bir WYSIWYG event builder geliyor. CRO araçlarının yıllardır sunduğu görsel editörlere benziyor. Şu an Google Ads purchase conversion’ları için beta; yıl içinde başka kullanım senaryolarına yayılacak.³

Optimizasyon akışını başlatmak için container üzerinde edit, approve veya publish yetkisi gerekiyor; tüm değişiklikler publish’ten önce preview edilebiliyor. Optimizasyon sırasında Google destination hesaplarına bağlantı otomatik kuruluyor ve varsayılan olarak “Read” erişimi veriliyor; bu izinler user management’tan ayarlanabiliyor.

Bu Ne Sinyali Veriyor

Teknik olarak güncelleme öncelikle tag kütüphanelerinin tarayıcıya nasıl teslim edildiğini optimize ediyor: opt-in eden siteler hızlanıyor, Google Tag’ler paylaşımlı ayarlarla daha kolay kontrol altında tutuluyor, tagging ve marketing ekipleri aynı arayüzde buluşuyor. Buraya kadar itiraz edilecek bir taraf yok.

Daha geniş resim ise merkezileşme. Bu benim okumam: ölçümleme, consent kontrolleri ve attribution Google’ın kendi tag altyapısında tek noktada toplandıkça, Google’ın tek elden adtech sağlayıcısı konumu güçleniyor; veri toplama, consent reddi sonrası modelleme, attribution kararı ve Ads sistemine besleme aynı kapının arkasına geçiyor. Snippet’i ürün ID’siyle daraltabilme seçeneği bu tabloda bir denge aracı; kapsamı sınırlamak isteyen organizasyona çıkış veriyor.

Pratik sonuç şu: büyümesi büyük ölçüde Google Ads’e bağlı olmayan işletmeler için bu merkezileşme, veri ihtiyaçlarında alternatifleri değerlendirmek için bir sinyal olabilir. Google Ads bağımlılığı yüksek olanlar içinse kazanç net ve upgrade büyük olasılıkla doğru tercih.

Opt-in Etmeli misin?

Karar tek eksende veriliyor: kazanç mı, dikkat mi ağır basıyor?

Geri alınabilir olduğu için pratik öneri net: önce preview ve bir workspace testi, ardından container ID kapsamının doğrulanması, sonra publish. Otomatik bir dayatma olmadığı için acele etmeye gerek yok; ama gtag.js yükleme yükünü taşıyan, performansa duyarlı kurulumlarda kazanç belirgin olabilir.