GA4 ile mağazanın sipariş panelinin aynı sayıyı göstermemesi tek başına bir hata kanıtı değildir. İki sistem farklı kayıtları, zamanları ve ölçüm koşullarını kullanabilir. Ancak farkın nedenini anlamadan “normaldir” demek de gerçek bir kurulum sorununu gözden kaçırabilir. İlk adım, karşılaştırılan sayıların aynı şeyi temsil edip etmediğini kontrol etmektir.
Burada önerdiğim çalışma bir mutabakat tablosudur. Mağaza siparişleri ticari kayıt olarak, analitik olayları ise ziyaret ve davranış ölçümünün parçası olarak ayrı tutulur. Amaç birini diğerine zorla benzetmek değil, açıklanabilen ve araştırılması gereken farkları ayırmaktır.
Sayım birimini eşitlemek
Bir panel sipariş sayısını, başka bir rapor satın alma olaylarını veya satılan ürün adedini gösteriyor olabilir. Sipariş içindeki üç ürün üç ayrı sipariş değildir. İptal edilen siparişlerin, test işlemlerinin ve iadelerin karşılaştırmaya nasıl dahil edildiği de yazılmalıdır.
Google, e-ticaret ölçümlerinde olay kapsamı ile ürün kapsamını ayırır. Bu nedenle karşılaştırmadan önce rapordaki metriğin tanımını incelemek gerekir. GA4 e-ticaret metrikleri belgesi bu ayrımı açıklar.
Aynı zaman ve durum kapsamını kullanmak
Tarih aralığı kadar saat dilimi de önemlidir. Gece yarısına yakın bir sipariş iki raporda farklı güne düşebilir. Sipariş oluşturma zamanı, ödeme zamanı ve ölçüm olayının ulaşma zamanı da farklı olabilir. Son saatlerin verisini olgunlaşmış bir önceki dönemle aynı kesinlikte yorumlamam.
Vergi, kargo, indirim ve para birimi tanımları tutar karşılaştırmasında ayrıca kontrol edilir. Aynı sipariş adedi görünse bile iki gelir sayısı farklı hesaplanmış olabilir. Bu farkı dönüşüm kaybı gibi yorumlamadan önce değer alanlarının anlamını eşlerim.
Farkları işlem gruplarına ayırmak
| Grup | Araştırılacak olasılık | Sonraki kontrol |
|---|---|---|
| Panelde var, analitikte yok | Olay tetiklenmemiş veya ölçüm gerçekleşmemiş olabilir | İzin akışı ve teknik teslim kaydı |
| Analitikte tekrar var | Yinelenen tetikleyici veya kimlik sorunu olabilir | İşlem kimliği ve gönderim kaynakları |
| Sayı yakın, tutar farklı | Değer kapsamı değişebilir | Vergi, kargo, indirim ve para birimi |
| Günler farklı | Zaman tanımı uyuşmayabilir | Saat dilimi ve olay zamanları |
| Kampanya dağılımı farklı | Atıf kapsamı değişebilir | Rapor boyutu ve atıf tanımı |
Tablo olasılık listesi olarak kullanılır. Ölçüm izni vermeyen ziyaretçiler veya istemci tarafındaki engeller nedeniyle eksik gözlem bulunabilir; bu durum gizlilik tercihini aşarak veri toplama gerekçesi değildir. Eksikliği raporlama sınırı olarak göstermek gerekir.
Tekrarlanan satın alma olayını kontrol etmek
Web veri akışlarında GA4 aynı transaction_id ile gönderilen satın alma olaylarını tekilleştirebilir. Her siparişin kendine ait, boş olmayan ve kişisel bilgi içermeyen kimliği bulunmalıdır. Aynı değerin farklı işlemlerde kullanılması eksik sayım yaratabilir. Google’ın işlem kimliği belgesi bu gereklilikleri belirtir.
Bir test siparişiyle yetinmem. Sayfa yenileme, ödeme başarısızlığı ve yeniden deneme gibi akışlar da kontrol edilmelidir. Pixel ve sunucu olaylarında çift sayım benzer problemin farklı gönderim yollarında nasıl oluştuğunu anlatıyor; platformların tekilleştirme kuralları birbirinin yerine kullanılmamalıdır.
Mutabakatı düzenli bir kontrol haline getirmek
Seçilen aralık için toplam fark, açıklanan fark ve çözülmemiş fark ayrı kaydedilir. Bir tolerans kullanılacaksa mağazanın geçmiş gözlemleri ve karar ihtiyacına göre belirlenir; herkese geçerli bir yüzde varsayılmaz. Ani değişim, bilinen sınırdan daha güçlü bir araştırma işareti olabilir.
Son kayıtta veri zamanı, kapsam, bulgu ve sorumlu yer almalıdır. Düzeltme sonrası aynı karşılaştırma yeniden yapılır. Böylece ekip her rapor toplantısında aynı sayı tartışmasını baştan yaşamaz; hangi verinin hangi karar için güvenilir olduğunu bilir.