Kısa cevap: Bu anonim GA4 case study'de sorun dashboard tasarımında değil, kaynak event kalitesindeydi. Purchase sayımı, data layer sırası, item parametreleri ve kanal naming'i temizlenince ekip aynı rapora bakarak bütçe kararı verebilir hale geldi.
Marka adı, kategori ve ticari hacim gizlilik nedeniyle anonimleştirildi. Problem tanıdıktı: Shopify paneli, GA4, Meta ve Google Ads aynı satış hacmi için farklı rakamlar gösteriyordu. Yönetim "hangi kanal gerçekten satıyor?" sorusuna cevap alamıyor, medya ekibi de bütçeyi panel ROAS'ına göre oynatıyordu.
Başlangıç problemi
GA4 purchase event'i çalışıyordu ama güvenilir değildi. Thank-you sayfası yenilendiğinde bazı siparişler ikinci kez sayılıyor, ödeme sağlayıcısından dönüşte bazı transaction_id'ler boş geliyordu. Ürün bazlı raporda item_category ve item_id eksikti. Looker Studio raporu güzel görünüyordu ama kaynak veri kirliydi.
| Katman | Bulgu | Karar riski |
|---|---|---|
| Purchase | Duplicate ve boş transaction_id | ROAS olduğundan iyi görünür |
| Items array | item_id ve kategori eksik | Ürün/kategori bütçe kararı alınamaz |
| Consent | Granted/denied senaryosu ayrı test edilmemiş | Veri düşüşü yanlış yorumlanır |
| Dashboard | GA4 ve backend farkı görünmüyor | Yönetim yanlış tek sayıya güvenir |
1. hafta: event doğrulama
İlk hafta rapor tasarımına dokunulmadı. Canlı sitede view_item, add_to_cart, begin_checkout ve purchase event'leri GTM Preview, GA4 DebugView ve backend sipariş tablosuyla karşılaştırıldı. Purchase event'ine transaction_id zorunlu kontrolü eklendi; thank-you sayfası refresh olduğunda ikinci push engellendi.
2. hafta: data layer ve item parametreleri
Ürün parametreleri standartlaştırıldı: item_id, item_name, item_category, price, quantity ve currency. Kategori kırılımı reklam kararında kullanılacağı için sadece GA4 raporunu doldurmak değil, ürün ailesi bazlı CAC okumasını mümkün kılmak hedeflendi. Eksik item parametresi oranı %42'den %3'e indi.
3. hafta: dashboard ve kanal uzlaştırma
Looker Studio raporu yeniden tasarlandı ama en sonda. Yönetim özeti, kanal kırılımı, funnel sağlığı ve ölçüm güveni ayrı bloklara ayrıldı. Raporun üstüne backend sipariş sayısı ile GA4 purchase farkı eklendi; böylece rapora bakan herkes önce verinin güven aralığını görmeye başladı.
Ne değişti?
En önemli değişim, "GA4 doğru mu?" sorusunun yerine "Bu veriyle medya bütçesi artırılır mı?" sorusunun gelmesiydi. GA4 ile backend farkı %6 seviyesine inince kanal karşılaştırması daha anlamlı hale geldi. Meta ve Google panel verileri hâlâ birebir aynı değildi; ama bu fark artık atribüsyon penceresi ve platform modellemesiyle açıklanabiliyordu.
| Önce | Sonra | Pratik etki |
|---|---|---|
| Panel ROAS tartışması | Backend + GA4 farkı görünür | Bütçe kararı daha sakinleşti |
| Ürün performansı belirsiz | Kategori ve item kırılımı var | Kârlı ürün ailesi ayrıştı |
| Dashboard güven vermiyor | Ölçüm güven bloğu eklendi | QBR toplantısı hızlandı |
Çıkarılacak ders
GA4 ölçümleme problemi çoğu zaman "dashboard kötü" diye görünür ama kök neden event kalitesidir. Önce purchase ve transaction_id, sonra item parametreleri, sonra consent senaryosu, en son dashboard. Sıra tersine çevrilirse, hatalı veriyi daha şık anlatmış olursun.
Bu vaka nasıl kullanılmalı?
Kendi kurulumunu kontrol edeceksen önce GA4 event checklist generator ile event setini çıkar. Teknik kurulum için GA4 e-ticaret kurulumu, karar mimarisi için e-ticaret ölçümleme rehberi iyi devamdır. Hizmet kapsamını görmek için GA4 e-ticaret kurulumu danışmanı sayfasına bakabilirsin.
Vaka hakkında sık sorulanlar
GA4 purchase farkı neden oluşur?
En sık nedenler duplicate purchase, eksik transaction_id, yanlış data layer sırası, consent tetikleme farkı, ödeme sayfası dönüşü ve reklam platformlarının farklı atribüsyon pencereleridir.
Bu çalışma reklam performansını artırır mı?
Doğrudan performans garantisi değildir. Ama yanlış ROAS ve CAC okumasını temizler. Bu da bütçe, kreatif ve kanal kararlarının daha güvenilir verilmesini sağlar.
Önce dashboard mu düzeltilmeli?
Hayır. Önce event ve sipariş eşleşmesi düzeltilmeli. Kaynak veri hatalıyken dashboard düzenlemek, hatayı daha okunabilir hale getirir ama karar kalitesini artırmaz.