Aynı satın alma işlemini hem tarayıcıdan hem sunucudan göndermek, iki farklı satış gerçekleştiği anlamına gelmez. Ölçüm düzeni bu iki bildirimin aynı iş olayını temsil ettiğini anlayabilmelidir. Aksi halde rapor, tek siparişi birden fazla dönüşüm gibi gösterebilir ve reklam kararları yanlış bir başlangıç noktasına dayanabilir.
Bu rehber, kurulumu değerlendirmek için bir kontrol sırası sunar. Belirli bir mağazada sorunun bulunduğu veya giderildiği iddiasını taşımaz. Kullanılan platform entegrasyonunun kendi davranışı ayrıca doğrulanmalıdır; hazır bir bağlantının yanına kontrolsüz ikinci bir ölçüm katmanı eklemek yeni tekrarlar yaratabilir.
Önce olayı, sonra gönderim yolunu tanımlamak
Satın alma olayı hangi iş anında oluşuyor? Ödeme başarıyla tamamlandığında mı, sipariş kaydı açıldığında mı, yoksa teşekkür sayfası görüntülendiğinde mi? Bu tanım net değilse doğru kimliklendirme bile farklı anlamdaki olayları birbirine karıştırabilir.
Bir siparişin yeniden görüntülenmesi yeni bir satın alma değildir. Başarısız ödemenin ardından yapılan yeni deneme de iş kuralına göre ele alınmalıdır. Olayın gerçek kaynağı, kimliği ve durum geçişi tek bir kayıt üzerinde tanımlanmalıdır. Kişiyi tanıyan bir kimlik ile işlemi tanıyan olay kimliği aynı amaçla kullanılmaz.
Meta eşleştirmesinin temelini doğrulamak
Meta’nın önerdiği yöntemde aynı olayın tarayıcıdaki eventID değeri sunucudaki event_id ile, olay adı da event_name ile eşleşir. İlgili bildirimlerin aynı Pixel’e gitmesi gerekir. Güncel belge, eşleşen tarayıcı ve sunucu olayları için 48 saatlik alım penceresini açıklar. Meta’nın çift olay yönetimi belgesi bu ayrıntıların resmi kaynağıdır.
Uygulamada olay kimliğinin her gönderim denemesinde yeniden üretilmemesine dikkat ederim. Aynı iş olayının tekrar gönderimi aynı kimliği korumalı; farklı siparişler ise aynı sabit değeri paylaşmamalıdır. Bütün işlemlere tek kimlik vermek, fazla sayım sorununu eksik sayım sorununa dönüştürebilir.
Test tablosunu yalnız mutlu akışla sınırlamamak
| Senaryo | Beklenen iş sonucu | İncelenecek davranış |
|---|---|---|
| Normal başarılı sipariş | Bir satın alma | İki yolun aynı olaya bağlanması |
| Teşekkür sayfasını yenileme | Yeni satış oluşmaması | Yeni kimlikle tekrar olay üretilmemesi |
| Sunucu isteğini yeniden deneme | Aynı olayın teslimi | Kimliğin korunması |
| İki farklı sipariş | İki satın alma | Kimliklerin farklı olması |
| Başarısız ödeme | Başarılı satın alma olmaması | Yanlış tetikleyici bulunmaması |
| Yalnız tek yolun çalışması | Mevcut bildirimin izlenebilmesi | Eksik yolun tanılanabilmesi |
Değer, para birimi ve ürün bilgileri de iki tarafta tutarlı olmalıdır. Bunlar olay kimliğinin yerine geçmez, fakat aynı siparişi tarif eden iki bildirimin farklı tutar taşıması ayrı bir veri kalitesi problemidir.
Entegrasyon envanterini çıkarmak
Mağaza uygulaması, tema kodu, etiket yöneticisi ve sunucu bağlantısı aynı olayı farklı yerlerden gönderebilir. Önce hangi aracın neyi gönderdiğini listelerim. Bir satırda tetikleyici, hedef, olay adı, kimliğin kaynağı ve teknik sorumlu bulunur.
Raporu düzeltmek için bütün bağlantıları sırayla kapatıp açmak yerine, kontrollü testle fazladan bildirimin kaynağını bulurum. Değişiklik öncesi ve sonrası örnekler aynı senaryoya dayanmalıdır. Canlı müşteri bilgilerinin ekran görüntülerini ekip içinde gereksiz yere dolaştırmam; tanılama için asgari test verisi kullanırım.
Son kontrolü iş kaydıyla yapmak
Platformun olay aldığını bildirmesi, bütün siparişlerin doğru sayıldığını tek başına kanıtlamaz. Test işleminin mağaza kaydı ile olay adı, kimliği, değeri ve zamanı karşılaştırılır. Ardından hata ve yeniden deneme senaryoları incelenir. Ölçüm izinleri ve veri paylaşımı tercihleri bu teknik düzeltmeden bağımsız olarak korunmalıdır.
Reklam öncesi dönüşüm kontrolü testin daha geniş çerçevesini sunuyor. Shopify uygulama envanteri de aynı işi yapan entegrasyonların belirlenmesine yardımcı olur. Amaç bütün raporları zorla eşitlemek değil, tek iş olayının anlamını ve gönderim yollarını doğrulanabilir hale getirmektir.