Üyelere Özel
Bu yazının tamamı ücretsiz üyelikle okunur. Kredi kartı gerekmez.
- 01 Karşılaştırma birimi kampanya adı değil, iki tarafta da bulunan ortak bir kimlik olmalıdır. Satın alma dönüşümlerinde bu transaction_id, ödemeye başlama veya sepete ekleme gibi eylemlerde ödeme oturumu ya da sepet kimliği. Anahtarın satır başına benzersiz olmadığı yerde yöntem çalışmaz.
- 02 Karşılaştırmaya başlamadan önce GA4 tarafının kendi sayımını doğrula. Bir mağazada platformun hazır GA4 entegrasyonu, haricen kurulan GTM yapısına göre ortalama yüzde on beş ile yirmi arasında daha az işlem saydı. Genellenebilir olan kısmı şu: hazır entegrasyon bir referans noktası değil, doğrulanması gereken bir kaynaktır.
- 03 Sonuç iki katmanlı okunur. Satır seviyesinde birbirini dışlayan üç kova (eşleşen, yalnızca Ads, yalnızca GA4), bunun yanında satır seviyesine hiç bağlanamayan Ads hacmi için ayrı bayraklar: sayfa adresi yok, modellenen dönüşüm, view-through dönüşüm, cross-device. Bu hacim paydadan düşülmezse eşleşme oranı olduğundan kötü çıkar.
- 04 İşlem kimlikleri Google Ads raporlamasının hiçbir yerinde boyut, kolon veya segment olarak bulunmaz. Panel tarafında bir sipariş kimliğinin görünebileceği tek yer sayfa yolunun kendisi, o da yalnızca kimlik query parametresinde değil yolun parçasıysa.
- 05 First-party cookie ile click ID yakalama pratikte yüzde doksan civarında bir tavana oturur ve pencere genişledikçe birkaç puan düşer. Kalan boşluğun büyük kısmı cross-device ve consent reddi. GA4 etiketi click ID'yi Ads dönüşüm etiketi için saklamadığından bu değeri kendi tarafında tutmak gerekir.
+ Ads ile GA4 karşılaştırmasında hangi alan üzerinden eşleştirme yapılmalı?
İki tarafta da bulunan ortak bir kimlik üzerinden. Satın alma dönüşümlerinde bu transaction id olur; Ads tarafında ölçülen eylem ödemeye başlama veya sepete ekleme ise ödeme oturumu kimliği ya da sepet kimliği devreye girer. Belirleyici olan anahtarın adı değil satır başına benzersiz olması, çünkü benzersiz olmayan bir anahtarla birleştirme birden çoğa dönüşür ve eşleşme oranı anlamını yitirir. Satın alma senaryosunda bir ön koşul daha var: Ads Webpages raporu adresin yalnızca yol kısmını raporlar, query parametrelerini raporlamaz. Sipariş kimliği /tesekkurler?siparis=12345 biçimindeyse rapora hiç girmez, yöntem ancak numara /siparis/12345 gibi yolun parçasıysa çalışır. Kampanya adı üzerinden eşleştirme güvenilir değildir, çünkü otomatik etiketlemede kampanya bilgisi GA4'e Ads bağlantısı üzerinden ulaşır ve cookie'ye yazılan utm_campaign değeri genellikle boştur.
+ Ads Report Editor ile bu karşılaştırma yapılabilir mi?
Kısmen. Report Editor'de web sayfası boyutu bulunmaz, dolayısıyla sipariş seviyesinde birleştirme oradan çıkarılamaz. Panel dışına çıkılırsa Ads API üzerinden dönüşüm yükleme kayıtları ve mağazanın kendi sipariş kayıtları da köprü olabilir. Report Editor kampanya seviyesindeki normalizasyon için gereklidir: (by conv. time) kolonları, All conv. farkı, cross-device dönüşümler ve conversion action envanteri buradan alınır. Panel içinde kalındığında satır seviyesindeki tek köprü Conversions bölümündeki Webpages raporudur.
+ GA4'te click ID boyutu var mı, Explore raporunda ona filtre uygulanır mı?
GA4 hazır bir click ID boyutu sunmaz. Rapordaki boyut, click ID'yi açılış sayfasında yakalayıp olayla birlikte gönderdikten sonra kendi kaydettiğin bir özel boyuttur; kurulmadıysa Explore raporunda seçebileceğin böyle bir alan yoktur. Kurulduğunda da dolu satırlara filtre uygulanmaz. Filtre, iOS tarafında gclid yerine gbraid veya wbraid ile gelen siparişleri ve consent reddi nedeniyle cookie yazılamayan siparişleri dışarıda bırakır. Bu satırlar rapordan çıkınca gerçekte var olan bir boşluk cross-device kaybı gibi görünür. Filtre uygulanmadan çekilip sınıflandırma sonradan yapılmalıdır.
+ First-party cookie ile click ID saklamanın ölçülebilir bir tavanı var mı?
Var. Pratikte yüzde doksan civarında bir yakalama oranına oturuyor ve karşılaştırma penceresi genişledikçe birkaç puan düşüyor. Düşüşün nedeni cookie ömrü ile reklam conversion window'u arasındaki asimetridir, ancak bu asimetri her hesapta yoktur: Ads tarafındaki tıklama conversion window'u her conversion action için ayrı ayrı belirlenir, varsayılanı otuz gündür ve doksan güne kadar çıkarılabilir. Ayar yükseltilmişse cookie daha erken, Safari tarafında ITP nedeniyle çok daha erken sona erer. Kalan boşluğun büyük kısmı cihaz değiştiren kullanıcılar ve consent reddidir.
+ Eşleşme oranı düşük çıkıyorsa ilk nereye bakmalı?
Paydaya. Satır seviyesine hiç bağlanamayacak Ads hacmi (sayfa adresi kaydedilememiş dönüşümler, modellenen dönüşümler, view-through dönüşümler ve cross-device) paydadan düşülmeden hesaplanan oran her zaman olduğundan kötü çıkar, çünkü yöntem kendi ölçemediği şeyi kayıp gibi raporlar. İkinci bakılacak yer GA4 kovası: rapora organik ve başka platform siparişleri sızmışsa artık iki panel değil iki farklı evren karşılaştırılıyor demektir. Üçüncüsü ise ön koşul, GA4'ün kendi sayımının mağazanın sipariş kaydıyla tutup tutmadığı.
+ sGTM ile cookie süresi uzatılarak yakalama tavanı yükseltilebilir mi?
Kısmen, ama koşulsuz değil. Sunucu tarafında Set-Cookie başlığıyla yazılan cookie, ITP'nin JavaScript cookie'lerine uyguladığı yedi günlük kısıtın kapsamında değildir. Muafiyet ise alt alan adının nereye çözümlendiğine bağlı: WebKit, üçüncü taraf CNAME gizlemesi ve üçüncü taraf IP adresi gizlemesi tespit ettiğinde sunucu tarafında yazılan cookie'nin ömrünü de yedi günle sınırlıyor. Ayrıntısını consent sınırları içinde reklam ölçümü yazısında ele aldım. Bu yöntem yalnızca cookie ömründen kaynaklanan kaybı kapatır; consent reddi, cross-device ve iOS'ta gclid yerine gelen gbraid veya wbraid bundan etkilenmez.