Google Tag Manager (GTM), pazarlama ve analitik ekiplerine tag yönetiminde büyük özgürlük tanır. Standart tag tiplerinin yetmediği durumlarda devreye giren Custom HTML tag’leri ise bu özgürlüğün en geniş alanını oluşturur. Ancak bu özgürlüğün arka planında, çoğu ekibin geç fark ettiği bir sınır vardır: her GTM container’ı 200 KB ile sınırlıdır.

Bu yazıda, Custom HTML tag’lerinin hangi durumlarda kullanıldığını, container’ın neden dolduğunu ve dolmadan önce alınabilecek mimari önlemleri ele alacağız. Ardından bu sınıra takılan ekiplerin sıfır maliyetle uygulayabileceği bir çözüm yaklaşımını adım adım anlatacağız.

Custom HTML Tag Neden Bu Kadar Çok Kullanılır?

GTM’in standart tag tipleri günlük kullanımın büyük bölümünü karşılar. Ancak bazı senaryolarda standart tag’ler yetersiz kalır, ekipler doğrudan HTML ve JavaScript yazmak zorunda kalır.

En sık karşılaşılan durumlar şunlardır:

Yapısal veri (Schema markup) enjeksiyonu

Ürün, makale, sıkça sorulan sorular, ekmek kırıntısı gibi JSON-LD formatındaki yapısal veriler doğrudan sayfaya HTML olarak basılır. Geliştirme döngüsünü beklemeden hızlıca canlıya almak için tercih edilir.

Üçüncü taraf piksel ve script entegrasyonları

Reklam platformlarının özel parametre alan pikselleri, A/B test araçlarının başlatma scriptleri, chat widget’ları, ısı haritası araçları çoğunlukla Custom HTML olarak eklenir.

Sayfa içinde değişken hesaplama ve dataLayer manipülasyonu

Standart değişken tipleriyle erişilemeyen veri noktalarını hesaplamak, dinamik olarak dataLayer’a push etmek veya sayfa öğelerinden veri toplamak için custom kod gerekir.

DOM müdahaleleri ve kullanıcı arayüzü olayları

Belirli bir butona tıklandığında sayfaya bir element eklemek, çerez banner’ını yönetmek, form alanlarına dinamik değer atamak gibi işlemler Custom HTML üzerinden yapılır.

Conversion ve event yardımcı scriptleri

Bir conversion’ın gerçekten ölçülebilmesi için sayfada bazı yardımcı fonksiyonların çalışması gerekebilir. Bu fonksiyonlar Custom HTML içine yazılıp tetiklenir.

Yukarıdaki senaryoların her birinde Custom HTML’in çözüm sunması kuvvetli bir gerekçedir. Ancak burada bir başka kuvvetli dinamik daha vardır: Custom HTML eklemenin geliştirici onayı, deploy süreci ve teknik koordinasyon gerektirmemesi.

Bir pazarlama yöneticisi sabah ihtiyacı belirler, öğleden sonra tag’i canlıya alır. Bu hız büyük bir avantajdır. Ama tam da bu hız nedeniyle Custom HTML tag’leri zamanla birikir.

Container Sınırı Sessizce Dolar

GTM’in 200 KB sınırı bir gecede dolmaz. Yıllar içinde birikir.

Bir gün ekip yeni bir kampanya için tag eklemek ister, GTM container %100 uyarısı verir. Eski tag’lerin hepsi canlıda çalışıyordur, hiçbiri tek başına kritik görünmese de bir bütün olarak iş süreçlerini taşıyordur. Silinemez, ama yenisi de eklenemez.

Bu noktada genellikle iki yanlış refleks görülür:

1. Eski tag’leri tek tek incelemek ve hangisinin gerçekten gerekli olduğunu sorgulamak

2. Sorunu erteleyip geçici çözümler aramak

Oysa asıl sorun tag sayısı değil, GTM’in nasıl kullanıldığıdır.

Doğru Soru: GTM Neyi Barındırmalı?

GTM’in tasarım amacı, tag’leri yönetmek ve tetiklemektir. İçeriği barındırmak değildir.

Custom HTML tag’lerinin içine yazılan uzun JSON-LD blokları, kapsamlı JavaScript fonksiyonları, kilobytelarca içerik aslında GTM’in görevi değildir.

Sağlıklı bir yaklaşım, GTM’i sadece bir yönlendirici olarak kullanmaktır. İçerik başka bir yerde durur, GTM o içeriğin yüklenmesini tetikler.

Bu ayrımı yapmak, container’ı yıllar boyu dolmaktan kurtarır.

Mimari Çözüm: GTM’den JavaScript Dosyasını Çağırmak

Çözümün özü şudur:

Custom HTML tag’inin içine yazılan tüm uzun kod, harici bir JavaScript dosyasına taşınır. GTM’deki tag ise yalnızca tek bir satır içerir; o da harici dosyayı çağıran script etiketidir.

Yani GTM’deki Custom HTML tag’inin içeriği şu kadar kısa olur:

Harici dosya içinde ise istenen tüm mantık çalışır. Sayfa URL’sine göre farklı kodlar tetiklenebilir, içerik dinamik olarak hesaplanabilir, çeşitli koşullara göre farklı davranılabilir.

GTM bu mantığın hiçbirinden haberdar olmaz; sadece dosyayı çağırır.

Bu yaklaşımın getirdiği avantajlar yalnızca container size sorununu çözmekle sınırlı değildir:

Kod güncellemesi GTM’siz yapılır

Bir değişiklik gerektiğinde GTM’e girip publish etmek gerekmez. Harici dosya güncellenir, GTM olduğu gibi kalır.

Birden fazla GTM container’ı tek dosyadan beslenebilir

Aynı kod birden fazla sitede çalışıyorsa, her container’a aynı script çağrısı eklenir. Kod tek yerden yönetilir.

Geliştirici workflow’una yakınlaşılır

Kod artık bir editörde, syntax highlight ile, pull request süreciyle yönetilebilir. GTM’in dar text alanından çıkılır.

Harici Dosya Nerede Barınmalı?

Bu yaklaşımı uygulamak için bir hosting çözümü gerekir.

Sitenin kendi sunucusuna erişim varsa en temiz yöntem, dosyayı doğrudan oraya koymaktır. Pazarlama ve analitik ekiplerinin ise çoğunlukla sunucu erişimi olmaz.

Bu durumda sıfır maliyetli birkaç güvenilir seçenek devreye girer:

Git tabanlı kod barındırma servisleri

GitHub, GitLab gibi platformlar kodu barındırır ve versiyon kontrol sağlar. Repository’deki dosyalar doğrudan internetten servis edilmez, ancak bağlanacak hosting servisleri için temel kaynak görevi görür.

Static hosting platformları

Render, Netlify, Cloudflare Pages, Vercel gibi platformlar git repository’sine bağlanır ve her commit’i otomatik olarak deploy eder.

Bu sayede kod GitHub’a push edilir edilmez yeni versiyon canlıya alınmış olur. Ücretsiz planları genellikle bu tür hafif kullanımlar için yeterlidir.

İdeal akış şu şekildedir:

• Kod GitHub gibi bir versiyon kontrol platformunda durur

• Bu repository Render gibi bir static hosting servisine bağlanır

• Repository’ye yapılan her commit otomatik olarak deploy edilir

• GTM ise bu hosting servisinin verdiği sabit URL’yi çağırır

Hosting URL’si değişmediği sürece GTM’e bir daha dokunmaya gerek kalmaz.

Operasyonel Tarafı: İçerik Yönetimi

Mimari değişiklik teknik tarafta sorunu çözer, fakat içerik üreten ekibin günlük iş akışını da düşünmek gerekir.

SEO veya pazarlama ekibinin yeni bir yapısal veri veya yeni bir tracking kodu eklemek için kod düzenlemek zorunda kalması istenmez.

Bu noktada harici dosyanın üzerine bir yönetim arayüzü inşa edilebilir.

Arayüz, kod bilgisi olmayan kullanıcıların form üzerinden veri eklemesine, mevcut kayıtları görmesine, düzenlemesine ve silmesine olanak tanır.

Yönetim arayüzü de aynı hosting platformunda barındırılabilir; ekipler yalnızca bir URL’yi açıp formu doldurarak işlerini halleder.

Bu sayede sistem üç katmana ayrılmış olur:

1. Kullanıcı yönetim arayüzünü kullanır

2. Arayüz git platformuna kodu yazar

3. Hosting servisi onu otomatik deploy eder

Tüm bu işlem birkaç saniye sürer.

Sınıra Takılmadan Önce Düşünmek

Custom HTML tag’leri GTM’in en güçlü özelliklerinden biridir, ancak GTM’in boyutunu da artıran en büyük etkenlerden biridir.

Her eklenen tag container size’ı bir miktar azaltır. Bu durum başlangıçta görünmez, ama hızlı içerik üreten ekipler için kaçınılmaz şekilde bir gün sınırla karşılaşılır.

O gün geldiğinde geçici çözümler aramak yerine, mimariyi en başından doğru kurmak çok daha az emek gerektirir.

GTM’i bir yönlendirici olarak görmek; içeriği harici dosyalara, dosyaları git platformuna, deploy’u static hosting servislerine bırakmak; bunların üzerine ekiplerin günlük kullanabileceği bir yönetim arayüzü inşa etmek…

Bu dört adım, bir ekibin GTM container’ı sorununu yıllar boyunca yaşamadan büyümesini sağlar.

Önemli olan, container size’ın bir uyarı vermesini beklemek değil; o uyarı gelmeden önce yapıyı doğru kurmaktır.

Doğru kurulmuş bir sistem, yalnızca bugünün sorununu çözmez; yarın daha fazla içerik üretildiğinde, daha fazla tracking eklendiğinde, daha karmaşık kampanyalar yürütüldüğünde ekibi yormaz.