Her yeni müşteri hesabı farklı bir keşif süreci başlatıyor; kimi oldukça muntazam, kimi birbiri üzerine eklenmiş yama müdahalelerden oluşuyor. Network sinyalleri üzerinden ön bir değerlendirme yapıldığında çoklu event’ler ve eksik parametreler dikkat çekiyor. Ardından etiket kontrolleri için alınan erişimlerle birlikte Tag Manager açıldığında, önceki müdahalelerden ve farklı zamanlardan arta kalan naming convention’larla karşılaşılıyor. Preview edildiğinde GA4 event’leri birbirine benzer trigger’lar sebebiyle çift sayılıyor, purchase event’i transaction_id olmadan gönderilmiş, Meta Pixel var ama CAPI yok, consent banner ya hiç yok ya da “accept all” default’uyla çalışıyor. BigQuery export’un sadece Analytics 360 müşterilerinde olduğu sanılıyor, halbuki ücretsiz.
Bu tablo bir üretim değil, devralınan bir durum. İçerideki standart zaten var, her müşteri hesabı onu kendi legacy’siyle yeniden hizalamayı gerektiriyor. Farklı consent tool’u, farklı GTM versiyonu, farklı developer kararlarıyla gelen bir hesapta standardı yeniden kurmak vakit ve karar maliyeti yaratıyor. 2026’da bu kurulum artık “ileri seviye” değil, temel: browser cookie tabanlı ölçümün sonu yaklaşıyor (iOS ITP, Safari cross-site cookie blokajı, ad blocker’lar, AI engine checkout’ları, Google UCP, ChatGPT agent flow) ve server-side tracking, Consent Mode v2, first-party data warehouse olmadan Google Ads teklif algoritmaları düzgün çalışmıyor, Meta’da event match quality düşüyor.
Bu rehber, ajans tarafında standardize edilebilir bir stack mimarisi tanımlıyor: CASA Framework. Beş katman, beş net sorumluluk. Consent (ziyaretçi rızası ve sinyal yönetimi), Analytics (GA4 client + BigQuery + self-hosted katman), Server-side (sGTM ile toparlama ve platform dağıtımı), Attribution (kanal katkı ölçümü) ve ajans-spesifik Multi-Client Governance (template, onboarding, versiyon yönetimi).
KVKK ve GDPR burada bir kere net: TR odaklı KVKK açık rıza zorunluluğu ile AB trafiği için GDPR artı ePrivacy kapsamı farklı konular. Giriş ve spesifik kutularda regülasyon referansları geçer; teknik bölümlerde “consent signal”, “consent state”, “first-party data” gibi regülasyon-nötr dil kullanacağım.
CASA Framework: Neden 5 Katman?
Her katman bir öncekinin çıktısına dayanıyor. Sıra değişince kurulum çöküyor:
| Katman | Ne Yapıyor | Çıktı |
|---|---|---|
| Consent | Ziyaretçi rızasını yakalar, platformlara sinyal iletir | ad_storage, analytics_storage, ad_user_data, ad_personalization state |
| Analytics | Client’ta event toplar, warehouse’a yazar | GA4 event stream + BigQuery export |
| Server-side | Client event’lerini toparlar, zenginleştirir, platformlara dağıtır | sGTM üzerinden dağıtılan CAPI, Enhanced Conversions, Ads click ID |
| Attribution | Kanal katkılarını hesaplar, raporlar | GA4 attribution modelleri + BigQuery SQL raporları |
| Multi-Client Governance | Ajans tarafında tekrar üretilebilirliği sağlar | Container template, onboarding checklist, versiyon yönetimi |
Consent olmadan analytics veri toplayamıyor; analytics olmadan server-side’da iletecek event yok; server-side olmadan attribution güvenilir sinyal bulamıyor; governance olmadan her müşteride sıfırdan kurma maliyeti oluşuyor. Framework’ün değeri katman isimlerinde değil, sıralamada.
Katman 1: Consent (Tarayıcıda Veri Toplamadan Önce)
Consent Mode v2’nin basic ve advanced modları, modellenen dönüşüm recovery oranları ve Google Ads teklif algoritmaları üzerindeki etkisi ayrı bir derinlikte ele alınmış konu; burada yineleme yapmayacağım. İlgili diğer konular ve detaylar için Consent Mode v2 ve Ölçüm Etkisi ve Consent Sonrası Reklam Ölçümü yazılarına göz atılabilir.
Ajans tarafında kritik olan karar consent tool seçimi. Tool piyasası dört kategoriye ayrılıyor (Consent 4-Category Matrix):
| Kategori | Tool Örnekleri | Ajans İçin Seçim Ekseni |
|---|---|---|
| Yerli (TR) | Efilli, Mobildev, Consentify, Cookieyes TR | KVKK odaklı metin, TR destek, yerel fatura |
| Global premium | Cookiebot, OneTrust, Termly, Osano, Iubenda | Çok dilli site, GDPR sertifikasyonu, IAB TCF 2.2 |
| Cloudflare native | Zaraz | CF altyapısı kullanan müşteri, edge katmanında consent routing |
| Self-hosted | Klaro, CookieConsent (Orest Bida), Civic, tarteaucitron | Veri egemenliği, abonelik maliyeti istemeyen müşteri |
Ajans multi-client config notu: aynı consent tool’unu farklı müşterilere farklı marka stili ve event mapping ile uygulamak için bir master config template tutmak ajans tarafında tekrarı ortadan kaldırıyor. Cookiebot ve OneTrust multi-site plan üzerinden, Klaro ise Git repo template’i üzerinden bunu destekliyor.
Katman 2: Analytics (Ne Ölçüyorsun?)
GA4 client-side temel hijyen (naming convention, transaction_id zorunluluğu, duplicate event önleme) ve source/medium attribution’ın first-party cookie üzerinden debug edilmesi ayrı yazılarda detaylı: GA4 Source Medium Debugging, GA4 Attribution Raporları Direct Şişmesi. Client-side tarafı bu iki spoke’a devrediyorum.
Umami’nin GA4’e alternatif değil, first-party backup katmanı olduğu ayrımı önemli. Ads platformlarının GA4 conversion’larına bağımlılığı Umami’yi tek başına yeterli kılmıyor. Detay ve karşılaştırma: Umami, PostHog, GA4 Karşılaştırma.
BigQuery multi-client schema kararı ajans tarafında ayrı dataset vs tek dataset artı property dimension tartışmasıdır:
| Yaklaşım | Avantaj | Dezavantaj | Önerilen Senaryo |
|---|---|---|---|
| Müşteri başına ayrı dataset | Faturalandırma temiz, müşteri bırakınca devretmek kolay, IAM seviyesinde izolasyon | Sorgu sayısı artıyor, dataset yönetim yükü ajansta | 10’dan az müşteri, müşteriler farklı GCP projelerinde |
Tek dataset artı property_id dimension | Tek sorguda cross-client karşılaştırma, ortak dashboard’lar | Müşteri bırakırsa veri ayırma süreci zor, hatalı SQL tüm müşterilere sızar | 10+ müşteri, ajans merkezli dashboard’lar, müşteriler GCP’yi kullanmıyor |
| Hybrid: müşteri dataset artı ajans özet dataset | İzolasyon artı cross-client özet | İki yerde şema senkronizasyonu gerekir | Operasyonel ölçek ve müşteriye ayrı erişim birlikte isteniyorsa |
BigQuery export’un Analytics 360 gerektirmediği, GA4 free’de zaten mevcut olduğu müşteri tarafında yaygın bir yanlış bilgi. Kurulum: GA4 > Admin > BigQuery Links. Günlük export default, streaming opt-in.
BigQuery üzerinde multi-channel attribution SQL örüntüleri için BigQuery Attribution Analizi canlı referans. Meta CAPI penceresi ve BigQuery telafi katmanı: Meta Attribution Penceresi BigQuery Telafi.
Katman 3: Server-Side (Toparlama ve Güvenli Dağıtım)
sGTM hosting kararı (Cloud Run vs Stape vs Taggrs vs Addingwell vs self-host Docker) ayrı bir karar matrisi yazısı halinde: sGTM Hosting Karar Matrisi. Kurulum adımları için: GTM Server-Side Tagging. Bu iki yazı karar ve kurulum eksenlerinde tamamlayıcı.
Bu katmanda ajans perspektifiyle üç nokta öne çıkıyor:
sGTM runtime gerçeği. sGTM, Google’ın yayınladığı Docker image üzerinde çalışan Node.js uygulaması (gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable). V8 isolate platformlarda (Cloudflare Workers, Deno Deploy, Vercel Edge, Netlify Edge) çalışmıyor. Default ajans önerisi: hızlı başlangıç için Cloud Run, bakım istemeyen müşteri için Stape, EU veri odağı için Taggrs/Addingwell, veri egemenliği için self-host Docker artı Caddy.
Same-origin proxy: Cloudflare Workers. CF Workers sGTM’nin runtime’ı değil, önündeki proxy katmanıdır. site.com/metrics endpoint’i müşteri domain’ine CF Worker ile oturtulup arkada Cloud Run’a yönlendirildiğinde Safari ITP 7 günlük cookie kısıtlaması bypass ediliyor, ad blocker listelerinde görünmeyen bir first-party endpoint elde ediliyor. Google Tag Gateway pattern ile aynı. Stape ve Taggrs bu kurulumu kendi panellerinden de sağlıyor.
Facebook CAPI sGTM üzerinden. Client-side Pixel artı sGTM üzerinden CAPI dual-send, event_id üzerinden deduplication, user_data hashing. Hedef event match quality 7 üzeri. sGTM tarafında Meta’nın resmi Server-Side Tag Template’i stable.
Scout bir sGTM değil. Scout, sGTM’nin yerine geçen bir proje değil, farklı bir katmanda çalışan bir custom event pipeline. Esnek event şeması ve multi-destination fan-out gerektiren niş ihtiyaçlar için. Ajans stack önerisinde default sGTM; Scout tarzı pipeline opsiyonel ileri seviye katman.
Katman 4: Destinations (Veriyi Hedeflere Yazma)
Server-side çıktı bir yere yazılmazsa stack’in değeri yok. Destinations katmanı iki ana akıştan oluşuyor: reklam platformları (Google Ads, Meta, TikTok) ve email/marketing automation.
Reklam platformları tarafı sGTM template’leri ile standardize: Enhanced Conversions, Facebook CAPI, TikTok Events API, Pinterest CAPI, LinkedIn CAPI template’leri resmi. Ajans tarafında kritik olan dataLayer’da user_data bloğunun consent state’ine göre filtrelenmesi.
Email tarafını ajans perspektifiyle burada açıyorum. Newsletter ve marketing automation stack’ini üç kategoride sekiz çözümle değerlendiriyorum:
| Kategori | Tool | Liste Boyutu | Fiyat Mantığı | Ajans Senaryosu |
|---|---|---|---|---|
| Managed e-ticaret | Klaviyo | 100K+ | Contact bazlı | Shopify müşterisi, revenue attribution ve lifecycle flow öncelik |
| Managed e-ticaret | Omnisend | 50K+ | Contact bazlı | Shopify müşterisi, SMS kanalı önemli, Klaviyo pahalı geliyorsa |
| Managed e-ticaret | Mailchimp | 10K-100K | Contact bazlı | Genel pazarlama, e-ticaret öncelik değil, tanıdık UI |
| Developer-first | Resend | Her boyut | API request bazlı | Transactional email, custom product, developer yönetimli müşteri |
| Developer-first | Loops | 10K-50K | Contact bazlı | SaaS müşterisi, lifecycle email, headless |
| Developer-first | Beehiiv / Kit | İçerik newsletter | Liste bazlı | İçerik markası, content newsletter, publisher müşteri |
| Self-hosted | Listmonk | Sınırsız | VPS maliyeti | Veri egemenliği önceliği, content newsletter, lifecycle flow basit |
| Self-hosted | Mautic | 10K-100K | VPS artı ops | B2B lead nurturing, açık kaynak CRM entegrasyonu, yoğun otomasyon |
Ajans tarafında default seçim: Shopify e-ticaret müşterisi için Klaviyo veya Omnisend, SaaS müşterisi için Loops, content/yayıncı müşteri için Beehiiv/Kit, veri egemenliği önceliği olan müşteri için Listmonk self-hosted. Kararın tek bir metrik üzerinden verilmediği senaryolar çoğunlukta; müşteriyle liste büyüklüğü, attribution ihtiyacı (revenue attribution gerekiyor mu), veri egemenliği beklentisi ve in-house teknik kapasiteyi konuşmak şart.
Kendi kullandığım iki örnek: Peyk ceaksan.com içerik newsletter’ı için Listmonk self-hosted (content brand, lifecycle flow yok), Scout ise Klaviyo ve Omnisend’e event fan-out yapıyor (e-ticaret lifecycle ve content newsletter birleşimi).
Katman 5: Attribution (Kanalları Karşılaştır)
GA4 2026 attribution modelleri (data-driven default, last-click bypass, paid vs organic search ayrımı) ve BigQuery üzerinde multi-channel SQL örüntüleri canlı cluster’larda: BigQuery Attribution Analizi, GA4 Veri Kontrolleri Konsolidasyonu, GA4 Attribution Raporları Direct Şişmesi. Bu yazılar model karar ağacını ve SQL pattern’lerini hâlihazırda kapsıyor.
Bu katmanda ajans perspektifiyle tek ek: aylık müşteri raporu şablonu. Raporun üç katmanı:
- Kanal katkısı (top-down): GA4 data-driven attribution modeline göre kanal bazlı conversion ve revenue.
- Platform özdeğerlendirmesi (bottom-up): Google Ads, Meta, TikTok’un kendi panellerindeki conversion sayıları. Farklılık varsa raporda not.
- Bağımsız doğrulama: BigQuery üzerinden last non-direct click modelini de hesaplayıp data-driven ile yan yana koymak. Ajans tarafında büyük kanal sapmalarını açıklamak için.
Birden fazla müşterinin attribution raporunu tek yerde birleştirmek ajans tarafında operasyonel bir sürtüşme; Scout’u bu ihtiyaç için kurdum.
CASA Katmanlarını Hangi Sırayla Kurmalısın?
14 Günlük Ajans Onboarding Protokolü. Yeni müşteri hesabında sıra:
- Gün 1-2 Consent: Banner deploy, Consent Mode v2 default “denied”, GTM consent mode aware trigger’lar.
- Gün 3-4 Analytics client-side: GA4 event naming audit, enhanced ecommerce
purchaseeventtransaction_idile, duplicate trigger temizliği. - Gün 5 Analytics warehouse: BigQuery export açılır, dataset convention kararı, retention süresi müşteriyle konuşulur.
- Gün 6-9 Server-side: sGTM deploy (Cloud Run veya Stape), CF Workers same-origin proxy, Meta CAPI dual-send artı
event_iddedup, Google Enhanced Conversions, TikTok Events API. - Gün 10-12 Attribution: GA4 model karar kutuları, BigQuery SQL pattern deploy, aylık rapor şablonu.
- Gün 13-14 Multi-client governance: Container template ajans library’sine eklenir, onboarding checklist bu müşteri için güncellenir, yeni convention’lar master config’e geri port edilir.
Ajans-spesifik notlar:
- Kontratta “müşteri platform ekibi dataLayer event push’larından sorumludur, gecikmeler SLA’yı sıfırlar” maddesi protokolün yürümesi için kritik.
- In-house teknik lead olmayan müşteride bu protokol 14 günde tamamlanmıyor; ilk haftadan sonra kalıcı bakım kontratı şart.
- Consent ve analytics client-side paralel yürüyebilir. Server-side zorunlu olarak ilk ikisinden sonra. Attribution veriyi 7-14 günde kazanır, en sona.
Sık yapılan sıra hataları: CAPI önden (consent henüz yokken CAPI dual-send kurulursa event match quality düşük ve ad_user_data denied trafikte hatalı event), BigQuery sonraya (tarihsel veri retroaktif gelmiyor, geç açılan export ay sonrası karanlık bırakır), attribution müşteri isteyince (mimari karar attribution ihtiyacı duyulmadan verilmiş olmalı; sonradan model kararı tek başına iş görmüyor).
Multi-Client Governance (Ajans-Spesifik Katman)
İlk dört katman zaten sektörel. Ajans farkı beşinci katmanda.
GTM container template yönetimi. Master container’da: event naming (snake_case purchase, add_to_cart, generate_lead), custom dimension convention (cd_customer_tier, cd_product_category), trigger filter pattern’leri, consent-aware variable’lar. Her müşteri yeni container’ına bu template import edilir, müşteriye özgü trigger’lar üstüne eklenir. Master template versiyonlanır (v2.3.1), breaking change olduğunda müşterilere upgrade path dokümantasyonu.
sGTM container izolasyonu. Her müşteri için ayrı GTM Server container ama paylaşımlı sGTM hosting altyapısı (tek Cloud Run projesi, müşteri başına ayrı service). Stape veya Taggrs kullanıyorsan zaten hesap içinde container başına ayrık yapı hazır.
Devir ve vendor lock-in. Self-hosted parçalar (Umami instance, Listmonk instance, kendi pipeline’ın varsa) için müşteriye devir prosedürü baştan dokümante. Müşteri ajansı bıraktığında stack’i bırakmıyor, taşıyor; ajans tarafında bu duruş kredibilite. GCP projesi zaten müşterinin; BigQuery data müşteri mülkü; sGTM Docker image source’u Google’ın public container registry’sinde.
Stack’in Canlı Örnekleri: Peyk ve Scout
İki örneği burada açıyorum çünkü soyut framework’ü somut örnek olmadan anlatmak zor.
Peyk. ceaksan.com için kurduğum self-hosted newsletter altyapısı. Listmonk üzerinde çalışıyor, Coolify ile deploy edildi, Resend SMTP. Per-post newsletter cluster sistemi ile her yazının kendine özgü CTA metnini taşıyor. A/B test için heading/subtitle override frontmatter’da. CF Workers collection endpoint’i ile subscribe form’ları same-origin çalışıyor, ad blocker tarafında görünmüyor.
Scout. DNOMIA tarafında kurduğum multi-client attribution ve event pipeline. Topladığı eventleri belirlenen destination’lara dağıtır. Esnek event şeması (her müşteri kendi custom event’ini tanımlayabilir), destination başına retry policy, event_id üzerinden dedup. Scout’un varoluş sebebi: ajanslar için birden fazla müşterinin ve müşterilere ait mağazaların event verisini tek dashboard’da izleyebilmek. sGTM bu senaryoyu destekliyor ama multi-client fan-out ve custom destination yazımı için Scout daha esnek ve pratik.
Peyk ve Scout CASA stack’inin parçası değil, yanında duran örnekler. Bir ajans stack’i bu iki projenin üzerine inşa edilmez; bir ajans stack’i sGTM artı Klaviyo/Omnisend üzerine kurulur. Peyk ve Scout custom pipeline gerektiren niş senaryolarda opsiyonel bir katman.
Kapanış
CASA Framework ajansın zaten bildiği parçaları tek bir çerçevede toplayıp yeni müşteri hesabına taşıma maliyetini düşüren bir yapı. Beş katman, net sıralama, ajansın kendi tool seçimleri üzerinde çalışır. 14 Günlük Onboarding Protokolü framework’ü operasyonel hale getiriyor; Multi-Client Governance katmanı framework’ü ajans ölçeğinde tekrarlanabilir kılıyor.
Bu yazı bir hub; her katmanın teknik detayı ayrı spoke’larda. Yeni müşteri hesabında CASA sırayla yürüdüğünde 14 günde çalışan bir stack’e dönüşüyor, üzerine müşteriye özgü event’ler ve raporlar ekleniyor.
- 01 CASA Framework beş katmandan oluşur: Consent, Analytics, Server-side, Attribution artı ajans-spesifik Multi-Client Governance. Her yeni müşteri hesabına taşınabilir standart.
- 02 Server-side tagging 2026'da temel, ileri seviye değil. Browser cookie tabanlı ölçüm iOS ITP, Safari cross-site cookie bloku ve ad blocker'lar karşısında giderek sınırlı.
- 03 sGTM runtime'ı Docker artı Node.js'tir. Cloudflare Workers yalnızca sGTM'nin önünde same-origin proxy olarak çalışır, runtime olamaz.
- 04 Ajans farkı teknoloji seçiminde değil, Multi-Client Governance katmanında: container template'leri, naming convention, versiyon yönetimi, 14 Günlük Onboarding Protokolü.
- 05 Newsletter stack seçimi liste büyüklüğü, attribution ihtiyacı ve veri egemenliği ekseninde; Klaviyo/Omnisend e-ticaret, Listmonk/Mautic self-hosted, Resend/Loops developer-first.
+ Ajans olarak sGTM'yi her müşteri için ayrı mı kurmalıyım?
Default yaklaşım: her müşteriye ayrı GTM container ve ayrı sGTM endpoint. Altyapı paylaşılabilir (aynı Cloud Run projesi, aynı Stape hesabı), ama veri izolasyonu için container seviyesinde ayrım şart. Detay: sgtm-hosting-karar-matrisi.
+ sGTM'yi Cloudflare Workers'da koşturabilir miyim?
Hayır. sGTM Google'ın yayınladığı Docker artı Node.js container'dır. Cloudflare Workers V8 isolate runtime'dır, Node.js çalıştıramaz. CF Workers yalnızca sGTM'nin önünde same-origin proxy olarak çalışır (Google Tag Gateway pattern). Hosting için Cloud Run, Stape, Taggrs, Addingwell veya self-host Docker.
+ Consent Mode v2 basic mi advanced mı?
Consent rate'in yüksek olduğu (%70+) hesaplarda basic yeterli. TR e-ticaret'te consent rate genelde %60 altı; bu durumda advanced mode modellenen dönüşümlerle %15-25 recovery sağlar. Trafiği düşük hesaplarda modelleme eşiği tutmayabilir.
+ Self-hosted Umami GA4'ün yerine geçer mi?
Ajans hesaplarında hayır. Ads platformları (Google Ads, Meta) GA4 conversion'larına bağımlı çalışıyor. Umami complementary katman: first-party backup, consent bağımsız temel trafik ölçümü, ajansın Google'dan bağımsız doğrulama katmanı.
+ Listmonk self-hosted Klaviyo'nun yerini alır mı?
Newsletter broadcast ve basit otomasyon için evet. E-ticaret revenue attribution, lifecycle flow, segment otomasyonu, SMS kanalı için Klaviyo veya Omnisend gerekir. Listmonk content brand ve bilgilendirme newsletter'ı için uygun, e-ticaret lifecycle motoru değil.
+ Müşteri ajansı bırakırsa kurduğun stack ne oluyor?
GTM, sGTM, BigQuery müşterinin mülkü, devredilebilir. Self-hosted parçalar (Umami instance, Listmonk instance) için devir prosedürü baştan dokümante edilmeli. Vendor lock-in'e karşı net duruş ajansın kredibilitesini artırır, kaybettirmez.