Google Analytics 4 e-ticaret kurulumu: hangi olay, hangi parametre, nasıl doğrulanır?

01Kuruluma sipariş kaydından başlıyoruz

Kuruluma olay listesini kopyalayarak değil, sipariş kaydının nasıl oluştuğunu çözerek başlıyoruz. İlk sorularımız GA4’le ilgili bile değil: raf fiyatı KDV dahil mi? Kargo ayrı mı tahsil ediliyor? İndirim ürün satırına mı uygulanıyor, sepetin tamamına mı? Sipariş numarası sistemin hangi alanında duruyor?

Bu soruların sebebi sahada en sık karşılaştığımız hatalar. Bir hesabı incelediğimizde sorun çoğunlukla üç yerde çıkıyor: dönüşüm değeri, dönüşüm sayısı ve huninin önceki adımlarındaki tutarsız veri. Üçü de olay adı kusursuz yazılmışken oluşabiliyor; hata olayın taşıdığı bilgide.

Etiketlerin Google Ads, Tag Manager ve GA4 arasında nasıl bağlandığı ayrı bir mimari konu; onu gokhangumus.com'daki GTM ve GA4 yazısında anlattım. Burada olayların içine ne yazıldığına bakıyoruz.

02E-ticaret hunisi: hangi olay ne taşır?

Google'ın önerdiği e-ticaret olayları bir alışveriş yolculuğunu adım adım izler¹. Çoğu mağaza için çekirdek altı olay yeterli. Tabloda iki sütun var: Google'ın zorunlu saydığı çekirdek ve anlamlı raporlama için gönderilmesi gerekenler².

Tablonun her satırında geçerli bir kural: value gönderiyorsanız currency artık seçimlik değildir². Liste uzatılabilir (view_item_list, select_item, remove_from_cart, refund)¹; ama çekirdek altı olay tutarlı değilse eklenen her olay tabloyu biraz daha bulanıklaştırır.

03purchase olayının anatomisi

Google'ın sözleşmesindeki zorunluluk düzeyleri farklı; bizim sahadaki standardımız ise dört alanın dördünü de her siparişte göndermek.

transaction_id (zorunlu). Her siparişe özgü, dinamik bir değer olmalı². GA4 aynı kimlikle gelen satın almaları tekilleştirir; bu yalnız web akışlarında çalışır⁷. Boş değer daha da kötüdür: transaction_id'si boş gelen bütün satın almalar birbirinin kopyası sayılıp tekilleştirilir⁷. Teşekkür sayfası yenilendiğinde olayın ikinci kez gitmesi sık görülür; kimlik doğruysa GA4 kopyayı ayıklar.

items (zorunlu). Her ürün için item_id ya da item_name bulunmalı; Google ikisini birlikte öneriyor¹. quantity yoksa 1 kabul edilir¹. Sepette üç adet olan bir ürün quantity olmadan gelirse ürün raporları sessizce eksik sayar.

value (gelir raporları için gerekli). Google'ın tanımı tercihe bırakılmamış: value, ürünlerin fiyat × adet toplamıdır; kargo ve vergi dahil edilmez, bunlar purchase olayında ayrı shipping ve tax parametreleriyle gider². Türkiye'de raf fiyatı KDV dahil olduğu için bu, value'ya KDV hariç ürün tutarını, tax'a KDV'yi, shipping'e kargo ücretini yazmak demek. Kurulumun çoğu zaman en çok tartışılan kısmı bu eşleme; ama bir kez sipariş kaydının alanlarıyla eşlendiğinde değişmez. Aynı value tanımını reklam platformlarında da kullanmak, paneller arasındaki tutar farkının en azından değer tanımından kaynaklanan bölümünü ortadan kaldırır. Atıf, tarih aralığı, iade ve modelleme kaynaklı farklar yine de sürer.

currency (value varsa zorunlu). Üç harfli ISO 4217 koduyla gider; Türkiye'deki bir mağaza için TRY².

04Ara adımları satın alma kadar ciddiye alın

Yalnız purchase doğru kurulduğunda gelir raporu doğru görünür ama huni yalan söyler. En tanıdık belirti: satın alma sayısının begin_checkout sayısından fazla görünmesi. Standart checkout akışında böyle bir tablo beklenmez; alternatif ödeme yolları, seçilen tarih aralığı ve ölçüm sırası ayrı ayrı kontrol edilmelidir. Olası sebepler arasında ara adımın bazı ödeme yollarında hiç tetiklenmemesi, tema ile uygulamanın aynı olayı iki kez göndermesi ve adımların farklı parametrelerle kurulması var.

Bu yüzden ara adımları purchase ile aynı disiplinle kuruyoruz: aynı items yapısı, aynı value tanımı, aynı para birimi. Kaybın hangi adımda yaşandığı sorusu bu adımlar olmadan cevaplanamaz; landing page teşhis sırasının altıncı kapısı da bu veriyle açılır.

05Consent Mode v2: onay vermeyen ziyaretçi ne olur?

Consent Mode, Google etiketlerinin ziyaretçinin çerez tercihine göre nasıl davranacağını belirler. Dört onay türü var³:

• analytics_storage: analiz çerezleri. Reddedilirse etiketler birinci taraf analiz çerezlerini okumaz, yazmaz.
• ad_storage: reklam çerezleri. Reddedilirse yeni reklam çerezi yazılmaz, var olanlar okunmaz.
• ad_user_data: çevrim içi reklamcılık amacıyla kullanıcı verisinin Google'a gönderilmesine onay. Reddedilirse user_id ve gelişmiş dönüşümlerdeki birinci taraf veriler gibi reklam amaçlı kişisel veri kullanımı kapanır.
• ad_personalization: kişiselleştirilmiş reklam. Reddedilirse yeniden pazarlama gibi özellikler veri almaz.

"v2" ile eklenen son ikisi. Google, Avrupa Ekonomik Alanı’ndaki (AEA) kullanıcılar için bu iki sinyali bekliyor; Mart 2024’ten bu yana sinyal gelmezse bağlı reklam ürünlerindeki kitlelere yalnız AEA dışındaki kullanıcılar giriyor⁴. Siteniz AEA'dan ziyaretçi alıyorsa GA4'te Yönetici > Veri toplama ve düzenleme > Onay ayarları ekranı bu sinyallerin gelip gelmediğini gösterir⁴. Hangi tercihin hangi ziyaretçiden nasıl alınacağı hukuki bir karar; burada yalnız teknik davranışı anlatıyoruz.

Uygulamanın iki yolu var ve farkı büyük³. Temel uygulamada etiketler, ziyaretçi onay bandıyla etkileşime geçene kadar yüklenmez; onay gelmezse hiçbir şey gitmez. Gelişmiş uygulamada etiketler sayfa açılınca yüklenir; onay yokken çerezsiz ölçüm gönderir, onay gelince tam veriye geçer. Google'a göre gelişmiş uygulama reklamverene özgü daha ayrıntılı bir modelleme sağlar; temel uygulamada modelleme genel bir modele dayanır³.

Kurulumu Tag Assistant'ta üç şeye bakarak doğruluyoruz: sayfa açılırken varsayılan onay durumu, bant etkileşiminden sonra güncellenen durum ve hangi etiketin çalışıp hangisinin onay yüzünden engellendiği⁸.

06Doğrulama: dört katman, dört farklı zaman

Kurulumu tek bir ekrana bakıp onaylamıyoruz. Her katman başka bir şeyi kanıtlıyor ve başka bir zamanda okunuyor:

1. DebugView (anında). Tag Assistant ya da debug_mode parametresiyle kendi cihazınızdan bir test siparişi verin; olayları ve parametrelerini saniyeler içinde görürsünüz⁵. Bakılacak şey olayın gitmesi değil, parametrelerin dolu ve doğru gitmesi: transaction_id sipariş numarasıyla, value KDV ve kargo hariç ürün tutarıyla aynı mı? Debug modunu kapatmak için parametreyi false yapmak yetmez, tamamen kaldırmak gerekir⁵.
2. Gerçek zamanlı rapor (dakikalar). Olayın sıradan bir oturumda da geldiğini gösterir⁶.
3. Standart raporlar (24–48 saat). GA4'te veri işleme 24–48 saat sürebilir ve bu sürede rakamlar değişebilir⁶. Kurulumun ertesi sabahı bakılan gelir raporu henüz son hali değil.
4. Sipariş kayıtlarıyla karşılaştırma (bir hafta). Asıl sınav bu. Bir haftalık satın alma adedini ve tutarını yönetim panelindeki siparişlerle yan yana koyuyoruz. Birebir tutmasını beklemiyoruz; rakamın hangi yönde ve ne kadar saptığına, bunun açıklanabilir olup olmadığına bakıyoruz. Panellerin neden hiçbir zaman birebir tutmadığı ayrı bir konu.

Onay vermeyen bir kullanıcının olayları DebugView'da görünmez⁵. Kendi testinizde çerez bandını reddettiyseniz boş ekran kurulumun bozuk olduğu anlamına gelmez.

07Kurulum günü bakılacak iki ayar

Veri saklama süresi. Standart mülklerde kullanıcı düzeyindeki ve olay düzeyindeki veriler için 2 ya da 14 ay seçilebilir⁹. Ayar standart raporları etkilemez; keşifleri ve huni raporlarını etkiler⁹. Geçen yılın aynı dönemiyle huni karşılaştırması yapmak istiyorsanız 14 ayı kurulum günü seçin.

Geliştirici trafiği ve test siparişleri. Google, debug modundaki trafiğin raporları bozmaması için geliştirici trafiğinin filtrelenmesini öneriyor⁵. Test siparişlerini sipariş sisteminde de işaretleyin; haftalık karşılaştırmada iki taraftan da düşebilin.

GA4, Tag Manager ve reklam platformlarını tek bir olay mimarisinde kurup sipariş kayıtlarıyla doğruluyoruz; ölçüm altyapısı hizmetimiz bu işin kapsamını anlatıyor. Meta tarafında aynı tekilleştirme mantığı Pixel ve Conversions API eşleşmesiyle kurulur.