Duplicate purchase event’leri nasıl tespit edilir?

Ölçüm sorunlarının çoğu kendini belli eder. Rakam düşer, rapor boşalır, biri fark eder. Duplicate purchase event’leri öyle değil. Her şey çalışıyor görünür, raporlar açılır, rakamlar makul durur. Sadece ciro olduğundan yüksektir.

Genelde finans tarafında bir mutabakat tutmadığında ortaya çıkar. O da ayın sonunda olur.

Tespit

BigQuery’deki GA4 export’unda purchase event’lerini transaction_id’ye göre gruplayın, birden fazla kez görünenleri listeleyin. Aynı işlem numarasının ikinci kez ateşlenmesi duplicate’tir, aradaki ciro farkı da şişme miktarınız.

Sorguyu en az 30 günlük pencerede çalıştırın. Bazı desenler günde bir iki kez gerçekleşir, aylık toplamda ciddi tutar. Tarayıcı oturumu geri yükleme, e-postadan teşekkür sayfasına dönme gibi senaryolar tam olarak böyle davranır.

Nereden çıkar

Teşekkür sayfası. En yaygın kaynak. Event sayfa yüklendiğinde ateşleniyorsa, müşterinin sayfayı yenilemesi, geri tuşuyla dönmesi ya da siparişi e-postadan tekrar açması her seferinde yeni bir satış yaratır.

Tek sayfa uygulamaları. SPA mimarilerde route değişimlerinde veya bileşen yeniden render olduğunda event tekrar tetiklenebilir. Bu davranış her tarayıcıda aynı sıklıkta görülmez, o yüzden testte fark edilmeyip canlıda ortaya çıkar.

Tag kurulumu. Bir migrasyondan sonra iki ayrı tetikleyicinin aynı tag’e ulaşması. Ya da hem dataLayer push’unun hem doğrudan gtag çağrısının aynı anda çalışması. İkisi de kurulum tarihinden aylar sonra keşfedilir.

Duplicate olmadan şişme: item_revenue

Bir de event tekrarı olmadan gerçekleşen bir şişme var, ve bu daha az biliniyor.

items dizisindeki item_revenue alanı ürün başına ciroyu taşımalıdır. Pek çok kurulumda ise sepetin tamamı her satıra yazılır. Bu alanı UNNEST ile açıp toplarsanız, üç ürünlük bir sipariş cironun üç katını gösterir. Hiçbir duplicate event yoktur, ciro yine de şişmiştir.

Kuralımız şu: ciro event seviyesindeki purchase_revenue alanından okunur. Ürün kırılımlı analizler yayına girmeden önce bu toplamla doğrulanır. Kategori bazlı ciro raporu hazırlayan herkesin bu kontrolü yapması gerekiyor.

Önleme

Tetikleyici tarafında: purchase event’ini sayfa yüklenmesine değil, sunucudan gelen sipariş onayına bağlayın. Mümkünse tarayıcı tarafında bir kilit kurun ki aynı transaction_id ikinci kez gönderilmesin.

Raporlama tarafında: warehouse sorgularınızda tekilleştirme kuralı bulunsun. Tetikleyiciyi bugün düzeltseniz bile geçmiş veri olduğu gibi kalacak, ve raporlarınız o geçmişi de okuyacak.

Neden bekletilmez

Şişmiş ciro doğrudan ROAS’a yansır, üstelik tam da dönüşüm getiren oturumlarda yansır. En çok yatırım yaptığınız kanallar olduğundan iyi görünür, bütçe oraya kayar, ve gerçekte ne kazandırdığınızı bilmeden büyüdüğünüzü sanırsınız.

Aynı event’ler LTV modellerinin de girdisi. Yani hata bugünün raporunda kalmaz, geleceğe dair tahminlere de taşınır.

Günlük çalışan otomatik bir kontrol, bu sorunu haftalar sonra patlayan bir mutabakat krizinden aynı gün kapatılan küçük bir işe çevirir. Sorgu zaten yazılmış durumda; kalan tek iş onu her sabah çalıştırmak.