Consent Mode v2 sonrası kayıp dönüşümler: modellenmiş veriye ne kadar güvenebilirsiniz?

Modellenmiş veriye, kurulumunuz advanced modda doğru çalışıyorsa ve hesabınız eşik değerleri karşılıyorsa, trend ve toplam düzeyinde güvenebilirsiniz. Kampanya, kreatif ya da gün bazında tek tek karar vermek içinse güvenmemelisiniz. Modelleme kayıp dönüşümleri geri getirmez, kaybın büyüklüğünü istatistiksel olarak tahmin eder. Bu yazıda o tahminin ne zaman sağlam, ne zaman kum üstünde olduğunu nasıl ayırt edeceğinizi anlatıyorum.

Consent Mode v2 aslında neyi değiştirdi

Consent Mode ilk sürümünde iki sinyalle çalışıyordu: ad_storage ve analytics_storage. Bunlar yalnızca tarayıcıda çerez yazılıp yazılamayacağını belirliyordu. v2 ile iki yeni sinyal geldi: ad_user_data, kullanıcı verisinin reklam amacıyla Google’a gönderilip gönderilemeyeceğini; ad_personalization ise bu verinin kişiselleştirilmiş reklam ve remarketing için kullanılıp kullanılamayacağını söyler.

Pratikteki fark şu: v1’de izin sinyali depolamayla ilgiliydi, v2’de verinin kullanım amacıyla ilgili. Bir kullanıcı analitik çerezlere izin verip reklam amaçlı veri paylaşımını reddedebilir. Bu kombinasyonu doğru ileten bir CMP ve etiket yapısı yoksa, Google Ads tarafında remarketing listeleri küçülür, enhanced conversions sinyali kesilir ve raporlardaki dönüşüm sayısı sessizce düşer. Çoğu ekip bu düşüşü önce kampanya performansı sanıyor, oysa sorun ölçüm katmanında.

Sinyallerin tam listesi ve varsayılan davranışlar için Google’ın Consent Mode geliştirici dokümantasyonu başvurulacak ilk kaynak. Blog yazılarından değil, oradan başlamanızı öneririm, çünkü parametre davranışları zaman içinde güncelleniyor.

Basic ve advanced kurulum: fark sadece teknik değil

İki kurulum biçimi arasındaki seçim, modellemenin kalitesini doğrudan belirler.

Basic kurulum

Basic kurulumda Google etiketleri kullanıcı izin banner’ında bir seçim yapana kadar hiç yüklenmez. Kullanıcı reddederse Google’a hiçbir istek gitmez. Varsayılan izin durumu bile iletilmez. Google Ads bu durumda yalnızca genel bir modelle, yani benzer reklamverenlerden öğrenilmiş kalıplarla tahmin yapar. GA4 tarafında ise davranış modellemesi hiç çalışmaz, çünkü modelin öğrenebileceği bir sinyal yoktur.

Basic kurulumun avantajı sadeliği ve hukuk ekiplerinin genellikle daha rahat onaylamasıdır. Dezavantajı, reddedilen trafiğin tamamen karanlıkta kalmasıdır.

Advanced kurulum

Advanced kurulumda etiketler sayfa açılır açılmaz yüklenir, ancak varsayılan olarak reddedilmiş izin durumuyla başlar. Kullanıcı reddederse etiketler çerez okumaz ve yazmaz, bunun yerine cookieless ping gönderir. Bu pinglerde izin durumu, zaman damgası, sayfa bilgisi ve dönüşüm olup olmadığı gibi sınırlı bilgiler bulunur. Kalıcı bir istemci kimliği yoktur, oturumlar arasında kullanıcı bağlanamaz.

Google bu pingleri, izin veren kullanıcıların davranışıyla birlikte kullanarak reklamverene özgü bir model eğitir. Modelleme kalitesindeki asıl sıçrama buradan gelir.

Cookieless ping bir kullanıcı değildir, bir sayım sinyalidir. Onu kullanıcı gibi analiz etmeye çalıştığınız anda yanlış soruyu soruyorsunuz demektir.

Advanced kurulumun hukuki boyutu ayrıca değerlendirilmelidir. İzin vermeyen kullanıcının tarayıcısından yine de Google’a istek gitmesi, bazı hukuk ekiplerinin kabul etmediği bir durum. Bu teknik bir karar değil, şirketin risk iştahıyla ilgili bir karar ve ölçüm ekibinin tek başına vermemesi gerekir.

GA4 modellemesi neyi dolduruyor, neyi doldurmuyor

GA4’te iki ayrı modelleme mekanizması var ve sık sık birbirine karıştırılıyor.

Davranış modellemesi, analytics_storage reddedilmiş kullanıcıların kullanıcı ve oturum düzeyindeki metriklerini tahmin eder: aktif kullanıcılar, oturumlar, etkileşim oranı, bu kullanıcıların hangi kanaldan geldiği gibi. Bu model yalnızca raporlama kimliği Blended olarak ayarlandığında raporlara yansır. Observed ya da Device-based kimlikte modellenmiş veri görmezsiniz.

Dönüşüm modellemesi ise attribution tarafında çalışır. Bir key event gerçekleşti ama kullanıcının hangi kampanyadan geldiği bilinemiyorsa, GA4 bu dönüşümü olası kanallara dağıtır. Yani toplam dönüşüm sayısı zaten cookieless pinglerden sayılmış olabilir, modelleme onun hangi kaynağa yazılacağını tahmin eder.

Davranış modellemesinin devreye girmesi için Google’ın belirttiği uygunluk koşulları kabaca şöyle:

• Mülkte advanced Consent Mode aktif olmalı ve GA4 etiketleri izin verilmeden önce de yüklenmeli.
• analytics_storage reddedilmiş en az 1.000 günlük event, en az 7 gün boyunca gelmeli.
• İzin vermiş en az 1.000 günlük kullanıcı, son 28 günün en az 7’sinde veri göndermeli.
• Raporlama kimliği Blended olmalı.
• Modelin eğitilmesi için eşikler karşılandıktan sonra birkaç gün beklemek gerekir, geçmişe dönük doldurma sınırlıdır.
• Varsayılan izin durumu, sayfadaki ilk GA4 isteğinden önce ayarlanmış olmalı.

Güncel eşikleri her zaman GA4 davranış modellemesi yardım sayfasından kontrol edin. Küçük ve orta ölçekli Türk e-ticaret sitelerinin önemli bir kısmı günlük 1.000 izinli kullanıcı eşiğine özellikle hafta sonları takılıyor. Bu durumda model hiç açılmaz, ya da açılıp kapanır ve raporlarda anlamsız dalgalanmalar görürsünüz.

Modellemenin doldurmadığı şeyleri de net koymak gerekiyor. Modellenmiş veri BigQuery export’a girmez. Audience oluşturmada kullanılamaz. Kullanıcı yolculuğu, cohort ve funnel analizlerinde reddedilen kullanıcıların gerçek davranışını size göstermez. Arayüzde gördüğünüz 12.000 kullanıcının 3.000’i modellenmişse, BigQuery’de o 3.000’i hiçbir zaman bulamazsınız.

Kurulumu doğrulamak: gcs, gcd ve Tag Assistant

Modellenmiş veriye güvenmeden önce ilk soru, sinyallerin doğru gidip gitmediği. Denetlediğim kurulumların büyük kısmında sorun modelde değil, izin sırasında çıkıyor: varsayılan izin durumu GA4 config’ten sonra ayarlanıyor, CMP asenkron yüklendiği için güncelleme geç geliyor ya da GTM’de Consent Initialization tetikleyicisi hiç kullanılmamış oluyor.

Doğrulama için izlediğim sıra şu:

1. Tarayıcıyı gizli pencerede açın, çerezleri temizleyin ve geliştirici araçlarında Network sekmesini collect filtresiyle açın.
2. Banner’da hiçbir seçim yapmadan sayfanın ilk isteğine bakın. gcs parametresi G100 olmalı. Buradaki biçim G1 önekinden sonra sırasıyla ad_storage ve analytics_storage için 1 ya da 0 değeridir.
3. Aynı istekte gcd parametresini okuyun. Bu parametre dört sinyalin hem değerini hem de nasıl ayarlandığını harflerle kodlar. Sırası ad_storage, analytics_storage, ad_user_data, ad_personalization şeklindedir. l harfi sinyalin hiç ayarlanmadığını gösterir ve v2 açısından alarm işaretidir.
4. Banner’da tümünü kabul edin ve sonraki isteği kontrol edin. gcs değeri G111 olmalı, gcd içinde varsayılan reddin güncellemeyle izne döndüğünü gösteren r harfini görmelisiniz.
5. Tümünü reddedip yeni bir oturumda tekrarlayın. Advanced kurulumda istekler gitmeye devam etmeli ama gcs G100 kalmalı. Basic kurulumda hiç istek görmemelisiniz.
6. Tag Assistant ile aynı akışı açın ve her event için Consent sekmesinde varsayılan ve güncel durumu karşılaştırın. İlk event’te varsayılan değerin boş görünmesi, sıralama hatasının en net belirtisidir.
7. Son olarak Google Ads ve GA4 yönetici panelindeki Consent Mode durum ekranlarını kontrol edin, ancak bunları tek kaynak olarak kullanmayın. Panel birkaç gün gecikmeli ve sadece özet bilgi verir.

Tüm bu adımları hem masaüstünde hem mobilde, en az bir ürün sayfasında ve ödeme onay sayfasında tekrarlayın. Ödeme adımında farklı bir alt alan adı ya da ödeme sağlayıcısı varsa, izin durumu orada sıklıkla kayboluyor.

BigQuery ile izin dağılımını ölçmek

Arayüzdeki modellenmiş rakamı değerlendirmek için önce ne kadar trafiğin reddedildiğini bilmeniz gerekir. GA4 export’taki privacy_info.analytics_storage alanı bunu event düzeyinde verir. Aşağıdaki sorgu son 28 gün için günlük izin dağılımını ve reddedilen tarafta kalan satın alma event’lerini çıkarır:

WITH gunluk AS (
  SELECT
    PARSE_DATE('%Y%m%d', event_date) AS gun,
    COALESCE(privacy_info.analytics_storage, 'Ayarlanmamis') AS analytics_storage,
    COUNT(*) AS event_sayisi,
    COUNTIF(event_name = 'purchase') AS purchase_sayisi,
    COUNTIF(user_pseudo_id IS NULL) AS kimliksiz_event
  FROM `project.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN
      FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 28 DAY))
      AND FORMAT_DATE('%Y%m%d', DATE_SUB(CURRENT_DATE(), INTERVAL 1 DAY))
  GROUP BY gun, analytics_storage
)
SELECT
  gun,
  analytics_storage,
  event_sayisi,
  ROUND(100 * event_sayisi / SUM(event_sayisi) OVER (PARTITION BY gun), 2) AS event_payi_yuzde,
  purchase_sayisi,
  kimliksiz_event
FROM gunluk
ORDER BY gun, analytics_storage;

Bu sorgunun çıktısında üç şeye bakıyorum. Birincisi, Ayarlanmamis satırının payı. Bu oran yüzde birkaçı geçiyorsa bazı sayfalarda ya da event’lerde izin sinyali hiç gitmiyor demektir. İkincisi, reddedilen payın günler arasında tutarlı olup olmadığı. Bir gün yüzde 25, ertesi gün yüzde 60 görüyorsanız banner’da ya da CMP tetiklemesinde bir değişiklik olmuştur. Üçüncüsü, reddedilen tarafta kalan purchase event’lerinin oranı. Bu oran, arayüzdeki modellenmiş dönüşümlerin makul bir üst sınırını hesaplamanıza yardım eder.

KVKK bağlamında Türkiye’deki durum

Bu bölüm hukuki görüş değildir, ölçüm ekiplerinin karşılaştığı pratik tabloyu özetler.

Google’ın AB kullanıcı izin politikası kapsamında v2 sinyallerini zorunlu tuttuğu bölge AEA, Birleşik Krallık ve İsviçre. Türkiye bu kapsamda değil, dolayısıyla yalnızca Türkiye trafiği olan bir sitede Google Ads, v2 sinyalleri eksik diye remarketing listelerini otomatik olarak kapatmıyor. Ancak bu, Türkiye’de izin yönetiminin gereksiz olduğu anlamına gelmiyor. 6698 sayılı Kişisel Verilerin Korunması Kanunu ve Kişisel Verileri Koruma Kurumu’nun çerez uygulamalarına ilişkin rehberi, zorunlu olmayan çerezler için açık rıza yaklaşımını öne çıkarıyor. 2024’te yürürlüğe giren değişiklikler de yurt dışına veri aktarımı konusunu yeniden gündeme getirdi.

Ölçüm ekibi açısından pratik sonuç şu: Türkiye’de banner kullanan ve reddetme seçeneğini gerçekten sunan sitelerde izin reddi oranları, Avrupa’daki sitelere yaklaşmaya başladı. AEA’ya da hizmet veren Türk markaları için ise bölgesel varsayılan izin ayarı kurmak gerekiyor: AEA kullanıcıları için varsayılan ret, diğer bölgeler için hukuk ekibinizin onayladığı yapı. Hangi yapının uygun olduğuna ölçüm ekibi değil, KVKK konusunda yetkin bir hukuk danışmanı karar vermeli.

Modellenmiş rakama ne kadar güvenmeli

Varsayımsal bir örnekle düşünelim. Bir e-ticaret sitesinde BigQuery’deki izinli trafikten 800 satın alma sayılıyor, GA4 arayüzü ise 1.050 gösteriyor. Reddedilen event payı yüzde 30 civarında. Bu durumda 250’lik fark mantıklı bir aralıkta, çünkü reddeden kullanıcıların izin verenlerle benzer oranda satın aldığı varsayımı altında beklenen rakama yakın. Aynı sitede arayüz 1.600 gösterseydi, modelin agresif tahmin yaptığından ya da izin sinyallerinde bir sızıntı olduğundan şüphelenirdim.

Benim kullandığım pratik yaklaşım, modellenmiş veriyi üç katmanda farklı ağırlıkla kullanmak. Toplam gelir ve dönüşüm trendi gibi üst düzey metriklerde modellenmiş rakamı kabul ediyorum, çünkü büyük sayılarda model hatası ortalamaya gidiyor. Kanal karşılaştırmasında modellenmiş attribution’ı dikkatli kullanıyorum ve her zaman izinli trafikteki gözlenen dağılımla yan yana koyuyorum. Kampanya, reklam grubu ve günlük ROAS kararlarında ise modellenmiş rakama tek başına dayanmıyorum, küçük hacimlerde güven aralığı gerçek farkı yutacak kadar geniş.

Bir de şunu kabul etmek gerekiyor: modelin doğruluğunu dışarıdan tam olarak test etmenin yolu yok. Google model performansını geriye dönük olarak kendi verisinde doğruladığını belirtiyor, ancak sizin sitenizde reddeden kullanıcıların davranışı izin verenlerden sistematik olarak farklıysa, örneğin reddedenler daha çok fiyat karşılaştırması yapan ve daha az satın alan bir kitleyse, model bu farkı tam yakalayamayabilir. Bu yüzden CRM ya da backend sipariş verisiyle aylık mutabakat yapmak, modellenmiş rakamı doğrulamanın en güvenilir yolu olmaya devam ediyor. Arayüz, BigQuery ve backend arasındaki farkı her ay aynı tabloda izleyin. Fark sabit kaldığı sürece modele güvenebilirsiniz, fark açılmaya başladığında önce kurulumu, sonra modeli sorgulayın.