sGTM Hosting Karar Matrisi: Cloud Run, Stape ve Self-host Karşılaştırması

Önceki yazıda sGTM (server-side Google Tag Manager) için kurulum adımlarını Cloud Run, Stape ve Docker self-host üzerinden anlattım. Bu yazı aynı konunun karar tarafı: hangi senaryoda hangi hosting, self-host için production-ready Caddy pattern’ı, ajans multi-client kurulumu ve Cloudflare Workers’ın gerçek rolü.

Hosting seçimi tool ismiyle değil, üç ekseni birlikte değerlendirerek verilir: bakım kapasitesi, veri egemenliği, trafik öngörülebilirliği. Aşağıda önce üç seçeneği bu eksenlere göre karşılaştırıyor, sonunda senaryolara göre bir karar matrisi çıkarıyorum.

sGTM Runtime Gerçeği

Kararın temeli: sGTM bir Docker imajıdır. Resmi imaj gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable.¹ Release notes’a göre 4.0.0 sürümünden (10 Kasım 2025) beri base imaj gcr.io/distroless/nodejs24-debian13, yani distroless Debian 13 üzerinde Node.js 24. Önceki 3.x sürümleri Node.js 22 ve Debian 12 kullanıyordu.²

Runtime ihtiyacı: Docker imajı çalıştırabilen bir container platformu. Cloud Run rehberindeki varsayılan kaynak instance başına 1 vCPU ve 0.5 GB bellek.³ Manual setup rehberi üst sınırı açıkça koyuyor: “The provisioned servers should have at most 1 vCPU. Additional vCPUs are not utilized and affect autoscaling negatively.”¹

Sonuç: sGTM hosting listesi Docker + Node.js koşturabilen platformlarla sınırlı. Bu liste şunları içermez: Cloudflare Workers, Vercel Edge Functions, Netlify Edge Functions. Hepsi V8 isolate platformlarıdır; Docker imajı çalıştıramaz, uzun ömürlü Node.js server tutamaz. Cloudflare’in ayrı ürünü Containers Docker imajı çalıştırabiliyor, ama sGTM için belgelenmiş bir kurulum yolu değil.⁴ Cloudflare Workers sGTM’nin önüne konabilir; aşağıda ayrı bölümde ele alıyorum.

Üç Seçenek, Üç Profil

Seçenek	Managed?	Region seçimi	Bakım yükü	Öngörülebilir maliyet
Google Cloud Run	Yarı-managed	Geniş (GCP region’ları)	Düşük	Hayır (kullanıma göre)
Stape	Tam managed	Stape’in sunduğu lokasyonlarla	Çok düşük	Evet (tier sabit)
Self-host Docker	Hayır	Tamamen esnek	Yüksek	Evet (kapasite içinde)
Google App Engine	Yarı-managed	Geniş (GCP region’ları)	Orta	Hayır

App Engine güncel dokümantasyonda Cloud Run lehine geri plana düştüğü için bu yazıda ayrı ele almıyorum; Cloud Run önerisi onu da kapsar. Esas karar Cloud Run, Stape ve self-host arasında.

Cloud Run

Cloud Run, sGTM için Google’ın önerdiği yol. GTM arayüzündeki automatic provisioning doğrudan Cloud Run’a deploy eder; Cloud Run setup rehberi hem otomatik hem manuel kurulumu anlatır.³

Güçlü yönleri:

• GCP servisleriyle native entegrasyon: Secret Manager (container config ve auth token yönetimi), IAM (müşteri proje izolasyonu), Cloud Logging ve Cloud Trace (debug için ek toplama katmanına gerek yok).
• Auto-scaling yerleşik: instance sayısı trafiğe göre ayarlanır. Rehberdeki örneğe göre 2-10 sunucu, tag karmaşıklığına bağlı olarak saniyede 35-350 isteği karşılar.³
• Region çeşitliliği: Frankfurt, Warsaw veya Milan gibi AB region’ları.
• Dokümantasyon ve pratisyen içeriği en zengin olan seçenek: Mark Edmondson ve Square Developer Blog gibi kaynaklar kurulumu Cloud Run üzerinden anlatır.⁵⁶

Zayıf yönleri:

• Maliyet kullanıma bağlı. Google’ın rehberi veri kaybı riskini azaltmak için production’da en az 2 instance öneriyor; bu, trafik düşük olsa da sabit bir alt maliyet demek, preview sunucusu buna ayrıca eklenir.³ Trafik arttıkça instance sayısı ve fatura büyür; kampanya günlerinde sabit tier modellerinin avantajı görünür hale gelir.
• Google Cloud billing kurulumu bir ajansın müşteri hesabında dokümantasyon ve onay süreci gerektirir. Müşterinin GCP project’i yoksa yeni proje açılması ek bir onboarding adımıdır.
• Cold start: min instance 0 tutulursa ilk istekte gecikme olur. Google production için en az 2 instance öneriyor; min 0, bu önerinin dışına çıkan bir maliyet tercihi.
• Preview server ayrı deploy edilir. Manual setup rehberi tam 1 preview sunucusu ister ve autoscaling’in 1 instance’ın üstüne çıkarılmamasını söyler.¹ Cloud Run’da bu, max instance değeri 1 olan ayrı bir service demek.

Kime uygun: Google ekosisteminde derinleşmiş ajans, GCP’ye alışkın teknik ekip, değişken trafik ve ölçek ihtiyacı, GA4 BigQuery export’u zaten kullanan müşteri hesapları.

Kime değil: Bakım süresine ayıracak kapasitesi olmayan ajans, müşteri tarafında GCP kurulumu uzun süren operasyonlar, sabit aylık maliyet zorunlu senaryolar.

Stape

Stape, sGTM hosting’e odaklanan managed bir hizmet. Container onların altyapısında çalışır; kullanıcı container config ve tag mapping ile ilgilenir.⁷

Güçlü yönleri:

• Sıfıra yakın ops. Docker, IAM, billing gibi katmanlarla uğraşılmaz.
• Region seçimi: AB dahil birden fazla lokasyon.
• “Power-ups” adıyla hazır ek özellikler sunar (Cookie Keeper, Custom Loader gibi); elle kurulduğunda zaman alan işlevleri panelden açar.⁸
• Preview container ayrı yönetilir, konfigürasyon UI üzerinden.
• Custom loader, ad blocker’lara karşı dayanıklılık için kullanılır.

Zayıf yönleri:

• Pricing tier bazlı; trafik üst limite dayandığında tier yükseltme gerekir. İstek kotasına yalnızca tracking hit’leri değil, script yüklemeleri (gtm.js, gtag.js), preview oturumları ve bot istekleri de sayılır.⁸
• Power-up’lar plan katmanına bağlı; ihtiyaç duyulan bir özellik (örneğin Multi Domains) trafik gerektirmese de üst plana geçmeyi gerektirebilir.⁸
• Abonelik site başınadır: her site için ayrı container ve ayrı plan gerekir, tek abonelik birden fazla siteye bölünemez.⁸ Ajans tarafında maliyet müşteri sayısıyla birlikte artar.
• Container image düzeyinde değişiklik yapılamaz; custom logic için Cloud Run veya self-host’a göre daha sınırlı esneklik.
• Stack Stape üstüne kurulduğunda taşıma maliyetli.

Kime uygun: Birden fazla müşteri yöneten ve müşteri başına planı müşteriye yansıtabilen ajans, bakıma gidecek zamanı kreatif ve strateji işine ayırmak isteyen ekip, EU region’ın yeterli olduğu hesaplar.

Kime değil: Veri egemenliği kritik müşteriler (finans, kamu, sağlık), custom container logic isteyen ileri kurulumlar, trafiği tier sınırlarını sık aşan, dolayısıyla sabit fiyat avantajı kalmayan hesaplar.

Self-host Docker

Kendi sunucunda Docker imajını koşturmak. Paolo Bietolini production-ready pattern’ı paylaştı: Docker Compose ve Caddy reverse proxy.⁹ Pratikte iki katman:

Production pattern: Docker Compose ile iki container (preview + tagging), ikisi de 127.0.0.1 port binding, Caddy reverse proxy ile HTTPS terminasyonu ve subdomain routing (sgtm.site.com → tagging, sgtm-preview.site.com → preview). Kritik Caddy notları: Bietolini’ye göre Preview mode bazı durumlarda yanıtı 20 saniyeye kadar geciktirir, bu yüzden Caddy timeout’unu 30 saniyeye çeker; cache kapalı olmalı (Preview cache’lenmiş response’la çalışmaz); X-Real-IP ve X-Forwarded-For header’ları container’a geçirilmeli.

Altyapı: Hetzner Cloud gibi bir sağlayıcıda AB lokasyonlu VPS, Caddy (otomatik Let’s Encrypt), Docker. Multi-app yöneten bir ortamsa Coolify veya Dokploy gibi PaaS katmanı eklenebilir; ama sGTM tek servis olduğu için doğrudan docker compose + Caddy genelde yeterli ve daha küçük bir attack surface sunar.

Kurulum özü (Paolo Bietolini pattern’ından sadeleştirilmiş):

# docker-compose.yml
services:
  gtm_prod:
    image: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
    environment:
      CONTAINER_CONFIG: ${CONTAINER_CONFIG}
      PREVIEW_SERVER_URL: ${PREVIEW_SERVER_URL}
    ports:
      - "127.0.0.1:8081:8080"
    restart: always

  gtm_preview:
    image: gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable
    environment:
      CONTAINER_CONFIG: ${CONTAINER_CONFIG}
      RUN_AS_PREVIEW_SERVER: "true"
    ports:
      - "127.0.0.1:8082:8080"
    restart: always

Container config string sGTM arayüzünde Admin > Container Settings > Manual Provisioning altında bulunur. Caddy konfigürasyonu, SSL ve log rotate detayları için Paolo Bietolini’nin rehberine bakabilirsin.⁹

Lokal debug: sGTM’yi kendi makinende çalıştırmak istiyorsan Simo Ahava’nın docker-compose stack’i işini görür.¹⁰ Resmi imaj yalnızca linux/amd64 olarak yayımlandığı için Apple Silicon Mac’lerde emülasyon gerekir; Colima ile kurulum dahil adımlara sGTM kurulum rehberinde değindim.

Güçlü yönleri:

• Sunucunun ve logların nerede tutulduğu bilinir; veri egemenliği sunucunun bulunduğu ülke kadardır. Sağlayıcının adı lokasyonu garanti etmez: Hetzner’de Almanya veya Finlandiya lokasyonu seçildiğinde sunucu AB’de olur, ama Hetzner’in ABD ve Singapur lokasyonları da var.¹¹
• Maliyet öngörülebilir: sunucu kapasitesi ve pakete dahil trafik kotası içinde trafik ek fatura üretmez; kota aşımı ayrıca ücretlendirilir.¹² İşletme emeği bu hesabın dışında kalır.
• Özelleştirme sınırı yok. Docker image’ı fork’lanabilir, custom middleware eklenebilir.
• Denetimde aradaki işleyici sayısı azalır, Stape gibi bir üçüncü taraf zincire girmez. Yurt dışı aktarım sorusu ise sunucu Türkiye dışındaysa ve sGTM veriyi Google, Meta gibi platformlara ilettiği sürece yerinde kalır.

Zayıf yönleri:

• Patch yönetimi, security update, monitoring, backup, SSL renewal sorumluluk alanına girer (Caddy SSL’yi otomatik yeniler; diğer katmanlar manuel).
• Auto-scaling manuel. Trafik ani yükseldiğinde VPS kapasitesi yetmezse servis kesintisi olur.
• Örnekteki Compose düzeni tek production ve tek preview container çalıştırır. Preview production’ın yedeği değildir; tek sunucu durduğunda tagging de durur.
• Preview ve prod ayrımı, reverse proxy, firewall kurulumu manuel.
• sGTM imaj güncellemeleri manuel takip edilmeli; Node.js major version geçişlerinde (release notes’taki geçişler 16, 18, 22 ve 24; hepsi çift numaralı LTS sürümler) test katmanı gerekir.²

Kime uygun: Küçük müşteri portföyü yöneten ajans, DevOps ekibi hazır, veri egemenliği müşteri sözleşmesinde, sabit maliyet zorunlu.

Kime değil: DevOps kapasitesi olmayan ajans, müşteri çeşitliliği yüksek (farklı trafik profilleri farklı boyutlandırma gerektirir), hızlı onboarding gereken senaryolar.

Kendi Bulut Hesabında Docker: AWS ve Azure

Aynı Docker imajı AWS ECS/Fargate veya Azure Container Apps gibi yönetilen container platformlarında da çalışır. Bu VPS ile aynı bakım modeli değil: işletim sistemi ve Docker host’u sağlayıcıya geçer; sGTM konfigürasyonu, imaj güncellemesi, domain, kapasite ve izleme ekipte kalır. Kurulum da eskisi kadar elle değil: ECS Express Mode, Fargate servisini, load balancer’ı ve autoscaling’i tek adımda kurar.¹³ Azure tarafında Container Apps için hazır betikler var.¹⁴ Hazır bir betiğin çalışması ise müşteri izolasyonu, monitoring ve devir süreçlerinin çözüldüğü anlamına gelmez. Bu yollar, müşterinin zaten bir AWS veya Azure hesabı ve bu ortamı işleten bir ekibi varsa anlamlı.

Ek Katman: Cloudflare Workers ile Same-Origin Proxy

Cloudflare Workers sGTM ekosisteminde sGTM’nin önüne konan transparent proxy. Google tag gateway for advertisers da aynı first-party serving fikrine dayanır, ama sGTM gerektirmez: istekleri CDN (Content Delivery Network) katmanında yönlendirir ve yönetilecek bir sunucu yoktur.¹⁵

Ne yapar:

Ziyaretçi tarayıcısı https://site.com/metrics yolunu çağırır. CF Worker bu isteği alır, Cloud Run (veya Stape veya self-host) üzerinde koşan sGTM endpoint’ine iletir. Response geri gelir, Worker tarayıcıya döndürür. Kullanıcı için tüm analytics trafiği site.com domain’inde kalıyor gibi görünür.

Ön koşul: sitenin DNS (Domain Name System) kaydı Cloudflare’de ve proxy’li olmalı; Worker route’u yalnızca Cloudflare’in önünde durduğu domain’de çalışır.

Ne kazandırır:

• First-party cookie: Tarayıcı site.com cookie’sini set eder, cross-site kısıtlaması tetiklenmez.
• Safari ITP (Intelligent Tracking Prevention): Safari, cookie’yi set eden yanıt üçüncü taraf bir IP’den geliyorsa ya da subdomain farklı bir domain’e CNAME ile çözümleniyorsa server-set cookie’leri de 7 güne indiriyor.¹⁶¹⁷ Same-origin proxy’de istek sitenin kendi domain’ine gider ve yanıt sitenin Cloudflare IP’lerinden döner; iki kontrol de sorun çıkarmaz. IP eşleşme kuralının ayrıntısı kurulum rehberinde.
• Latency: Worker isteği Cloudflare ağında kullanıcıya yakın bir noktada alır, ama cache kapalı olduğu için yanıt yine origin’deki sGTM’den gelir. Kazanım latency değil; araya bir hop eklenir.
• Ad blocker dayanıklılığı (kısmi): Bilinen GA ve Meta endpoint path’leri yerine kendi domain yolun kullanıldığı için basit liste bazlı blocker’lar tanımayabilir. Daha kapsamlı listeler container ID ve istek parametrelerini de yakalayabildiği için tam bypass değil.

Kritik: CF default caching kapalı olmalı. sGTM Preview Mode cache’lenmiş response’larla çalışmaz, debug çalışmaz hale gelir.¹⁸

Açık kaynak örnek: simondahla/sgtm-same-origin-proxy-cloudflare-worker hazır Worker kodu sunar.¹⁹ owntag aynı pattern için detaylı yazı yayınladı.²⁰ Stape kendi yönetim panelinden Cloudflare Worker kurulum yönergesi sağlar.²¹

Öneri: Site Cloudflare arkasındaysa, hangi hosting’i seçersen seç production ortamında CF Worker proxy katmanı değerlendirmeye değer. Gerçek kazanım first-party cookie ve ITP dayanıklılığı.

Ajans Multi-Client Mimari

Birden fazla müşteri yöneten ajans için üç mimari yol:

Yol A: Tam izolasyon. Müşteri başına ayrı Cloud Run project veya ayrı Stape container’ı (Stape’te abonelik zaten site başına). En temiz, en yüksek ops yükü.

Yol B: Paylaşımlı altyapı, ayrı container. Tek ajans Cloud Run project altında müşteri başına ayrı service (sgtm-clienta, sgtm-clientb). Self-host senaryoda tek VPS üzerinde ayrı Docker Compose service’leri aynı pattern’ı verir. İzolasyon ile ortak altyapı arasındaki orta yol budur.

Ek müşterinin maliyetini üç kalem belirler: kurulum emeği, paylaşılan kaynaklar ve müşterinin kendi tüketimi. Şablon ve deployment kodu ikinci müşteride kurulum emeğini düşürür, ama bulut faturasını tek başına düşürmez. Fatura ancak çalışan bir kaynak paylaşıldığında bölünür ve bu paylaşım platforma göre koşullu: AWS’de load balancer paylaşılabilir ama her müşterinin compute’u ayrı ücretlenir;²² Azure App Service’te plan kapasitesi paylaşılır, ama plan büyüdükçe fatura da büyür ve Google’ın tek preview instance kuralı¹ ayrı bir plan ya da daha üst bir katman gerektirebilir. Trafik ve log tüketimi her platformda ayrıca faturaya yansır.

Teknik not: ECS Express Mode’da, subnet’leri load balancer’ın availability zone’larıyla uyumlu olan aynı VPC’deki en fazla 25 servis tek bir Application Load Balancer’ı paylaşabilir;²³ her müşterinin tagging ve preview servisi bu gruptaysa bir ALB’ye 12 tam müşteri kurulumu sığar. Azure App Service’te ücret plandaki VM başına alınır ve aynı plandaki app’ler varsayılan olarak birlikte ölçeklenir;²⁴ preview’u tek instance’a sınırlayan per-app scaling yalnızca Standard ve üstü katmanlarda var ve plan faturasını kendiliğinden düşürmüyor.²⁵

Yol C: Tek server container, birden fazla domain. Bir tagging server tek bir server container çalıştırır, ama tek server container birden fazla domain’den veri alabilir.²⁶ Müşteri siteleri aynı servise yönlenir, trafik ve konfigürasyon paylaşılır. Maliyet en düşük, izolasyon yok: bir sitedeki yük artışı ortak servisi etkiler, tek publish herkesi etkiler, GTM erişimi olan herkes tüm tag’leri görür. Aynı markanın birden fazla domain’i için mantıklı; ayrı ekip erişimi, bağımsız publish veya müşteri devri gerekiyorsa ayrı container ve servis modeli uygun.

Müşteri ayrılma senaryosu:

• Cloud Run, ayrı project (Yol A): Project müşterinin kendi organizasyonuna ve billing hesabına devredilebilir.
• Cloud Run, paylaşımlı project (Yol B): Project devredilemez; devretmek diğer müşterilerin kaynaklarına da yetki vermek olur. Müşterinin servisleri kendi project’ine yeniden kurulur, container config ve DNS taşınır. IAM yetkisi vermek kaynak taşımak değildir.
• Stape: Container sahipliği müşterinin Stape hesabına devredilebilir (ownership transfer).⁸
• Self-host: Docker compose ve .env müşteri sunucusuna taşınır.

Devir checklist’i ajans sözleşmesinin ekinde olmalı: DNS devri, ajansın IAM yetkilerinin kaldırılması, sGTM’deki üçüncü taraf entegrasyonların API (Application Programming Interface) anahtarlarının iptali veya devri, GA4 property ownership.

Karar Matrisi

Senaryo	Önerilen	Neden
Küçük-orta ajans, DevOps ekibi yok	Stape EU region	Sıfıra yakın ops, hızlı onboarding, tier sabit fiyat
Google ekosisteminde derin müşteri, BigQuery kullanıyor	Cloud Run	GCP servisleriyle native entegrasyon, esnek ölçekleme
Enterprise müşteri, veri egemenliği sözleşmede	Self-host, sözleşmedeki ülkede sunucu	Veri işleme yeri ve işleyici zinciri kontrol altında
Çok müşterili ajans, standardizasyon önceliği	Cloud Run paylaşımlı project	Ortak altyapı, ayrı service, template deploy
Çok müşterili ajans, AWS veya Azure zorunlu	ECS Express Mode veya App Service plan	Paylaşımlı load balancer veya plan, sabit maliyeti müşterilere böler
Ad blocker sorunu ön planda	Herhangi + CF Worker proxy	Liste bazlı blocker’lar kendi domain yolunu tanımayabilir (kısmi)

Site Cloudflare proxy arkasındaysa, her seçeneğin üstüne CF Worker same-origin proxy eklemek değerlendirilmeli; tek başına bir hosting değil, bir katman.

Ölçeğe Göre Maliyet

Ölçek	Makul olabilecek seçenek	Maliyeti belirleyen
Tek site, düşük trafik, teknik ekip yok	Stape	Sabit tier; Cloud Run’da önerilen 2 instance ve preview, düşük trafikte de sabit bir alt maliyet oluşturur
Tek site, değişken veya yüksek trafik	Cloud Run veya Stape üst tier	Instance saati ile tier sınırından hangisinin trafik profiline oturduğu
Birkaç müşteri, tek ajans	Cloud Run paylaşımlı project veya tek VPS	Şablon kurulum emeğini düşürür; VPS’de kapasite paylaşılır, bir müşterinin yükü diğerlerini etkiler
Çok müşteri, AWS veya Azure zorunlu	ECS Express Mode veya App Service plan	Load balancer veya plan müşterilere bölünür; Fargate’te compute müşteri başına, App Service’te plan kapasitesi ortak (preview ayrı tutulur)
Veri işleme ülkesi sözleşmede tanımlı	Ülke içi self-host	Maliyetten önce sözleşme koşulu; işletme emeği en yüksek

Son Not

sGTM hosting kararı “Cloud Run mu Stape mi” ikilemine sıkıştırılamaz. Karar üç eksende başlar (bakım kapasitesi, veri egemenliği, trafik öngörülebilirliği), ajans ve müşteri profiline göre dallanır. Tool isimleri değişir, eksenler kalır.

Kurulum detayları için sGTM Kurulum Rehberi. Ajans marketing stack’inin geri kalan katmanları (consent, analytics, attribution, governance) için: Ajanslar için Marketing Stack 2026.

Footnotes

1. Manual setup guide. Google Tag Manager ↩ ↩² ↩³ ↩⁴
2. Server-side tagging release notes. Google Tag Manager ↩ ↩²
3. Cloud Run Setup Guide. Google Tag Manager ↩ ↩² ↩³ ↩⁴
4. Lifecycle of a Container. Cloudflare Containers Docs ↩
5. Deploying Server-Side Google Tag Manager on Cloud Run. Square Developer Blog ↩
6. Google Tag Manager Server Side on Cloud Run - Pros and Cons. Mark Edmondson ↩
7. Google Tag Manager Server-Side Tagging with Stape. Analytics Mania ↩
8. Pricing and plans. Stape ↩ ↩² ↩³ ↩⁴ ↩⁵
9. Implementing Server-Side GTM with Docker: On-Premise Solution Guide. Paolo Bietolini ↩ ↩²
10. Run Server-side Google Tag Manager On Localhost. Simo Ahava ↩
11. Locations. Hetzner Docs ↩
12. Billing FAQ. Hetzner Docs ↩
13. Amazon ECS Express Mode. AWS Documentation ↩
14. sGTM Deployment on Azure Container Apps. Selnekovic ↩
15. Google Tag Gateway vs Server-Side GTM: Which One Do You Need? Paolo Bietolini ↩
16. Private Browsing 2.0. WebKit ↩
17. Tracking Prevention in WebKit. WebKit ↩
18. Same-origin Deployment With Server-side Google Tag Manager. Simmer ↩
19. sgtm-same-origin-proxy-cloudflare-worker. simondahla (GitHub) ↩
20. How to Make Your Server-Side GTM Accessible for Free via Cloudflare on Your Main Domain and Bypass ITP. owntag ↩
21. How to Use Same Origin Through Cloudflare. Stape ↩
22. AWS Fargate Pricing. Amazon Web Services ↩
23. Resources created by Amazon ECS Express Mode services. AWS Documentation ↩
24. Azure App Service plans. Microsoft Learn ↩
25. High-density hosting with per-app scaling. Microsoft Learn ↩
26. How Do I Organize My Multi-domain Setup For Server-side Tagging In Google Tag Manager? Simmer ↩

Önemli Noktalar

• 01 sGTM Docker + Node.js container olduğundan Cloudflare Workers gibi V8 isolate platformlarında koşmaz
• 02 Cloud Run en iyi dokümante edilen yol, Stape sıfıra yakın ops alternatifi, self-host sunucunun bulunduğu ülkeyi kontrol etmek için
• 03 CF Workers sGTM'nin önünde same-origin proxy olarak çalışır; site Cloudflare arkasındaysa first-party cookie ve ITP kazanımı sağlar
• 04 Ajans multi-client kurulumunda şablon kurulum emeğini, paylaşılan load balancer veya plan sabit maliyeti böler; müşteri başına tüketim platforma göre ayrı ücretlenir ya da ortak kapasiteden karşılanır
• 05 Hosting kararı liste fiyatından önce üç eksende verilir: bakım kapasitesi, veri egemenliği, trafik öngörülebilirliği

Sık Sorulan Sorular (FAQ)

+ sGTM'yi Cloudflare Workers'da koşturabilir miyim?

Hayır. sGTM bir Docker imajı (gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable) ve Node.js runtime ister. Cloudflare Workers V8 isolate platformudur, Docker ve Node.js server'ı çalıştıramaz. CF Workers yalnızca sGTM'nin önünde same-origin proxy olarak kullanılır.

+ Cloud Run mu Stape mi daha ucuz?

Ölçeğe göre değişir. Düşük trafikte Stape'in sabit tier'ı genelde daha öngörülebilir; Cloud Run'da Google'ın önerdiği 2 production instance ve preview sunucusu, trafik düşük olsa da sabit bir alt maliyet oluşturur. Trafik yükseldikçe karşılaştırma, instance saatleri ile tier sınırlarının trafik profiline nasıl oturduğuna döner. Ajans tarafında kurulum ve bakım emeği de bu hesaba girer.

+ Preview container ayrı mı host edilmeli?

Evet. Google'ın manual setup rehberi tam 1 preview sunucusu ister ve autoscaling'in 1 instance'ın üstüne çıkarılmamasını söyler. Tagging server'lar preview isteklerini PREVIEW_SERVER_URL üzerinden bu sunucuya yönlendirir. Rehber tek instance kuralının gerekçesini açıklamıyor.

+ Stape kullanırken veri Türkiye'den çıkıyor mu?

Stape EU region seçimi sunar, ama verinin Türkiye'de kalmasını garanti etmez. Self-host bu durumu ancak sunucu Türkiye'de barındırılırsa değiştirir; Hetzner gibi AB sağlayıcıları aynı yurt dışı aktarım sorusunu doğurur. Ayrıca sGTM'nin işi veriyi Google ve Meta gibi yurt dışındaki platformlara iletmek. Hosting yeri bu aktarımı ortadan kaldırmaz, yalnızca aradaki işleyiciyi değiştirir.

+ sGTM instance'ı kaç müşteriye hizmet verebilir?

Bir tagging server tek bir server container çalıştırır; CONTAINER_CONFIG tek container'ın yapılandırmasıdır. Tek server container birden fazla domain'den veri alabilir, bu yüzden birden fazla müşteri sitesi teknik olarak aynı container'a gönderebilir. Ajans pratiğinde izolasyon için müşteri başına ayrı server container ve ayrı tagging server tercih edilir; paylaşımlı bir Cloud Run project'i altında her müşteri ayrı service olarak deploy edilir.

+ CAPI ve Enhanced Conversions gibi özellikler hosting seçimine bağlı mı?

Temel işlevler hosting'e bağlı değil: CAPI ve Enhanced Conversions tag'leri sGTM container konfigürasyonunda kurulur ve her hosting'de aynı çalışır. Fark ek katmanlarda. Stape'in power-up'ları (Cookie Keeper, custom loader gibi) Stape'e özgüdür; Cloud Run veya self-host'ta aynı işlevin ayrıca kurulması gerekir.