Etkinlik Verilerinin Takibinde Farklı Yaklaşımlar: GTM, sGTM, Zaraz ve Gateway

Üçüncü Parti Scriptlerin Ağırlığı ve Alternatif Yaklaşımlar

Client-side event tracking (istemci taraflı etkinlik takibi) artık tek başına güvenilir veri toplamak için yeterli değil. Safari 26’nın Advanced Fingerprinting Protection’ı, ITP kısıtlamaları ve ad blocker’lar tarayıcı tarafındaki verileri %30-40 oranında eksik bırakabiliyor. Bu da, Server-side ve edge tabanlı yaklaşımları bir zorunluluk hâline getirmeye başladı.

Web performansını en çok etkileyen faktörlerden biri olan üçüncü parti scriptler. Analitik, reklam pikselleri, A/B test araçları; her biri tarayıcıda ayrı bir JavaScript dosyası yükleyerek Total Blocking Time (TBT) ve Largest Contentful Paint (LCP) metriklerini olumsuz etkiler. Özellikle e-ticaret sitelerinde bu yük ciddi boyutlara ulaşıyor. Shopify gibi platformlarda SEO ve performans için yüklenen bir app, paralelde veri akışını bozabilir.

Total Blocking Time (TBT), sayfanın kullanıcı etkileşimine kapalı kaldığı toplam süreyi ölçer. Uzun süre çalışan JavaScript görevleri bu metriği doğrudan yükseltir.

Largest Contentful Paint (LCP), sayfadaki en büyük görsel öğenin (görsel, başlık bloğu vb.) ne kadar sürede render edildiğini ölçer. Üçüncü parti scriptler ana thread’i bloke ederek LCP’yi geciktirebilir.

Bu yazıda Google Tag Manager (client-side), Server-Side GTM, Cloudflare Zaraz ve Google Tag Gateway’i gerçek e-ticaret verisiyle karşılaştırıyorum. Önce client-side ve server-side ayrımının neden kritik olduğuna, ardından her yaklaşımın güçlü ve zayıf noktalarına değinmeye çalışacağım.

Client-Side ve Server-Side Tracking: Temel Fark

Bu yazıdaki dört yaklaşımı anlamak için önce temel ayrımı netleştirmek gerekiyor: veri nerede toplanıyor ve nerede işleniyor?

Client-Side (Tarayıcı Tarafı)

Geleneksel yaklaşım. JavaScript kodları tarayıcıda çalışır, event’ler doğrudan üçüncü parti sunuculara (Google, Meta, TikTok) gönderilir.

Kullanıcı tarayıcısı → JavaScript SDK → analytics.google.com / facebook.com

Sorun: Tarayıcı bu veri akışının tam kontrolüne sahip. Ad blocker’lar script’leri engelleyebilir. Safari ITP ve AFP cookie’leri ve fingerprint API’lerini kısıtlayabilir. Kullanıcı tarayıcı ayarlarından JavaScript’i devre dışı bırakabilir. Sonuç: toplanan veri eksik kalır.

Server-Side (Sunucu/Edge Tarafı)

Veri istemci (client) tarafından önce kendi sunucunuza veya edge katmanınıza gider, orada işlenir ve hedeflere dağıtılır.

Kullanıcı tarayıcısı → Kendi domain/sunucunuz → analytics.google.com / facebook.com

Avantaj: Tarayıcı kısıtlamalarından bağımsız. 1st-party context sağlar. Veri zenginleştirme, filtreleme ve tekilleştirme mümkün. Consent yönetimi sunucu tarafında kontrol edilebilir.

Neden Bu Ayrım Artık Kritik?

2025’in ikinci yarısında üç gelişme client-side’ın tek başına yeterliliğini ortadan kaldırdı:

1. Safari 26 AFP (Eylül 2025): Client-side tracker’lar fingerprint API’lerine, query string’e ve referrer’a erişimini kaybetti¹².
2. Chrome Privacy Sandbox kapatıldı (Ekim 2025): 3P cookie’ler Chrome’da kaldı, ancak Safari ve Firefox’ta zaten engelli. Cross-browser tutarlılık için server-side tek güvenilir yol³⁴.
3. Consent Mode v2 zorunluluğu (Temmuz 2025): Uygulamayan siteler Google Ads remarketing ve kitle segmentasyonunu kaybediyor⁵⁶.

Bu üç gelişmenin detayları ve cookie politikalarındaki değişimler yazının ilerleyen bölümlerinde ele alınıyor.

Bu bağlamda aşağıdaki dört yaklaşımın her biri bu ayrımda farklı bir noktada konumlanıyor:

Yaklaşım	Konum	Tarayıcı bağımlılığı
GTM (Client)	Tamamen client-side	Tam bağımlı
sGTM	Client hit → server işleme	Kısmi (ilk hit client’tan)
Zaraz	Edge (CDN) işleme	Minimal (sıfıra yakın JS)
Gateway	Proxy (transparent)	Düşük (mevcut tag’leri proxy’ler)

4 Yaklaşımın Tanıtımı

GTM (Client-Side)

Google Tag Manager, tarayıcıda çalışan en yaygın tag management çözümü. dataLayer üzerinden event’leri dinler, trigger ve değişken sistemiyle etiketleri yönetir.

Avantajları:

• Geniş entegrasyon kütüphanesi (yüzlerce şablon)
• Güçlü trigger, değişken ve özel JavaScript desteği
• Büyük topluluk ve dokümantasyon kaynağı
• Ücretsiz

Dezavantajları:

• Her araç tarayıcıda ayrı script yükler; performans maliyeti yüksek
• Ad blocker’lara karşı savunmasız
• Üçüncü parti scriptlerin güvenlik riskleri (XSS, veri sızıntısı)
• Safari 26 AFP ile tracker olarak sınıflandırılan GTM script’leri query string ve referrer erişimini kaybedebiliyor

Ne zaman tercih edilmeli: Küçük-orta ölçekli siteler, çok sayıda entegrasyon gerektiren yapılar, ekipte GTM deneyimi olan durumlar.

Server-Side GTM (sGTM)

Server-Side GTM, GTM container’ını tarayıcı yerine sunucu tarafında çalıştırıyor. İstemci hit’leri bir proxy endpoint’ine gönderiyor, sunucu tarafındaki container event’leri işleyip ilgili hedeflere dağıtıyor. Genellikle Cloud Run veya özel sunucu üzerinde barındırılıyor.

Avantajları:

• 1st-party context: Hit’ler kendi domain’iniz üzerinden gidiyor
• ITP (Intelligent Tracking Prevention) bypass imkanı
• Tam veri kontrolü; hangi verinin nereye gideceğine sunucu tarafında karar veriliyor
• Ad blocker’lara karşı dayanıklı
• Consent Mode v2 sunucu tarafında yönetilebiliyor

Dezavantajları:

• Altyapı maliyeti (Cloud Run faturaları trafik arttıkça yükseliyor)
• Kurulum ve bakım karmaşıklığı
• GTM bilgisi hâlâ gerekli; ek olarak sunucu yönetimi de ekleniyor

Ne zaman tercih edilmeli: Yüksek trafikli siteler, CAPI (Conversions API) zorunluluğu olan yapılar, teknik beceri kapasitesi bulunan ekipler. Kendi altyapısını kurmak istemeyen ekipler için Stape gibi managed hosting çözümleri kurulum ve bakım yükünü önemli ölçüde azaltıyor.

2026 güncellemesi: sGTM v3.2.0 ile GA4 Client artık gtag.js’i yüklemiyor; tüm Google JS kütüphaneleri Web Container Client üzerinden yükleniyor. readAnalyticsStorage sandbox API’si ile GA client/session ID’leri güvenli şekilde okunabiliyor.

Cloudflare Zaraz

Cloudflare’ın 2021’deki Zaraz satın alımı⁷ ile birlikte gelen bu çözüm, üçüncü parti scriptleri tarayıcı yerine Cloudflare Workers üzerinde, edge noktasında çalıştırıyor⁸. Tarayıcıya temelde istenmedikçe hiçbir ek JavaScript yüklenmiyor.

Avantajları:

• Tarayıcıda sıfır JS yükü; performans etkisi neredeyse yok
• Cloudflare planına dahil (aylık 1 milyon event’e kadar ücretsiz)
• Kolay kurulum; Cloudflare dashboard üzerinden yapılandırma
• Yerleşik consent yönetimi
• JavaScript SDK ile özelleştirmeler

Dezavantajları:

• Cloudflare’a bağımlılık; site Cloudflare arkasında olmalı
• GTM’e kıyasla daha az entegrasyon seçeneği
• dataLayer uyumsuzlukları⁹; mevcut GTM implementasyonunu birebir taşımak her zaman mümkün değil
• Hata ayıklama ve debug süreci daha zor¹⁰

Ne zaman tercih edilmeli: Zaten Cloudflare kullanan siteler, performansı ön planda tutan projeler, az sayıda araç entegrasyonu gerektiren yapılar.

2026 güncellemesi: Zaraz Automated Actions (Kasım 2024) ile pageview, özel event ve e-ticaret tracking’i araç bazında otomatikleştirilebiliyor. Managed Components programı ile vendor’lar kendi entegrasyonlarını oluşturabiliyor. Consent yönetimi Google Consent Mode v2 ve IAB TCF uyumlu.

Google Tag Gateway

Google Tag Gateway, bir tag manager değil. Sadece Google etiketlerini (gtag.js, GA4, Google Ads) kendi domain’iniz üzerinden proxy’leyen bir araç¹¹. Ad blocker’ların Google endpoint’lerini engellemesi sonucu kaybedilen sinyalleri kurtarıyor.

Avantajları:

• Tamamen ücretsiz
• 5 dakikada kurulabiliyor
• Google’ın kendi verilerine göre medyan %11 sinyal kurtarma
• Mevcut GTM veya Zaraz kurulumunun yanında çalışabiliyor

Dezavantajları:

• Sadece Google araçları için geçerli (Meta’nın kendi gateway çözümleri var¹², TikTok gibi diğer platformlar kapsam dışı)
• Tag management özelliği yok
• Tek başına yeterli bir çözüm değil

Ne zaman tercih edilmeli: Mevcut kuruluma ek olarak, Google Ads dönüşüm kaybı yaşanan senaryolarda.

2026 güncellemesi: Google Tag Gateway Mayıs 2025’te beta’dan çıktı. Ocak 2026’da GCP entegrasyonu (Global External Application Load Balancer üzerinden tek tık kurulum) ve Akamai desteği eklendi¹³. Artık sadece Cloudflare arkasındaki siteler değil, GCP veya Akamai kullanan siteler de Gateway kullanabiliyor.

Karşılaştırma Tablosu

	GTM (Client)	sGTM	Zaraz	Gateway
Çalışma noktası	Browser	Sunucu	Edge (CDN)	Proxy
Performans etkisi	Yüksek	Düşük	Sıfıra yakın	Yok
Kurulum zorluğu	Düşük	Yüksek	Orta	Çok düşük
Maliyet	Ücretsiz	Değişken (altyapı)	Ücretsiz (1M event/ay)	Ücretsiz
Ad blocker dayanıklılığı	Düşük	Yüksek	Orta-yüksek	Yüksek (sadece Google)
Entegrasyon sayısı	Çok yüksek	Yüksek	Orta	Sadece Google
GTM bilgisi gerekli mi	Evet	Evet	Hayır	Hayır
Consent Mode v2 desteği	Kısmi	Tam	Tam (yerleşik)	Tam (Google tag’leri)
2026 tarayıcı kısıtlamalarına dayanıklılık	Düşük	Yüksek	Yüksek	Orta-yüksek

Gerçek Veri ile Test

Bu karşılaştırmayı somutlaştırmak için bir e-ticaret sitesinde aynı anda GTM ve Zaraz ile iki ayrı GA4 mülkü çalıştırdım. Her iki platform da aynı kullanıcıları, aynı zaman diliminde takip etti. Edinilen veri bağlamında gözlem sonuçları aşağıda.

Toplam Rakamlar

Metrik	GTM	Zaraz	Fark
Toplam event	131,163	559,385	+326.5%
Toplam event (page_view hariç)	90,992	103,196	+13.4%
page_view	40,171	456,189	+1,035.6%
session_start	12,809	16,118	+25.8%
purchase	140	143	+2.1%

İlk bakışta Zaraz 4.3 kat daha fazla event toplamış gibi görünüyor. Ancak page_view çıkarıldığında fark sadece %13’e düşüyor. Bu, session_start ve diğer interaction event’lerindeki artışın ad blocker bypass ile açıklanabilecek makul bir fark olduğunu gösteriyor. Asıl anomali page_view sayılarında.

page_view Sorunu

Session başına page_view oranı çarpıcı: GTM’de 3.1, Zaraz’da 28.3. Sayfa bazında bakıldığında farkın kaynağı netleşiyor.

Sayfa	GTM	Zaraz	Fark
/arama	3,713	85,642	+2,207%
/arac-kamerasi	1,674	58,501	+3,395%
/sarj-data-kablosu	601	16,530	+2,650%
/sepet	556	615	+10.6%
/order	715	731	+2.2%

Kategori ve listeleme sayfalarında devasa farklar varken, sepet ve sipariş sayfalarında fark %10 civarında kalıyor. Bu, Zaraz’ın bir hatası değil, varsayılan yapılandırma kararı. Zaraz history.pushState ve replaceState çağrılarını dinleyerek her URL değişikliğinde page_view gönderiyor. Filtre, sıralama veya sayfalama işlemlerinde URL değişen listeleme sayfaları bu inflation’a en çok maruz kalan bölümler. SPA benzeri davranış gösteren sitelerde bu özelliğin kapatılması veya özelleştirilmesi gerekiyor.

Attribution Sorunu

Event-level source/medium dağılımı iki platform arasında dramatik bir tablo ortaya koyuyor.

Kaynak	GTM Sessions	Zaraz Sessions
(direct) / (none)	8,699	20,480
google / organic	10,598	38
Tüm referral	9,101	40

Zaraz’daki event-level attribution tamamen bozulmuş durumda. Event bazında session’ların %99.5’i direct/none olarak raporlanıyor. Organik arama ve referral kaynakları event düzeyinde neredeyse hiç görünmüyor.

Ancak session-level source/medium tablosunda durum farklı. Zaraz session düzeyinde doğru çalışıyor, hatta bazı referral kaynakları GTM’de hiç görünmezken Zaraz’da yakalanmış. GTM tarafında da referral exclusion veya cross-domain yapılandırma eksikliği bazı kaynakların kaybolmasına neden olmuş olabilir. Bu nedenle attribution karşılaştırmasında her iki tarafın da yapılandırma detaylarını göz önünde bulundurmak gerekiyor.

E-ticaret Funnel

Asıl kritik soru: conversion event’leri güvenilir mi? Funnel karşılaştırması net bir tablo çiziyor.

Adım	GTM	Zaraz	Fark
view_item	16,843	17,690	+5.0%
add_to_cart	858	814	-5.1%
begin_checkout	740	774	+4.6%
add_payment_info	196	210	+7.1%
purchase	140	143	+2.1%

Günlük purchase dağılımı da tutarlılığı doğruluyor.

Tarih	GTM	Zaraz	Fark
22 Şubat	12	11	-1
23 Şubat	22	23	+1
24 Şubat	17	15	-2
25 Şubat	16	16	0
26 Şubat	25	26	+1
27 Şubat	27	29	+2
28 Şubat	21	23	+2

view_item’dan itibaren tüm funnel oranları neredeyse aynı. Günlük purchase farkı en fazla 2. Sepet terk takibi dahil e-ticaret conversion tracking her iki platformda da güvenilir düzeyde çalışıyor.

Zaraz’a Özel Kazanımlar

Zaraz’ın varsayılan olarak topladığı bazı event’ler GTM tarafında ayrı event olarak yapılandırılmamıştı. Bu veriler dataLayer içerisinde zaten mevcuttu ancak GTM’de trigger ve tag olarak tanımlanmadığı için GA4’e iletilmiyordu. Zaraz, dataLayer’ı otomatik olarak okuduğu için bu event’leri ek yapılandırma olmadan topladı⁹¹⁴.

Event	Sayı	Açıklama
consent_default	14,377	Consent varsayılan durumu
user_data	3,515	Kullanıcı veri event’i
search	3,297	Site içi arama
consent_update	2,562	Consent güncelleme
login	215	Giriş yapma
sign_up	40	Kayıt olma

Özellikle consent event’leri ve site içi arama verisi değerli. GTM’de bunlar ayrıca trigger ve tag tanımlayarak toplanabilir; Zaraz’ın avantajı dataLayer uyumluluğu sayesinde bunları varsayılan olarak sunması.

2026’da Değişen Dengeler

Bu yazının ilk versiyonunu Mart 2026 başında yayınladığımda odak GTM ve Zaraz arasındaki performans ve veri kalitesi farkıydı. Ancak 2025’in ikinci yarısında üç gelişme tracking ekosistemini köklü şekilde değiştirdi.

Safari 26 ve Advanced Fingerprinting Protection

Eylül 2025’te yayınlanan Safari 26, Advanced Fingerprinting Protection’ı (AFP) varsayılan olarak aktif hâle getirdi¹². Tracker olarak sınıflandırılan client-side script’ler artık:

• Yüksek entropy API’lerine erişemiyor (ekran çözünürlüğü, donanım bilgisi)
• Script tarafından yazılan uzun ömürlü storage’ı (cookie, localStorage) kaybediyor
• Query string parametrelerine ve document.referrer’a erişemiyor

Apple standart kampanya parametrelerini (UTM) muaf tuttu, ancak fingerprinting tamamen engellendi. Bu, client-side tracking’in Safari kullanıcıları için veri kalitesini doğrudan düşürüyor.

Pratik etki: GTM gibi client-side çözümler Safari 26 kullanıcılarından daha az ve daha düşük kaliteli veri topluyor. Server-side veya edge tabanlı çözümler bu kısıtlamalardan etkilenmiyor. Safari ve Firefox ayrıca bounce tracking protection ile redirect zinciri üzerinden yapılan takibi de engelliyor; belirli bir süre kullanıcı etkileşimi olmayan ara domain’lerin cookie ve storage verileri temizleniyor.

Bunun ötesinde, Safari ITP 2.1’den (Şubat 2019) bu yana JavaScript ile oluşturulan cookie’lerin (document.cookie) ömrünü 7 günle sınırlıyor. localStorage ve IndexedDB de 7 gün kullanılmazsa siliniyor. Link decoration tespit edildiğinde (bilinen tracker’lardan gelen query parametreleri) bu süre 1 güne düşüyor. Sunucu tarafından set edilen cookie’ler (Set-Cookie header) bu kısıtlamadan muaf, ancak Safari CNAME cloaking tespiti yapıyor: tracking subdomain’inin IP adresi ana domain’den farklı bir subnet’e çözümleniyorsa, o cookie’ler de 7 güne düşürülüyor¹⁵.

Chrome Privacy Sandbox’ın Sonu

Ekim 2025’te Google, 6 yıllık Privacy Sandbox projesini resmen kapattı³⁴. Attribution Reporting, Protected Audience, Private Aggregation ve IP Protection API’leri kaldırıldı. 3P cookie’ler Chrome’da kalmaya devam ediyor.

Bu ne anlama geliyor? Chrome’da kısa vadede bir değişiklik yok, ancak Safari ve Firefox’ta 3P cookie’ler zaten engelli. Cross-browser tutarlı veri toplama için server-side/1st-party yaklaşım tek güvenilir yol.

Cookie Politikalarının Evrimi ve Google’ın Geri Adımı

Cookie konusu tracking ekosisteminin en çalkantılı hikayesi. Google Ocak 2020’de Chrome’da üçüncü parti cookie’leri “2 yıl içinde” kaldıracağını duyurdu. Sonrası: 4 erteleme (2021, 2022, 2024 iki kez), ardından Temmuz 2024’te tamamen geri adım. Google’ın kendi verilerine göre 3P cookie’lerin kaldırılması publisher gelirlerini Google Ad Manager’da %34, AdSense’de %21 düşürüyordu¹⁶. Ekim 2025’te Privacy Sandbox’ın kapatılmasıyla Topics API, Protected Audience ve Attribution Reporting da kaldırıldı. Geriye CHIPS (partitioned cookies) ve FedCM kaldı.

CHIPS (Cookies Having Independent Partitioned State), üçüncü parti cookie’leri site bazında izole eder; bir cookie sadece onu set eden üst düzey site bağlamında erişilebilir, cross-site takip yapılamaz.

FedCM (Federated Credential Management), üçüncü parti cookie’lere ihtiyaç duymadan federe kimlik doğrulama (Google ile giriş yap, SSO vb.) akışlarını tarayıcı düzeyinde yönetir.

Sonuç: 3P cookie’ler Chrome’da kalmaya devam ediyor, ancak Safari ve Firefox’ta zaten işlevsiz. Bu durum her üç tarayıcıda tutarlı çalışan bir tracking stack’inin neden 1st-party ve server-side odaklı olması gerektiğini gösteriyor.

Tarayıcılar Arası Cookie Davranışı (2026)

	Chrome	Safari	Firefox
3P cookie	İzin var	Varsayılan engelli	Site bazında partitioned
JS-set 1P cookie max ömür	Sınırsız	7 gün	Sınırsız
Server-set 1P cookie max ömür	Sınırsız	Sınırsız (CNAME/IP uyuşmazlığında 7 gün)	Sınırsız
localStorage/IndexedDB	Sınırsız	7 gün kullanılmazsa silinir	Sınırsız
Fingerprinting koruması	Minimal	AFP (varsayılan)	Bilinen fingerprinter engeli
CNAME cloaking tespiti	Yok	Var (IP subnet kontrolü)	Yok

Bu tablo neden server-set 1st-party cookie’lerin kritik olduğunu özetliyor. sGTM kendi subdomain’iniz üzerinden (aynı IP subnet’te) Set-Cookie header’ı ile cookie set ediyor ve Safari’nin 7 gün limitini bypass ediyor. Zaraz ise Cloudflare edge’inde çalıştığı için zaten 1st-party context’te; Managed Components üzerinden cookie’ler sunucu tarafından set ediliyor.

CNAME cloaking ve gerçek 1st-party arasındaki fark: CNAME cloaking, tracking subdomain’ini (ör. track.example.com) üçüncü parti bir sunucuya (ör. cdn.tracker.com) yönlendirmektir; Safari bunu IP subnet kontrolüyle tespit edip cookie’leri 7 güne düşürür. sGTM ve Zaraz bu yolu kullanmıyor. sGTM kendi subdomain’inizi (ör. ss.example.com) aynı IP subnet’te çalışan bir sunucuya (Cloudflare proxy veya GCP Load Balancer) yönlendirir; Safari bunu gerçek 1st-party olarak kabul eder. Zaraz ise zaten sitenin Cloudflare altyapısında çalıştığı için ayrıca bir subdomain yönlendirmesine bile gerek kalmaz. CNAME cloaking gri alan olarak değerlendirilirken, aynı altyapı üzerinden 1st-party cookie set etmek tarayıcı politikalarıyla uyumlu bir yaklaşım.

Consent Mode v2 Zorunluluğu

Temmuz 2025’ten itibaren EEA trafiği için Consent Mode v2 tam olarak zorunlu hâle geldi⁵⁶. Uygulamayan siteler:

• Google Ads’te remarketing ve kitle segmentasyonu kaybediyor
• Attribution ve dönüşüm raporlamasında boşluklar oluşuyor
• ad_personalization ve ad_user_data parametreleri olmadan veri gönderilemiyor

İki mod var: temel (onay olmadan hiç veri yok) ve gelişmiş (anonim ping’lerle modelleme). Gelişmiş modda consent reddedildiğinde Google tag’leri yine yüklenir ancak hiçbir cookie yazılmaz. Bunun yerine cookieless ping’ler gönderilir: consent durumu, sayfa görüntüleme ve dönüşüm event’leri kalıcı tanımlayıcı olmadan iletilir. Google bu verileri davranışsal modelleme ile işleyerek reddedilen kullanıcılardan kaybedilen dönüşüm verisinin bir kısmını kurtarır. Server-side çözümler consent yönetimini daha granüler kontrol edebiliyor.

Google Tag Gateway’in Genişlemesi

Gateway Mayıs 2025’te beta’dan çıktı ve Ocak 2026’da iki önemli entegrasyon kazandı¹³:

• GCP entegrasyonu: Global External Application Load Balancer üzerinden tek tık kurulum
• Akamai desteği: Cloudflare dışındaki CDN altyapılarına da genişleme

Bu, Gateway’in artık sadece Cloudflare kullanan sitelerle sınırlı olmadığı anlamına geliyor. Mevcut GTM veya Zaraz kurulumunun yanına eklenebilen, medyan %11 sinyal kurtaran düşük maliyetli bir katman.

Cookieless Tracking ve Alternatif Ölçüm Yöntemleri

Cookie’lere bağımlı olmayan tracking yöntemleri artık ek bir seçenek değil, temel stratejinin parçası. Öne çıkan yaklaşımlar:

• Enhanced Conversions (Google Ads): Dönüşüm anında toplanan müşteri verisi (e-posta, telefon) SHA-256 ile hash’lenerek Google’ın oturum açmış kullanıcı veritabanıyla eşleştiriliyor. Cookie olmadan cross-device dönüşüm takibi sağlıyor; çoğu reklamveren %5-25 dönüşüm artışı raporluyor¹⁷.

• Server-side CAPI entegrasyonları: Meta CAPI, TikTok Events API, Pinterest CAPI gibi platformlar, hash’lenmiş 1st-party veriyi sunucudan sunucuya göndererek tarayıcıyı tamamen devre dışı bırakıyor. Ortak model: checkout/form verisi → hash → server-side gönderim → platform eşleştirmesi¹⁸.

• Cookieless analytics araçları: Plausible, Fathom ve Simple Analytics gibi araçlar hiç cookie kullanmadan çalışıyor. GDPR kapsamında consent banner gerektirmiyor. Temel metrikler (sayfa görüntüleme, referrer, cihaz) için yeterli, ancak e-ticaret funnel analizi ve reklam attribution’ı için yetersiz kalıyor.

• Contextual targeting: Kullanıcı kimliği yerine sayfa içeriğine dayalı reklam hedefleme. 2025 araştırmalarına göre contextual reklamlar, davranışsal hedeflemeye kıyasla CTR’da %5-8, dönüşüm kalitesinde %10-12 içinde performans gösteriyor ve marka güvenliğinde öne geçiyor.

• 1st-party veri stratejileri: Üyelik programları, newsletter kayıtları, hesap oluşturma ve satın alma geçmişi üzerinden toplanan veriler, cookieless tracking’in temelini oluşturuyor. CDP’ler (Segment, Bloomreach gibi) bu veriyi birleştirip tek bir müşteri profili oluşturuyor.

GA4 + BigQuery: Consent Mode ile Raw Veri Sahipliği

Consent Mode v2’nin gelişmiş modunda consent reddedildiğinde GA4 cookieless ping’ler gönderiyor. Bu veriler BigQuery’ye aktarılabilir ve GA4 arayüzünün sunmadığı bir analiz derinliği sağlıyor¹⁹.

BigQuery’de consent reddedilmiş event’lerde neler var, neler yok:

Mevcut	Yok (null)
event_name (page_view, purchase vb.)	user_pseudo_id
Event parametreleri (transaction_id, value)	ga_session_id
event_timestamp	Traffic source alanları
privacy_info.analytics_storage = “No”	Kullanıcı/oturum kimliği

Pratik kullanım:

• Consent oranı çarpanı: Onay veren ve vermeyen kullanıcı oranını hesaplayarak toplam dönüşüm tahmini yapılabiliyor. Örnek: %60 onay oranıyla 100 purchase görüyorsanız, tahmini toplam ~167.
• Event düzeyinde analiz: Kullanıcı/oturum kimliği olmadan da toplam purchase, gelir ve ürün verileri analiz edilebiliyor.
• BigQuery ML ile modelleme: Onay veren kullanıcıların davranış kalıplarından propensity modelleri oluşturulup, onay vermeyen segment için tahmin yapılabiliyor.

GA4 arayüzündeki davranışsal modelleme (conversion recovery) BigQuery export’una dahil değil. BigQuery’de kendi modellerinizi kurmanız gerekiyor.

Kurulum ve maliyet: GA4 Admin’den BigQuery bağlantısı kurulur. Günlük export ücretsiz (standart: 1M event/gün limiti). Streaming export yaklaşık $0.05/GB. Küçük-orta ölçekli siteler genellikle ücretsiz katman içinde kalıyor²⁰.

Duruma Göre Tercih Rehberi

Tek bir “en iyi” yaklaşım yok. Doğru tercih sitenin yapısına, ekibin kapasitesine ve önceliklere bağlı.

Senaryo	Önerilen yaklaşım	Neden
Cloudflare kullanan, az sayıda araç, performans öncelikli	Zaraz	Sıfır JS yükü, ücretsiz, kolay kurulum
Çok sayıda entegrasyon, karmaşık trigger mantığı	GTM (client)	En geniş entegrasyon kütüphanesi, esnek trigger sistemi
CAPI zorunluluğu, ITP bypass, veri kontrolü	sGTM	1st-party context, tam veri kontrolü
Google Ads dönüşüm kaybı yaşayan	Gateway + mevcut kurulum	5 dakikada %11 sinyal kurtarma
E-ticaret, yüksek trafik, attribution kritik	Hibrit (Zaraz + server-side event processing)	Edge performansı + server-side veri zenginleştirme
Safari trafiği yüksek, veri kaybı yaşanan	sGTM veya Zaraz + server-side	AFP ve ITP bypass, 1st-party context
Consent Mode v2 uyumu gerekli	sGTM veya Zaraz (yerleşik consent yönetimi)	Sunucu tarafı consent kontrolü, granüler yönetim

Dikkat Edilmesi Gerekenler

• Zaraz: Auto page view yapılandırmasını kontrol edin, SPA davranışına dikkat. Varsayılan ayarlar her site yapısına uygun değil.
• GTM: Marketplace veya platform tarafından sağlanan dataLayer kalitesini test edin, enhanced measurement ayarlarını doğrulayın.
• sGTM: Altyapı maliyetini ve bakım yükünü hesaba katın. Cloud Run faturaları trafik artışıyla birlikte hızla yükselebilir.
• Gateway: Tek başına çözüm değil, mevcut kurulumun yanına eklenti olarak düşünün.
• Consent: Hangi yaklaşımda olursa olsun consent yapılandırması sonuçları doğrudan etkiler. Consent mode’un aktif olduğu ve olmadığı senaryolar arasında ciddi farklar oluşabiliyor.
• Privacy-first alternatifler: GA4 dışında seçenekleri de değerlendirin. Umami ve PostHog gibi araçlar cookie’siz çalışarak consent yükünü azaltabiliyor.

Server-Side Event Processing ile Zaraz’ın Eksiklerini Kapatmak

Zaraz’ın edge performansı güçlü. Ancak test sonuçlarında gördüğüm attribution kaybı, event-level veri bozulması ve platform CAPI entegrasyonlarındaki sınırlamalar tek başına yeterli olmadığını gösteriyor. Bu noktada server-side event processing devreye giriyor.

Temel fikir şu: Zaraz edge’de event toplamaya devam ediyor (sıfır tarayıcı JS yükü korunuyor), ancak toplanan event’ler bir server-side katmana aktarılarak işleniyor, zenginleştiriliyor ve birden fazla hedefe dağıtılıyor.

Kullanıcı tarayıcısı
  → Cloudflare Edge (Zaraz: event toplama, sıfır JS yükü)
    → Scout Collector (batch işleme, zenginleştirme, tekilleştirme)
      → Hedefler: Meta CAPI, GA4 Measurement Protocol, Google Ads, Klaviyo, TikTok...

Bu yaklaşımı dnomia bünyesinde geliştirdiğim Scout ile uyguluyorum. Scout, Zaraz’dan edge’de toplanan event’leri alıp batch olarak işliyor, profil verileriyle zenginleştiriyor ve birden fazla hedefe (Meta CAPI, GA4 Measurement Protocol, Google Ads, Klaviyo gibi) tek noktadan dağıtıyor.

Meta tarafında da benzer bir evrim yaşanıyor. Meta Signals Gateway, CAPI Gateway’in ötesine geçerek sadece Meta değil, Google BigQuery, TikTok, Snapchat ve özel endpoint’lere de veri yönlendirebilen bir hub hâline geldi¹². Çoklu platform kullanan e-ticaret siteleri için tek noktadan dağıtım mantığı güçleniyor.

12 Ocak 2026’da Meta Ads Insights API’deki 7 günlük ve 28 günlük view-through attribution pencereleri kaldırıldı; CAPI’yi kurduktan sonra raw event’leri BigQuery’ye yazıp kendi look-back penceresini kurmanın somut mimarisini Meta Attribution Penceresi Daraldı: BigQuery ile Telafi Katmanı yazısında ele aldım.

Zaraz Eksiklikleri ve Server-Side Çözümleri

Zaraz eksikliği	Server-side çözüm
Event-level attribution kaybı	Server-side UTM ve click ID saklama, profil bazlı zenginleştirme
Geo yanlışlığı (edge IP sorunu)	Gerçek kullanıcı IP’si ile geo çözümleme
CAPI entegrasyon sınırlılığı	Doğrudan Meta, Google Ads, TikTok, Pinterest CAPI desteği
Consent yönetimi karmaşıklığı	Çok katmanlı consent modeli, CMP auto-detection
ITP cookie sınırlaması	Server-set 1st-party cookie (CNAME proxy)

Her Durumda Gerekli mi?

Kısa cevap: hayır. Blog veya kurumsal site gibi basit GA4 takibi yapılan projelerde Zaraz tek başına yeterli. Ancak aşağıdaki senaryolarda server-side katman kaçınılmaz hale geliyor:

• E-ticaret, CAPI zorunluluğu, attribution kritik: Zaraz + server-side event processing veya sGTM gerekli.
• Çoklu reklam platformu (Meta + Google + TikTok): Server-side’ın tek noktadan dağıtım avantajı öne çıkıyor. Her platform için ayrı entegrasyon yerine tek collector üzerinden yönetim.
• Veri zenginleştirme ihtiyacı: Kullanıcı profili, geçmiş satın alma verisi, segmentasyon bilgisi gibi verilerin event’lere eklenmesi gerektiğinde edge tarafı yetersiz kalıyor.

Sonuç

2026’da event tracking’de “client-side yeterli mi?” sorusunun cevabı netleşti: tek başına yeterli değil. Safari 26 AFP, Consent Mode v2 zorunluluğu ve Privacy Sandbox’ın kapanması, server-side veya edge tabanlı yaklaşımları zorunlu kıldı.

Doğru araç hâlâ bağlama bağlı:

• Performans öncelikli, Cloudflare kullanan: Zaraz
• Karmaşık trigger mantığı, çok sayıda entegrasyon: GTM (client) + Gateway
• CAPI, attribution, veri kontrolü: sGTM
• E-ticaret, çoklu platform, veri zenginleştirme: Hibrit (Zaraz/GTM + server-side event processing)

Bu yazıdaki gerçek veri karşılaştırması bir noktayı net gösteriyor: e-ticaret conversion event’leri (purchase, add_to_cart) her iki platformda da %5 içinde tutarlı. Asıl fark attribution, page_view inflation ve tarayıcı kısıtlamalarına dayanıklılıkta ortaya çıkıyor.

Tracking stack’inizi seçerken “en iyisi hangisi?” yerine “benim yapım için hangisi doğru?” sorusuyla başlayın. Cevap genellikle tek bir araç değil, doğru katmanların kombinasyonu oluyor.

Google’ın UCP protokolüyle checkout’un Google yüzeylerinde gerçekleşmesi, site-based pixel’lerin tamamen kör kalması anlamına geliyor. Server-side tracking zorunluluğunu daha da artıran bu gelişmeyi UCP: Agentic Commerce ve E-Ticaret Ekosistemi yazısında inceliyorum.

Ayrıca GA4 ve GTM’in yerleşik scroll tracking’inin neden yetersiz kaldığını ve content-scoped bir alternatifi Scroll Depth Tracking yazısında ele aldık. Kullanıcı tarafı tracking’in ötesinde, geliştirici tarafında da etkileşim verisi toplanabilir: Geliştirici Etkileşim Takibi yazısında Claude Code hook’larıyla dosya okuma/düzenleme örüntülerini nasıl analiz ettiğimi anlattım.

Footnotes

1. Safari 26 Tracking Changes ↩ ↩²
2. Safari 26 Tracking Changes: Impact on Marketing Measurement ↩ ↩²
3. Google Privacy Sandbox Shutdown ↩ ↩²
4. Google Pulls The Plug On Topics, PAAPI And Other Major Privacy Sandbox APIs ↩ ↩²
5. Consent Mode v2 Explained ↩ ↩²
6. About Consent Mode - Google Ads Help ↩ ↩²
7. Cloudflare acquires Zaraz to enable cloud loading of third-party tools ↩
8. Zaraz Use Workers to Make Third Party Tools Secure and Fast ↩
9. Zaraz DataLayer Compatibility ↩ ↩²
10. Traps you should avoid when migrating from GTM to Zaraz ↩
11. Cloudflare Zaraz vs Google Tag Gateway ↩
12. Meta Signals Gateway vs CAPI Gateway ↩ ↩²
13. Google Tag Gateway GCP Integration ↩ ↩²
14. Zaraz Settings Reference ↩
15. Safari ITP - Everything You Need to Know ↩
16. Google Cookie Deprecation U-Turn ↩
17. Google Ads Enhanced Conversions Guide ↩
18. CAPI and Enhanced Conversions Don’t Need Cookies ↩
19. Navigating Consent Mode in GA4 BigQuery Export ↩
20. GA4 BigQuery Export Cost ↩

Önemli Noktalar

• 01 Client-side tracking tek başına güvenilir veri toplamak için artık yeterli değil: Safari 26 AFP, ITP ve ad blocker'lar veriyi %30-40 eksik bırakabiliyor
• 02 Zaraz page_view inflation riski taşıyor: varsayılan ayarlarla session başına 28.3 page_view (GTM'de 3.1)
• 03 E-ticaret conversion event'leri (purchase, add_to_cart) her iki platformda %5 içinde tutarlı
• 04 Consent Mode v2 Temmuz 2025'ten itibaren zorunlu: uygulamayan siteler Google Ads remarketing ve kitle segmentasyonunu kaybediyor
• 05 Google Tag Gateway Ocak 2026'da GCP ve Akamai entegrasyonu kazandı: artık sadece Cloudflare değil
• 06 Tek bir doğru cevap yok: doğru araç sitenin yapısına, ekibin kapasitesine ve önceliklere bağlı

Sık Sorulan Sorular (FAQ)

+ Zaraz, GTM'in yerini alabilir mi?

Performans açısından evet, ancak entegrasyon çeşitliliği, trigger esnekliği ve event-level attribution doğruluğu açısından henüz tam bir alternatif değil.

+ Zaraz ücretsiz mi?

Aylık 1 milyon event'e kadar ücretsiz. Sonrası her 1 milyon event için 5 dolar.

+ Google Tag Gateway ile Zaraz aynı şey mi?

Hayır. Gateway sadece Google etiketlerini proxy'leyen bir araç. Zaraz ise GTM alternatifi bir tag management çözümü. İkisi birlikte kullanılabilir.

+ sGTM mi Zaraz mı tercih etmeliyim?

sGTM veri kontrolü ve CAPI entegrasyonlarında daha güçlü ama altyapı maliyeti var. Zaraz kurulumu kolay ve performans etkisi sıfıra yakın. Ekip kapasitesi ve bütçe belirleyici.

+ Zaraz'ın attribution sorunu düzeltilebilir mi?

Event-level attribution sorunu yapılandırmaya bağlı. Session-level doğru çalışıyor. Server-side event processing ile zenginleştirilebilir.

+ Client-side ve server-side tracking arasındaki temel fark nedir?

Client-side tracking tarayıcıda JavaScript çalıştırarak veri toplar; ad blocker'lara, ITP'ye ve Safari 26 AFP'ye karşı savunmasızdır. Server-side tracking veriyi sunucu veya edge katmanında işler; tarayıcı kısıtlamalarından bağımsızdır ve veri kalitesi daha yüksektir.

+ Consent Mode v2 tracking'i nasıl etkiliyor?

Consent Mode v2 Temmuz 2025'ten itibaren zorunlu. Uygulamayan siteler Google Ads'te remarketing ve kitle segmentasyonunu kaybediyor. Temel modda onay olmadan hiç veri gönderilmiyor; gelişmiş modda anonim ping'lerle modelleme yapılıyor.

+ Küçük bir site için hangi yaklaşım uygun?

Blog veya kurumsal site için Zaraz (Cloudflare kullanıyorsanız) veya GTM tek başına yeterli. Server-side tracking e-ticaret, CAPI zorunluluğu veya çoklu reklam platformu kullanıldığında gerekli hale geliyor.

+ Safari'de cookie'ler neden 7 günde siliniyor?

Safari ITP 2.1'den (2019) beri JavaScript ile oluşturulan cookie'lerin ömrü 7 günle sınırlı. Server-set cookie'ler (Set-Cookie header) bu kısıtlamadan muaf, ancak CNAME/IP uyumsuzluğu tespit edilirse onlar da 7 güne düşürülüyor. Bu nedenle server-side tracking Safari'de güvenilir 1st-party cookie yönetimi için zorunlu.