Server-side GTM’e geçmeli misiniz?

Çoğu işletme için kısa cevap şu: ölçülebilir bir sorununuz varsa evet, “herkes geçiyor” diye hayır. Server-side GTM veri akışı üzerinde kontrol kazanmanızı, çerez ömrünü belirli koşullarda uzatmanızı ve reklam platformlarına daha temiz sinyal göndermenizi sağlar. Buna karşılık her ay ödenen bir altyapı faturası ve sahiplenilmesi gereken bir sunucu getirir. Karar, bu iki tarafın sizin trafiğiniz ve ekibiniz için nasıl dengelendiğine bağlı.

Server-side GTM gerçekte ne yapar

Klasik kurulumda kullanıcının tarayıcısı GA4’e, Google Ads’e, Meta’ya ve diğer araçlara ayrı ayrı istek gönderir. Server-side kurulumda tarayıcı bu istekleri önce sizin kontrolünüzdeki bir tagging server’a gönderir. Bu sunucu gelen isteği bir client ile yakalar, bir event modeline çevirir, ardından server container içindeki tag’ler bu veriyi hedef platformlara iletir.

Pratikte değişen üç şey var. Birincisi, veri tarayıcıdan çıktıktan sonra üçüncü taraflara ulaşmadan önce sizin elinizden geçer. İkincisi, istekler metrics.siteniz.com gibi kendi alt alan adınıza gider. Üçüncüsü, çerezleri JavaScript yerine sunucu tarafından Set-Cookie başlığıyla yazabilirsiniz. Google’ın server-side tagging dokümantasyonu mimariyi ayrıntılı anlatıyor, ancak dokümantasyon size bu üç değişikliğin sizin için ne kadar değerli olduğunu söylemez. Onu sizin hesaplamanız gerekir.

Önemli bir yanlış anlamayı baştan düzeltelim: server-side GTM, web GTM’in yerine geçmez. Çoğu kurulumda web container yerinde kalır, dataLayer aynı şekilde beslenir, sadece isteklerin gittiği adres değişir. Yani istemci tarafındaki ölçüm hijyeniniz kötüyse server tarafı bunu düzeltmez, sadece kötü veriyi daha pahalı bir yoldan taşır.

Neyi çözer, neyi çözmez

Satış sunumlarında server-side GTM çoğu zaman her derde deva gibi anlatılır. Sahada gördüğümüz tablo daha mütevazı.

Ad blocker

İsteklerin kendi alan adınıza gitmesi, google-analytics.com gibi bilinen alan adlarını hedefleyen liste tabanlı engellemenin bir kısmını aşar. Ancak birçok engelleyici path, parametre ve script imzasına da bakar. gtag.js dosyası hâlâ googletagmanager.com üzerinden yükleniyorsa kazanç sınırlı kalır. Script’i de kendi sunucunuzdan servis etseniz bile engelleyici listeleri zamanla güncellenir. Burada bir de etik sınır var: ad blocker kullanan kişi bir tercih beyan ediyor. Consent Mode sinyallerini ve onay durumunu server tarafında da aynen korumak zorundasınız.

ITP ve çerez ömrü

Safari, JavaScript ile yazılan birinci taraf çerezlerin ömrünü kısaltıyor. Server tarafından yazılan çerezler bu kısıtlamadan etkilenmeyebilir, ancak bir koşul var: tagging server’ınızın IP adresi ana sitenizin IP aralığıyla uyuşmuyorsa Safari bu çerezleri de üçüncü taraf gibi değerlendirip ömürlerini kısaltabilir. Yani sadece bir CNAME kaydıyla alt alan adı açmak yetmeyebilir. Gerçek fayda için tagging server’ı ana sitenizle aynı altyapının arkasına, örneğin aynı load balancer veya CDN üzerinden bir path’e almanız gerekebilir. Bu da işin kolay kısmı değil.

Veri kontrolü

En sağlam fayda burada. Server container içinde IP adresini kısaltabilir, URL’lerdeki e-posta veya telefon gibi kişisel verileri temizleyebilir, belirli parametreleri belirli platformlara hiç göndermeyebilirsiniz. KVKK açısından hangi verinin hangi tedarikçiye gittiğini belgeleyebilmek, denetimde elinizi ciddi şekilde güçlendirir.

Aynı kontrol, reklam platformlarına giden sinyalin kalitesi için de geçerli. Sipariş değeri, kâr marjı veya müşteri segmenti gibi bilgileri tarayıcıda açığa çıkarmadan, server container içinde zenginleştirip sadece ilgili platforma gönderebilirsiniz. Bu, dönüşüm değerlerinin rakiplerin inceleyebileceği bir dataLayer’da durmasından çok daha sağlıklı bir yaklaşımdır. Ancak zenginleştirme için sunucudan ek bir API veya veritabanı çağrısı yapıyorsanız, her event için gecikmeyi ve maliyeti artırdığınızı unutmayın.

Sayfa hızı

Sayfa hızı kazancı yalnızca istemcideki pixel’leri gerçekten kaldırdığınızda oluşur. Meta pixel, TikTok pixel ve benzerlerini tarayıcıda bırakıp bir de server tarafına kopyalarsanız sayfa hızında değişiklik görmezsiniz. Üstelik bazı platformlar deduplication için hâlâ istemci tarafı sinyal ister.

Barındırma seçenekleri ve maliyet kalemleri

Tagging server’ı nerede çalıştıracağınız, maliyetten çok operasyon modelinizi belirler. Aşağıdaki tablo sahada en sık karşılaşılan seçenekleri özetliyor.

Seçenek	Kurulum zorluğu	Operasyon yükü	Kimler için uygun
Cloud Run (kendi GCP projeniz)	Orta	Yüksek: izleme, güncelleme ve ölçekleme sizde	GCP bilgisi ve nöbet kapasitesi olan ekipler
Yönetilen sağlayıcı	Düşük	Düşük: altyapıyı sağlayıcı yönetir	Küçük ve orta ölçekli, altyapı ekibi olmayan şirketler
Başka bir bulut, Docker ile	Yüksek	Yüksek: her şey sizin sorumluluğunuzda	Mevcut altyapısını tek bulutta tutmak zorunda olanlar
App Engine (eski kurulumlar)	Orta	Orta	Yeni kurulum için değil, taşınmayı bekleyen mirasa sahip olanlar

Cloud Run tarafında Google’ın Cloud Run kurulum rehberi iyi bir başlangıç noktası. Yönetilen sağlayıcılarda ise sözleşmeye bakarken fiyattan önce veri işleme yeri, alt işleyiciler ve çıkış koşullarını okuyun.

Maliyeti belirleyen kalemler, kurulumdan bağımsız olarak büyük ölçüde aynı:

• İstek hacmi: her event bir istektir, server container’dan tedarikçilere giden her iletim de ek iş yüküdür.
• Minimum instance sayısı: soğuk başlangıç ve veri kaybını önlemek için sürekli açık tutulan instance’lar, trafik olmasa da faturalanır.
• CPU ve bellek ayarı: instance başına ayrılan kaynak, hem birim maliyeti hem de instance başına kaldırılabilen isteği belirler.
• Bölge seçimi: bölgeler arası fiyat farkı ve kullanıcılarınıza olan gecikme, birlikte değerlendirilmelidir.
• Loglama: Cloud Logging’e her isteğin yazılması, fark edilmeden faturanın ciddi bir kalemine dönüşebilir.
• Load balancer ve ağ çıkışı: ITP için aynı altyapı arkasına alma kararı ek bileşen ve ek trafik maliyeti demektir.

Tamamen hipotetik bir örnek vermek gerekirse, aylık birkaç milyon event işleyen orta ölçekli bir e-ticaret sitesi ile aylık yüz milyonlarca event işleyen bir yayıncı arasında fatura farkı kolayca on katı aşabilir. Kendi tahmininizi yapmak için GA4’teki aylık event sayınızı, istemciden gelen istek oranıyla birlikte ele alın ve seçtiğiniz sağlayıcının hesaplayıcısında birkaç senaryo deneyin.

Operasyonel sahiplik: sunucu artık sizin

Server-side GTM’e geçtiğinizde ölçüm altyapınız bir web sayfası ayarı olmaktan çıkıp üretimde çalışan bir servise dönüşür. Bu servisin bir sahibi olmalı. Cumartesi gece tagging server yanıt vermediğinde kimin haberdar olacağını, kimin müdahale edeceğini bilmiyorsanız henüz hazır değilsiniz.

Sahiplenilmesi gereken işler somut. Uptime ve hata oranı için alarm kurulmalı. Google server container imajını güncellediğinde Cloud Run servisinin yeniden deploy edilmesi gerekir, bu da takvime bağlanmalı. Preview server ile tagging server’ın ayrı servisler olduğu ve ayrı izlenmesi gerektiği unutulmamalı. Server container’daki değişiklikler web container’daki gibi versiyonlanmalı, yayın öncesi gözden geçirilmeli. Son olarak fatura takibi için bütçe alarmı tanımlanmalı.

Server container’a eklediğiniz her tag, gece yarısı sizi uyandırabilecek bir bağımlılıktır. Sahibi olmayan bir tag’i server tarafına taşımayın.

Pazarlama, veri ve yazılım ekiplerinin aynı masada olması burada şart. Pazarlama ekibi yeni bir platform eklemek istediğinde bunun hangi veriyi dışarı çıkardığını veri ekibi, altyapıya ne yük getirdiğini yazılım ekibi değerlendirebilmelidir.

Pratik bir öneri: geçişten önce kısa bir runbook yazın. Tagging server yanıt vermezse ilk kontrol edilecek metrikler, son deploy’un nasıl geri alınacağı, preview modunun nasıl açılacağı ve hangi tedarikçiye kimin ulaşacağı bu belgede olsun. Bir sayfayı geçmeyen bu doküman, ilk olayda saatler kazandırır.

Aşamalı geçiş planı

Tek seferde tüm tag’leri taşımak, bir şey bozulduğunda neyin bozduğunu bulamamanın en hızlı yoludur. Sahada işe yarayan sıra şu:

1. Envanter ve hedef: mevcut tag’leri listeleyin, geçişle hangi sorunu çözmek istediğinizi yazılı hale getirin ve bugünkü değerleri baseline olarak kaydedin.
2. Altyapı: tagging server ve preview server’ı kurun, alt alan adını bağlayın, alarm ve bütçe uyarılarını ilk günden tanımlayın.
3. GA4’ü paralel akıtın: Google tag yapılandırmasında server_container_url parametresiyle trafiği önce bir test property’sine yönlendirin. Eski gtag kurulumlarında bu rolü transport_url üstlenir.
4. Karşılaştırın: en az iki hafta boyunca eski ve yeni akışı tarayıcı, cihaz ve event bazında karşılaştırın.
5. Üretime alın: farklar açıklanabilir düzeydeyse ana property’yi server tarafına çevirin ve istemci tarafındaki kopyayı kaldırın.
6. Reklam platformlarını tek tek ekleyin: Google Ads ve Meta gibi platformları event_id ile deduplication kurarak, her biri için ayrı bir karşılaştırma dönemiyle devreye alın.
7. Çerez ve ITP iyileştirmesini en sona bırakın: aynı altyapı arkasına alma işi en fazla bağımlılığı olan adımdır.

Dördüncü adım için BigQuery export’u kullanıyorsanız, geçiş tarihinin öncesi ve sonrasını tarayıcı bazında karşılaştırmak hızlı bir sağlık kontrolü sağlar:

DECLARE migration_date DATE DEFAULT DATE '2026-06-15';

WITH daily AS (
  SELECT
    PARSE_DATE('%Y%m%d', event_date) AS gun,
    device.web_info.browser AS tarayici,
    COUNT(*) AS event_sayisi,
    COUNT(DISTINCT user_pseudo_id) AS kullanici
  FROM `project.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260601' AND '20260630'
    AND event_name IN ('page_view', 'purchase')
  GROUP BY gun, tarayici
)
SELECT
  tarayici,
  IF(gun < migration_date, 'once', 'sonra') AS donem,
  ROUND(AVG(event_sayisi), 0) AS gunluk_ort_event,
  ROUND(AVG(kullanici), 0) AS gunluk_ort_kullanici
FROM daily
GROUP BY tarayici, donem
ORDER BY tarayici, donem;

Burada aradığınız şey mutlak artış değil, tutarlılık. Safari’de kullanıcı sayısının düşüp event sayısının sabit kalması, çerez tarafında bir şeyin beklediğiniz gibi çalışmadığına işaret edebilir. Chrome’da ani bir düşüş ise genellikle yanlış yapılandırılmış bir client veya consent akışından kaynaklanır. Haftanın günü etkisini ve kampanya takvimini hesaba katmadan sonuç çıkarmayın.

Ne zaman geçmemelisiniz

Server-side GTM’in doğru cevap olmadığı durumlar sanıldığından daha yaygın. Aylık trafiğiniz düşükse ve reklam bütçeniz sinyal kaybının ROAS üzerinde ölçülebilir bir etki yaratacağı büyüklükte değilse, altyapı maliyeti muhtemelen kazancı aşar. Mevcut web container’ınız dağınıksa, dataLayer tutarsızsa ve temel event’ler güvenilir değilse önce oraya yatırım yapın. Bozuk veriyi server tarafına taşımak onu düzeltmez.

Ekibinizde servisi sahiplenecek kimse yoksa ve yönetilen bir sağlayıcıya da bütçe ayıramıyorsanız, yarım bırakılmış bir server kurulumu hiç kurulum olmamasından daha kötüdür. Veri kaybı sessizce yaşanır ve aylar sonra fark edilir.

Bir de beklenti meselesi var. Geçiş sonrası GA4’te kullanıcı sayısının belirgin şekilde artmasını bekleyen yönetim ekipleri çoğu zaman hayal kırıklığına uğrar. Artış olursa bile büyük kısmı Safari ve belirli engelleyicilerin yaygın olduğu segmentlerde görülür, toplam trafikte ise tek haneli bir iyileşme olarak kalabilir. Bu rakamı projenin başarı ölçütü yaparsanız, gerçekte değerli olan veri kontrolü ve sinyal kalitesi kazanımları gözden kaçar.

Son olarak, amacınız kullanıcının onay tercihini veya ad blocker kararını aşmaksa, bu hem hukuki hem de itibari bir risktir. Server-side GTM, onay yönetimini daha kontrollü uygulamanın aracıdır, onu devre dışı bırakmanın değil.

Özetle, geçiş kararını teknik bir trend olarak değil, bir yatırım kararı olarak ele alın. Çözmek istediğiniz sorunu yazın, bugünkü değeri ölçün, maliyeti ve sahipliği netleştirin. Bu üç soruya net cevap verebiliyorsanız geçiş büyük ihtimalle karşılığını verir. Veremiyorsanız önce o cevapları bulun.