Consent Bir Tasarım Parametresi
Kullanıcı izin vermediğinde tag davranışı değişir. Bu bir hata durumu değil, sistemin amaçlandığı gibi çalışması. Sorun izinsiz ölçüm yapamamak değil, bu kısıtla birlikte çalışan doğru sinyal mimarisini kurmamış olmak.
Google, Consent Mode’u tam bu senaryo için tasarladı. Çerçeve şu soruya yanıt veriyor: cookie yazamadığında hangi sinyaller toplanabilir, bu sinyallerden ne öğrenilebilir?
Sırasıyla: Consent Mode’un sinyal mimarisi, cookieless takip parametreleri, Conversion Linker’ın localStorage geçişi, modeled conversions mekanizması, Enhanced Conversions ve son olarak sGTM, tag gateway ve CNAME gibi harici yaklaşımlar.
Consent Mode V2: Tasarlanmış Sinyal Mimarisi
Consent Mode’un iki modunu teknik davranış farkıyla anlamak gerekiyor.
Basic mode: Banner onaylanana kadar hiçbir Google tag’i tetiklenmez. Kullanıcı reddederse o oturum için hiçbir sinyal toplanmaz.
Advanced mode: Tag her koşulda tetiklenir. Ancak consent yokken tag şunları yapmaz:
- Cookie yazmaz (
_ga,_gcl_awdahil hiçbiri) - Fingerprinting yapmaz
- Cross-site takip almaz
Bunun yerine şunları yapar:
- URL’ye ping gönderir (hangi sayfa ziyaret edildi, tarayıcı tipi, sayfa kategorisi)
gcsparametresiyle consent durumunu iletirgcdparametresiyle consent öncesi default state’i iletir
gcs ve gcd Parametreleri
gcs (Google Consent State), consent durumunu iki karakterli bir kodla kodlar:
| gcs Değeri | Anlam |
|---|---|
| G100 | ad_storage ve analytics_storage reddedildi |
| G110 | analytics_storage verildi, ad_storage reddedildi |
| G111 | Her ikisi de verildi |
| G000 | Consent henüz alınmadı (pending) |
| G1— | Site o consent türü için onay gerektirmiyor |
Bu parametre Google’ın sunucusuna giden her request’e eklenir. Cookie yokken bile hangi bağlamda ölçüm yapıldığı kaydedilir. Modeled conversions bu sinyaller üzerine inşa edilir.
gcd (Google Consent Default) ise page load anındaki default consent state’ini kodlar. Advanced mode’da default’u denied olarak ayarlamak ve kullanıcı seçimine göre update etmek doğru yapıdır:
// Sayfa başında, herhangi bir tag çalışmadan önce
gtag("consent", "default", {
ad_storage: "denied",
analytics_storage: "denied",
ad_user_data: "denied",
ad_personalization: "denied",
wait_for_update: 500,
});
// CMP consent verdiğinde
gtag("consent", "update", {
ad_storage: "granted",
analytics_storage: "granted",
ad_user_data: "granted",
ad_personalization: "granted",
});wait_for_update: 500 değeri banner yüklenme gecikmesini karşılar. CMP performansına göre 300-1000 ms arasında ayarlanabilir.
Cookieless Dönüşüm Takibi: wbraid ve gbraid
gclid, URL’ye eklenen reklam tıklaması parametresi. Ancak gclid cookie tabanlı çalışır: siteye girişte _gcl_aw cookie’sine kaydedilir, dönüşümde bu cookie okunur. Safari ITP bu cookie’yi 24 saate kısıtlayabilir, consent yoksa hiç yazılamaz.
Safari tarafında bunun yanında ikinci bir mekanizma daha var ve o cookie ömrünü kısaltmıyor, parametreyi tamamen siliyor. Apple’ın Link Tracking Protection’ı bilinen tıklama parametrelerini gezinme gerçekleşmeden önce adresten çıkarıyor. Parametre siteye hiç ulaşmadığı için sunucu tarafında yakalamak da mümkün olmuyor; sunucu tarafına geçmek bu kaybı kapatmıyor. Kapsamı dar: Özel Dolaşma ile Mail ve Mesajlar uygulamalarından açılan bağlantılar. Normal Safari oturumlarında varsayılan olarak çalışmıyor, kullanıcı gelişmiş korumayı tüm dolaşma için açtığında çalışıyor. Apple hangi parametrelerin silindiğini yayımlamıyor; gclid’in silindiği bilgisi uygulayıcı testlerine dayanıyor ve birbirinden bağımsız birkaç kaynak aynı sonucu bildiriyor.1 UTM parametrelerinin dokunulmadan geçtiği ise WebKit’in kendi örneğiyle uyumlu. Hangi tarayıcının hangi parametreyi kırptığını ve bunun gateway tasarımına etkisini tracking için URL anatomisi yazısında topladım.
Google bu soruna iki parametre ile yanıt verdi: wbraid ve gbraid2.
| Parametre | Senaryo | Mekanizma |
|---|---|---|
| gclid | Standart web dönüşüm | Cookie (_gcl_aw) |
| gbraid | iOS web-to-app dönüşüm | URL parametresi, sunucu tarafında işlenir |
| wbraid | App-to-web dönüşüm | URL parametresi, sunucu tarafında işlenir |
Mekanizma sütununda “cookie bağımsız” dememek gerekiyor, çünkü doğru değil: Google’ın kendi sayfası wbraid geldiğinde Google tag’in alan adınızda yine birinci taraf cookie yazdığını söylüyor.2 Bağlantının kendisi URL parametresi üzerinden kuruluyor, ama cookie tamamen devreden çıkmıyor.
wbraid ve gbraid değerleri URL parametresinde kalır, tıklama bağlantısı için cookie’ye yazılmaya ihtiyaç duymaz. Google Ads bu parametreleri sunucu tarafında işler. Consent reddedildiğinde cookie yazılamaz ama URL parametresi hâlâ mevcut; Google sunucusu bu parametreden dönüşümü bağlayabilir.
Reklam tıklaması URL’sine bakmak bu parametreleri görmeyi sağlar. Conversion Linker tag’inin aktif olması, bu parametrelerin doğru korunmasını sağlar.
Conversion Linker ve localStorage
Conversion Linker, Google tag ekosisteminin reklam tıklaması parametrelerini korumakla görevli bileşeni. gclid, wbraid, gbraid gibi parametreleri yakalayıp depolamak, cross-page ve cross-domain senaryolarında korumak temel işlevi.
Kasım 2024’te Conversion Linker davranışı değişti: reklam tıklaması bilgisi artık cookie’ye ek olarak localStorage’a da yazılıyor3.
localStorage sunucuya gitmiyor ve ITP’nin cookie’ye uyguladığı 24 saat kısıtlamasına tabi değil. Tıklama attribution penceresi bu şekilde genişliyor.
Bu localStorage yazımı consent ile nasıl etkileşiyor? ad_storage=denied olduğunda Conversion Linker cookie yazmaz; localStorage yazımının consent modundan nasıl etkilendiği Google dokümantasyonunda net değil. Teknik olarak localStorage bir cookie değil, ama “ad depolama” kapsamında değerlendirilmesi beklenir. Kesin davranışı doğrulamak için Tag Assistant Network sekmesinden localStorage yazımını izlemek gerekir.
Modeled Conversions: Sınırları Açık İstatistiksel Yaklaşım
Advanced mode sinyalleri ve wbraid/gbraid verileri Google’ın modeled conversions motorunu besler. Mekanizma şu:
- Consent veren kullanıcıların davranış örüntüsü gözlemlenir (observed conversions)
- Benzer bağlamda (sayfa tipi, cihaz, campaign) consent vermeyen kullanıcılar tespit edilir
- İstatistiksel model, consent vermeyen segment için olası dönüşüm sayısını tahmin eder
- Bu tahmin Google Ads raporlarına “modeled conversion” olarak eklenir
Önemli sınırlar:
- Modeled ve observed conversions Google Ads raporlarında ayrı gösterilmiyor
- Google modelin nasıl çalıştığını açıklamıyor; segment büyüklüğüne ve veri zenginliğine göre kalitesi değişiyor
- Küçük consent oranında veya düşük trafik hacminde model güvenilirliği düşer
- Bu model bireysel kullanıcı takibi değil, istatistiksel tahmin
Bu sınırların ikisi Google’ın kendi dokümanında sayı ve yön olarak veriliyor, o yüzden ayrı durmayı hak ediyorlar.
Modelleme bir uygunluk eşiğine bağlı. Reddedilen her ziyaret için bir modellenen dönüşüm oluşmaz. Eşiğin kendisi Google’ın dokümanında tutarlı değil. Consent mode modelleme sayfası, ülke ve alan adı grubu başına yedi günlük bir dönemde yedi yüz reklam tıklaması arıyor ve temel ile gelişmiş uygulama ayrımı yapmıyor.4 Daha güncel modelleme rehberi ise günde yüz tıklamadan söz ediyor ve bu koşulun yalnızca temel uygulama için gerekli olduğunu, gelişmiş uygulama için aranmadığını yazıyor.5 İki sayfa da yayında duruyor, dolayısıyla tek bir rakamı kural diye aktarmak yanıltır. Pratikte kalan şu: modelleme her hesapta devreye girmiyor ve girmediğinde reddedilen hacim raporda hiç görünmüyor. Düşük hacimli bir hesapta “advanced mode’a geçtik, kayıp kapanır” beklentisi bu yüzden karşılanmayabilir. Eşiği kendi hesabına uygulamadan önce belgenin tarihine ve hangi uygulama tipinden söz ettiğine bakmak gerekiyor.
Model eksik saymak üzere kurulu. Fazla tahmini önlemek hedeflendiği için gerçekte gerçekleşmiş bazı dönüşümler hiç sayılmıyor, Google bunu açıkça yazıyor.4 Yani modellenen sayı fazla tahmin yönünde bir risk taşımıyor. Bunun matematiksel bir alt sınır olduğu ise garanti edilmiyor; belgede yalnızca modelin yönü belirtiliyor.
Raporlama tarafında bir ayrıntı daha var. Modellenen dönüşümler Conversions kolonunun içinde duruyor ve bu kolonu kullanan tüm alt raporlara yansıyor.4 Ayrı bir kolonu ya da segmenti yok, dolayısıyla belirli bir siparişe de bağlanamıyor. Bir dönüşüm raporunu mağazanın kendi sipariş kayıtlarıyla karşılaştıran biri için bu hacim, en baştan paydadan düşülmesi gereken bir kalem.
Enhanced Conversions: Kullanıcının Gönüllü Verisi
Enhanced Conversions, kullanıcının dönüşüm anında bıraktığı birinci taraf veriyi (e-posta, telefon) hashleyerek Google’a gönderir. Cookie bağımlılığı yok, GCLID cookie’si süresi dolmuş veya hiç yazılmamış olsa bile e-posta eşleşmesiyle attribution kurulabiliyor6.
Yasal çerçeve: Bu veri kullanıcının gönüllü olarak verdiği veri (checkout’ta girilen e-posta). Ancak bu verinin reklam amacıyla Google’a iletileceğinin kullanıcıya bildirilmesi, yani ad_user_data consent’inin alınmış olması bekleniyor. Teknik olarak cookie gerektirmiyor, yasal olarak veri işleme izni gerektiriyor.
Nasıl Çalışıyor
Dönüşüm anında dataLayer’a kullanıcı verisi eklenir:
dataLayer.push({
event: "purchase",
user_data: {
email_address: "kullanici@domain.com", // SHA-256 Google tarafından yapılır
phone_number: "+905xxxxxxxxx", // E.164 format
},
ecommerce: {
transaction_id: "ORDER-123",
value: 299.99,
currency: "TRY",
},
});Ham e-posta Google’a gitmiyor; SHA-256 hashing Google tag tarafından tarayıcıda yapılıyor. Google bu hash’i kendi sistemindeki kullanıcı kayıtlarıyla eşleştiriyor.
Ön koşul: Dönüşüm noktasında kullanıcı verisi mevcut olmalı. Misafir checkout, e-posta girmeden satın alma veya telefon zorunlu olmayan formlar bu senaryoda veri sağlamıyor.
İki sınırı daha var ve ikisi de kurulum kararını değiştiriyor.
gbraid ya da wbraid taşıyan tıklamalarda çalışmıyor. Google Ads API dokümanı bunu açıkça yazıyor: web için enhanced conversions bu tıklamaları desteklemiyor.7 Yani iOS tarafında ATT izni verilmediği için click ID yerine bu parametreleri alan siparişler enhanced conversions ile de kurtarılamıyor. Bu grup yalnızca Google’ın kendi raporlamasında toparlanıyor, sizin ölçüm katmanınızda değil. Yukarıdaki tabloda wbraid ve gbraid satırlarının neden ayrı durduğunu da bu açıklıyor: cookieless takibin karşılığı, o siparişlerin sizin tarafınızda satır seviyesinde görünmemesi.
Kurulum yöntemi artık bir tercih değil. 2026 boyunca iki değişiklik oldu: Nisan’dan itibaren kullanıcı tarafından sağlanan veri site etiketinden, Veri Yöneticisi’nden ve API bağlantısından eşzamanlı kabul ediliyor; Haziran’dan itibaren de web ve potansiyel müşteri tarafındaki iki ayrı özellik tek bir açma kapama ayarında birleşti.8 Etiket ile API arasında seçim yapmayı öneren eski kurulum notları güncellenmeli.
sGTM, Tag Gateway, BigQuery ve CNAME
Bazı teknik yaklaşımlar consent sınırının dışında ama tarayıcı gizlilik önlemlerini etkileyen bir alanda.
sGTM ve First-Party Cookie Yazımı
sGTM, kendi subdomain’inizde (gtm.siteadi.com) çalışan bir sunucu container’ı. Set-Cookie header’ı ile yazdığı cookie’ler JavaScript cookie’si değil, HTTP cookie olarak işleniyor, dolayısıyla ITP’nin JavaScript ile yazılan cookie’lere uyguladığı yedi günlük kısıt bunlara doğrudan uygulanmıyor.
Buraya kadarı doğru, ama tek başına bırakılırsa yanıltıyor. WebKit’in kendi belgesi şunu yazıyor: ITP üçüncü taraf CNAME gizlemesini ve üçüncü taraf IP adresi gizlemesini tespit ediyor ve bu isteklerin HTTP yanıtında yazılan cookie’lerin ömrünü yine yedi günle sınırlıyor.9 Yani sunucu tarafında yazmak, alt alan adının nereye çözümlendiğinden bağımsız bir muafiyet vermiyor.
Pratikte iki şart çıkıyor. Alt alan adı bir sağlayıcının alan adına CNAME ile bağlıysa yedi gün kısıtı geri geliyor; bu zaten aşağıdaki CNAME cloaking başlığının konusu. Alt alan adı doğrudan bir IP’ye çözümleniyorsa da, o IP’nin ana alan adının IP’siyle aynı taraf sayılıp sayılmadığı belirleyici oluyor. WebKit bu karşılaştırmanın ölçütünü yayımlıyor: adreslerden biri IPv4 diğeri IPv6 ise, ikisi de IPv4 olup ortak alt ağ maskesi on altı bitten kısaysa ya da ikisi de IPv6 olup ortak maske altmış dört bitten kısaysa iki adres farklı taraf sayılıyor.9 Aynı paragrafta tespitin sezgisel olduğu ve ileride değişebileceği de yazılı, dolayısıyla eşiğin tam sınırına oturtulmuş bir kurulum sabit olmayan bir sayıya yaslanmış oluyor.
Burada sık karışan bir ayrım var: karşılaştırma, ana alan adının ve etiketi sunan alt alan adının çözümlendiği sunucu IP’leri arasında yapılıyor. Ziyaretçinin IP’siyle ilgisi yok, dolayısıyla iCloud Özel Geçişi gibi ziyaretçinin adresini değiştiren özellikler bu hesaba girmiyor. Onların etkisi cookie ömründe değil, IP’ye dayanan coğrafi zenginleştirme, tekilleştirme ve bot filtresi gibi yerlerde.
Sonuç olarak “sGTM kurduk, cookie ömrü sorunu çözüldü” cümlesi tek başına doğrulanabilir değil. Varsayılan bir Cloud Run kurulumu kendi IP aralığıyla geldiği için bu hizalamayı büyük olasılıkla sağlamıyor. Doğrulaması ise ölçümle yapılıyor: kurulumdan sonra Safari’de cookie’nin gerçekte kaç gün yaşadığına bakmak. Chrome tarafında ayrıca, açık son kullanma tarihi taşıyan tüm cookie’ler için dört yüz günlük bir üst sınır var, M104’ten beri geçerli.10
ITP bir tarayıcı gizlilik önlemi. sGTM bunu teknik olarak devre dışı bırakıyor. Consent alanının dışında (ITP’nin amacı consent değil, cross-site tracking önlemek), ancak tarayıcının kullanıcı adına aldığı bir gizlilik kararını etkiliyor.
Consent açısından net: sGTM, ad_storage=denied olduğunda cookie yazmaz. Consent kurallarını ihlal etmiyor. ITP’nin hedeflediği gizlilik önlemini teknik olarak aşıyor, bu tartışmalı.
sGTM’nin tartışmasız değeri: Consent Mode sinyallerini, Enhanced Conversions’ı ve Meta CAPI gibi üçüncü taraf platform entegrasyonlarını tek sunucu katmanında merkezi olarak yönetmek. Çok platformlu kurulumlar için operasyonel avantaj büyük.
Google Tag Gateway
Aynı eksende ikinci bir seçenek. Google tag kendi alan adınızdan yükleniyor, ölçüm istekleri de önce kendi alan adınıza gidiyor, oradan Google’a iletiliyor.11 Kurulum için istekleri iletebilen bir CDN ya da yük dengeleyici gerekiyor; Google, Cloudflare, Akamai, Fastly ve Google Cloud’u sayıyor ve en dayanıklı kurulum için bunu sGTM ile birlikte öneriyor.
Buradaki kazanç sGTM ile aynı yerden geliyor: istek kendi alan adınızdan yanıtlandığı için cookie sunucu tarafında yazılabiliyor. Dolayısıyla yukarıdaki şart burada da geçerli, hatta atlanması daha kolay. Google’ın dokümanında cookie ömrüne dair açık bir taahhüt yok; vaat edilen şey sinyal kurtarma, cookie ömrü değil. İkisini aynı şey saymamak gerekiyor.
BigQuery Ham Veri İhracı
GA4’ün BigQuery ihracı, UI’da aggregated olarak sunulan veriyi event bazında sağlar. Consent açısından değişen bir şey yok: Consent verilmemiş kullanıcıların modeled event’leri BigQuery’de de modeled olarak işaretlenir.
BigQuery export, ölçüm kalitesini değiştirmiyor, analiz esnekliğini artırıyor. Yanlış beklentiyle kurulursa (consent olmadan veri kurtarmak için) hayal kırıklığı yaratır.
CNAME Cloaking
CNAME cloaking, birinci taraf domain altında DNS CNAME kaydıyla üçüncü taraf bir tracker’ı çalıştırmak. Tarayıcının tracker engelleme listesi domain’i tanıyamıyor çünkü alan adı sizin alan adınız gibi görünüyor.
Bu yaklaşım IAB Europe ve browser üreticileri tarafından etik dışı olarak değerlendiriliyor. Consent Mode ile çalıştırılabilir ama bir consent problemi çözmüyor; tracker’ı gizlemek için DNS manipülasyonu yapıyor. Production ortamında önerilmiyor.
Uygulama Öncelik Sırası
Üç katman aynı anda uygulanmak zorunda değil. Hangisinden başlanacağı bütçe dağılımına ve mevcut altyapıya göre değişiyor.
1. Consent Mode V2 Advanced (zorunlu başlangıç noktası)
AB trafiği olan Google Ads hesapları için politika zorunluluğu. Entegrasyon olmadığında remarketing ve audience targeting AB trafiği için devre dışı kalıyor. CMP zaten aktifse teknik maliyet düşük: GTM’de consent default ayarı ve CMP’nin update çağrısı.
Doğrulama: Google Tag Assistant Network sekmesinde gcs parametresi ve consent komutu görünüyor mu?
Uygulama notu: Consent update’i her zaman sayfa geçişinden önce, kullanıcının onay verdiği sayfada çağır. Geç update GA4’te session_start kaybına yol açar. Sayfa unload’dan hemen önce çağrı yapıldığında browser network isteğini iptal edebilir.
2. Enhanced Conversions (Google Ads bütçesi varsa)
Dönüşüm noktasında kullanıcı verisi toplanıyorsa (checkout, kayıt formu, demo talebi) öncelikli. ad_user_data consent’i alınmış olmalı. Google Ads dönüşüm takibi kurulumu tamamlanmış olması ön koşul.
3. sGTM (çok platform veya ölçek)
Google + Meta veya başka bir platform kombinasyonu varsa, yüksek trafik hacminde consent sinyallerini merkezi yönetmek için sGTM altyapısı kullanılabilir. Başlangıç maliyeti yüksek ama tüm katmanlar tek noktadan yönetilmiş olur.
Hangi Yapı Ne Zaman
| Katman | Consent Uyumu | Gri Alan | Ön Koşul |
|---|---|---|---|
| Consent Mode V2 Advanced | Tam uyumlu | Hayır | CMP aktif, GTM kurulu |
| wbraid / gbraid | Tam uyumlu | Hayır | Google Ads + Conversion Linker |
| Modeled conversions | Tam uyumlu | Hayır | Advanced mode aktif |
| Enhanced Conversions | Uyumlu (ad_user_data gerekli) | Hayır | Dönüşüm noktasında kullanıcı verisi |
| sGTM first-party cookie | Consent uyumlu, ITP tartışmalı | Kısmen | Sunucu altyapısı, subdomain, alt alan adının CNAME ile gizlenmemesi |
| Google tag gateway | Tam uyumlu | Hayır | İstek iletebilen CDN ya da yük dengeleyici |
| BigQuery ihracat | Tam uyumlu | Hayır | GA4 BigQuery bağlantısı |
| CNAME cloaking | Tartışmalı | Evet | Önerilmiyor |
Consent ve GDPR’ın ölçüm üzerindeki yapısal etkisini ele aldığım yazı bu tablonun yasal arka planını detaylı açıklıyor. Analitik platformları arasındaki veri farklılıklarını anlatan yazı ise modeled data’nın GA4, Google Ads ve gerçek dönüşüm rakamları arasında nasıl tutarsızlık yarattığını gösteriyor.
Haziran 2026: Kontrol Noktası Değişikliği
Google, 15 Haziran 2026’dan itibaren GA4 ve Google Ads arasındaki veri kontrollerini konsolide ediyor. Bu değişiklik, yukarıdaki sinyal mimarisinin önemini doğrudan artırıyor.12
Google Signals’in rolü daralıyor. Bugüne kadar Google Signals hem behavioral reporting’deki signed-in kullanıcı verisini hem de Google Ads cookie/ID toplamayı kontrol ediyordu. 15 Haziran’dan itibaren Signals yalnızca behavioral reporting’i kontrol edecek. Ads veri toplama kontrolü tamamen Consent Mode’a geçiyor.
Bu yazıdaki gcs/gcd parametreleri ve consent default yapısı daha kritik hâle geliyor. Yukarıdaki tablodaki “CMP aktif, GTM kurulu” ön koşulu artık yetmez. CMP’nin dört consent parametresini (ad_storage, ad_user_data, ad_personalization, analytics_storage) doğru iletmesi zorunlu. Signals artık fallback görevi görmeyecek.
Ads personalization da taşınıyor. 2026 sonlarında GA4’teki katmanlı ads personalization ayarları (account, property, Ads link, event) kalkacak. ad_personalization consent parametresi tek kontrol noktası olacak. Bu, remarketing audience’ları ve DV360/SA360 entegrasyonlarını doğrudan etkiliyor.12
Detaylı hazırlık rehberi ve checklist bu geçiş için referans niteliğinde.
Footnotes
-
Apple silinen parametrelerin listesini yayımlamıyor. Private Browsing 2.0 yalnızca sınıfı tarif ediyor: “query parameters that have been identified as being used for pervasive cross-site tracking granular to users or clicks”.
gclid’in bu sınıfta olduğu uygulayıcı testlerine dayanıyor; AppsFlyer’ın iOS 17 bülteni kendi testlerindegclidilefbclid’in silindiğini, UTM parametrelerinin korunduğunu bildiriyor. ↩ - iOS 14 ve sonraki sürümlerde kampanya ölçümüyle ilgili güncellemeler. Yön birebir: “For web to app measurement, the parameter is known as GBRAID, and for app to web measurement, it’s known as WBRAID.” Birinci taraf cookie cümlesi ise Google Ads tarafındaki sayfada: Updates to iOS 14 campaign measurement, “To support this new parameter, the Google tag (gtag.js), Google Tag Manager (gtm.js), and Google Analytics (analytics.js) with a linked Google Ads account will set a new first-party cookie on your domains by default.” ↩ ↩2
- Conversion Linker storage update, Google Tag Manager Help ↩
- About consent mode modeling, Google Ads Help. Uygunluk eşiği birebir: “a daily ad click threshold of 700 ad clicks over a 7 day period, per country and domain grouping”. Aynı sayfa modelin fazla tahmini önlemeyi hedeflediğini ve bu nedenle gerçekte gerçekleşmiş bazı dönüşümlerin sayılmayabileceğini de belirtiyor: “some conversions that in reality occurred may not be accounted for.” Modellenen dönüşümler Conversions kolonunda görünür ve bu kolonu kullanan alt raporlara yansır. ↩ ↩2 ↩3
- Conversion modeling for consent mode (Google Ads Help). Eşik birebir: “Have an ad click threshold of 100 clicks per day, per country and domain grouping. This eligibility condition is required for basic consent mode implementation but not for advanced implementation.” ↩
- About enhanced conversions for web, Google Ads Help ↩
- Manage online click conversions, Google Ads API. Hata tablosu, gbraid veya wbraid taşıyan tıklamalar için web tarafında enhanced conversions desteklenmediğini belirtiyor: “Google Ads does not support enhanced conversions for web for these conversions.” ↩
- Gelişmiş dönüşümler ayarlarınızla ilgili güncellemeler, Google Ads Yardım. Nisan 2026’dan itibaren kullanıcı tarafından sağlanan veri site etiketlerinden, Veri Yöneticisi’nden ve API bağlantılarından eşzamanlı kabul ediliyor; Haziran 2026’dan itibaren web ve potansiyel müşteri gelişmiş dönüşümleri tek ayar altında birleşti. ↩
- Tracking Prevention in WebKit, “CNAME and Third-Party IP Address Cloaking Defense” başlığı. Birebir: “ITP detects third-party CNAME cloaking and third-party IP address cloaking requests and caps the expiry of any cookies set in the HTTP response to 7 days.” Karşılaştırmanın ölçütü bu sayfada değil, Private Browsing 2.0 yazısının “Defending Against Cloaked First Party IP Addresses” bölümünde: “two IP addresses are considered different parties if any of the following criteria are met: 1. One IP address is IPv4, while the other is IPv6. 2. If both addresses are IPv4, the length of the common subnet mask is less than 16 bits. 3. If both addresses are IPv6, the length of the common subnet mask is less than 64 bits.” Aynı yerde tespitin sezgisel olduğu ve değişebileceği belirtiliyor: “Detection of third-party IP addresses is heuristic, and may change in the future.” ↩ ↩2
- Cookie expiration limited to 400 days, Chrome for Developers. M104’ten (Ağustos 2022) itibaren cookie’ler dört yüz günden uzak bir son kullanma tarihi taşıyamıyor. Açık son kullanma taşımayan oturum cookie’leri kapsam dışında. ↩
- Set up Google tag gateway for advertisers with your content delivery network, Google Ads Yardım. Tag kendi alan adınızdan yükleniyor ve ölçüm olayları kendi alan adınıza gönderilip oradan Google’a iletiliyor. ↩
- Google Analytics Help: Updates to Google Analytics Data Controls (Google Signals rolü değişikliği, Consent Mode konsolidasyonu, ads personalization ve IP adresi akışı güncellemeleri) ↩ ↩2
- 01 Consent Mode V2 Advanced mode, consent reddedildiğinde cookie yazmak yerine URL ping ve gcs parametresiyle sinyal toplar; bu Google'ın bu senaryo için tasarladığı mekanizma
- 02 wbraid ve gbraid parametreleri, cookie olmadan iOS ve Safari kullanıcıları için dönüşüm bağlantısı kuran cookieless alternatifler
- 03 Conversion Linker, Kasım 2024'ten itibaren reklam tıklaması bilgisini localStorage'a da yazıyor; cookie süresi dolduğunda bile tıklama attribution'ı korunuyor
- 04 Enhanced Conversions, dönüşüm anında kullanıcının bıraktığı veriyi (e-posta, telefon) SHA-256 ile hashleyerek cookie bağımsız attribution kurar; birinci taraf veri yasal çerçevede kalır
- 05 sGTM first-party cookie yazımı ITP'nin JavaScript cookie kısıtını aşar ama koşulsuz değil: WebKit üçüncü taraf CNAME ve IP gizlemesini tespit ettiğinde sunucu tarafında yazılan cookie'yi de yedi günle sınırlıyor. Etik ve yasal değerlendirmesi ayrıca açık tartışma konusu
+ Consent Mode V2 basic ve advanced modları arasındaki ölçüm farkı nedir?
Basic mode'da consent verilene kadar hiçbir tag tetiklenmez; consent reddedilirse o oturum tamamen görünmez. Advanced mode'da tag her koşulda tetiklenir, ancak consent yoksa cookie yazmadan yalnızca URL ping ve gcs parametresiyle sinyal gönderir. Advanced mode Google'ın modeled conversions motorunu besleyen sinyali toplar, basic mode toplamaz.
+ wbraid ve gbraid parametreleri ne işe yarar?
Google'ın iOS ve Safari için geliştirdiği cookieless dönüşüm takip parametreleri. gclid cookie tabanlı çalışır ve ITP kısıtlamasına tabidir. gbraid (web-to-app dönüşümler) ve wbraid (app-to-web dönüşümler) ise URL parametresi olarak geliyor ve sunucu tarafında işleniyor. Bunlara cookie bağımsız demek yine de doğru değil: Google'ın kendi sayfası wbraid geldiğinde Google tag'in alan adınızda birinci taraf cookie yazmayı sürdürdüğünü söylüyor. Özellikle iOS trafiği yoğun e-ticaret sitelerinde gclid'in yanında çalışması önemli.
+ Modeled conversions ne kadar güvenilir?
Modeled conversions bireysel kullanıcı verisi değil, konsente eden kullanıcıların örüntüsünden istatistiksel tahmin. Google bu modeli açıklamıyor, segment büyüklüğüne ve sektör verilerine göre kalitesi değişiyor. Google Ads raporlarında modeled ve observed (doğrudan ölçülen) conversions ayrımı yapılmıyor; bu şeffaflık eksikliği bilinen bir eleştiri.
+ Enhanced Conversions consent gerektirmez mi?
Enhanced Conversions'ın gönderdiği veri (e-posta, telefon hash'i) kullanıcının dönüşüm anında bıraktığı veri. Ancak bu verinin Google'la paylaşılması için kullanıcının 'reklam amacıyla veriniz işlenecek' bilgisine sahip olması, yani ad_user_data consent'inin verilmiş olması beklenir. Teknik olarak cookie gerektirmiyor, yasal olarak veri işleme izni gerektiriyor.
+ sGTM first-party cookie yazımı etik mi?
sGTM kendi subdomain'inizden Set-Cookie header'ı yazar ve ITP'nin JavaScript cookie'lerine uyguladığı 7 gün kısıtı bu cookie'lere doğrudan uygulanmaz. Ama muafiyet koşulsuz değil: WebKit'in kendi belgesi, üçüncü taraf CNAME gizlemesi ve üçüncü taraf IP adresi gizlemesi tespit edildiğinde HTTP yanıtında yazılan cookie'lerin ömrünün de 7 günle sınırlandığını söylüyor. Yani alt alan adının nereye çözümlendiği belirleyici. ITP bir gizlilik önlemi, sGTM bunu teknik olarak devre dışı bırakıyor. Consent alanının dışında ama gizlilik tartışmasının içinde bir alan. CNAME cloaking daha belirgin gri alan: tarayıcının tracker'ı tanımasını engellemek için DNS manipülasyonu yapılıyor ve IAB tarafından etik dışı olarak değerlendiriliyor.
+ BigQuery ham veri ihracı ne sağlar?
GA4'ün BigQuery ihracı, UI'da agregatlanmış olarak görünen veriyi olay bazında sunar. Consent Mode aktifse, consent verilmemiş kullanıcıların modeled event'leri BigQuery'de de modeled olarak işaretlenir. Ham veri ihracı ölçüm kalitesini artırmaz; analiz ve segment esnekliği sağlar. Consent sınırını değiştirmez, consent çerçevesinde daha derin analiz imkanı verir.