Bir sipariş iki satış gibi görünüyorsa: Mükerrer dönüşümü bul

Aynı siparişin iki kez görünmesi neyi anlatır?

Bir sipariş tamamlandıktan sonra teşekkür sayfası yenileniyor. Tarayıcı aynı satın alma bilgisini tekrar gönderiyor. Birkaç saniye sonra sunucunun gönderimi de geliyor. Elinde üç kayıt olabilir; fakat müşterinin üç kez sipariş verdiğini henüz bilmiyorsun. Önce ticari işlem ile bu işlemi taşıyan teknik mesajları ayırman gerekir.

Mükerrer kayıt incelemesinin amacı sayıyı küçültmek değildir. Gerçek siparişleri koruyup aynı olayın tekrar gönderimlerini doğru ilişkilendirmektir. Gereğinden sert bir tekilleştirme, birbirinden farklı siparişleri birleştirerek satışları eksik sayabilir. Bu nedenle “tekrar var, hepsini sil” yaklaşımı da yanlış sonuç üretebilir.

Bu rehber bir veri inceleme ve düzeltme yöntemi sunuyor. Canlı reklam hesabında işlem yapmıyor. İndirilebilir örneği, kendi sipariş kaydın ile ölçüm gönderimlerini nasıl karşılaştıracağını öğrenmek için kullanabilirsin.

Üç farklı kimliği birbirine karıştırma

Aynı iş olayı yeniden gönderildiğinde gönderim denemesi değişebilir; ticari işlemin kimliği değişmemelidir. Buna karşılık müşterinin yeni ve ayrı bir siparişi eski kimliği kullanmamalı. Tekrarlanan abonelik tahsilatı, iade veya değişim gibi akışlarda hangi olayın yeni işlem sayılacağını iş kurallarınla açıkça tanımla.

Kendi kayıtlarında sipariş kimliği, olay türü, hedef sistem ve gönderim zamanı alanlarını birlikte tut. Bir platformun beklediği kimlik alanıyla kendi veri tabanın arasında açık bir eşleme olsun. Tek bir sütuna bazen müşteri kimliği, bazen sipariş numarası yazmak incelemeyi bozar. Kimliğe e-posta, telefon veya ad ekleyerek benzersizlik sağlamaya çalışma.

Yalnız sipariş numarasına göre bütün olayları silmek de doğru değildir. Aynı siparişte bir purchase ve daha sonra bir refund bulunması beklenebilir. Ticari işlem bağlantısı korunurken olay türleri ayrı anlam taşır.

Platformun kuralını kendi varsayımından ayır

Google’ın işlem kimliği belgesi satın alma tekilleştirmesini web akışlarında transaction_id üzerinden açıklar; uygulama akışlarına aynı kuralı genellemez. Her siparişin kimliği benzersiz ve boş olmayan bir değer olmalı, müşteri kişisel bilgisi içermemelidir. Boş metin göndermek veya farklı işlemlerde aynı değeri kullanmak eksik sayım oluşturabilir.

Meta’nın resmî tekilleştirme belgesinde event_id ve event_name eşleşmesi ele alınır. Tarayıcı ve sunucu gönderimlerini bu alanları birlikte kontrol ederek incele. Tek bir alanı benzetmek, bütün platform koşullarının sağlandığını kanıtlamaz. Entegrasyonunun güncel uygulama ayrıntısını ilgili platform belgesiyle karşılaştır.

Bu iki sözleşmeyi birbirinin yerine koyma. GA4 alan adı transaction_id iken Meta gönderimindeki kimlik alanının adı ve kullanım yeri farklıdır. “Bizde order_id var” demek, onun doğru parametreye ulaştığını göstermez. Gerçek gönderimin alanını, değerini ve tipini kontrol et; yalnız kurulum ekranındaki ayara bakmakla yetinme.

Altı ham satırı dört siparişe bağlayalım

Aşağıdaki kayıtlar eğitim için üretilmiş sentetik gönderimlerdir. D101–D104 ticari kayıtlarında dört ödenmiş sipariş bulunduğunu biliyoruz. Gönderimlerdeki order_ref bizim denetim alanımızdır; platformdan otomatik dönen sipariş eşlemesi değildir. Tutarlar indirim sonrası ürün değeri, vergi ve kargo hariç TL’dir.

Ham satırlar 950 TL’ye ulaşıyor. Ticari kaydın dört benzersiz siparişi ise 100 + 150 + 200 + 250 = 700 TL. Bu 250 TL fark, yeniden gönderilen D101 ve D102 değerlerinin toplamı. Ancak “GA4 kesin altı satın alma sayar” diyemeyiz; hedefin işlemesi ve tekilleştirme davranışı ayrıca incelenmelidir.

Bu örnekte doğru cevap, ham olay toplamını düzeltip her şeyi bitirmek değildir. E002’nin tekrar olduğunu, E004’ün kimlik üretme hatası taşıdığını ve E005/E006’nın ayrı gerçek siparişler olmasına rağmen kimliksiz gönderildiğini ayrı ayrı kaydetmelisin.

Cevap anahtarı: Hangi satır korunur, hangisi araştırılır?

Denetim tablosunda D101 için tek ticari satın alma ve iki gönderim bulunur. D102 için de tek ticari satın alma vardır; “-retry” eki yeni sipariş kanıtı değildir. D103 ile D104 ayrı siparişlerdir. İki kimlik alanı da boş diye bunları aynı ticari işlem kabul etmek yanlış olur. Kendi sipariş kaydına dayanan beklenen sonuç dört sipariş ve 700 TL’dir.

Bu bilgi, geçmiş platform raporunu elle değiştirme izni vermez. Önce hangi gönderimlerin hedef tarafından kabul edildiğini, nasıl işlendiğini ve hangi dönemleri etkilediğini belirle. Yeni uygulamada kimliğin doğru üretilmesini sağlamak ile geçmiş raporu düzeltmek farklı işlerdir. Platformun desteklediği düzeltme yolunu araştırmadan eski bütün olayları yeniden gönderme.

Çalışma dosyası her satıra beklenen açıklamayı ekler. Kendi verinde bu açıklama kanıta dayanmalı. Aynı tutar ve yakın zaman tek başına tekrar kanıtı değildir; iki farklı müşteri aynı fiyattan alışveriş yapabilir. Aynı müşteri de iki ayrı sipariş verebilir. Eşleştirme kararını ticari olayın kimliğine bağla.

Hatayı veri akışındaki yerine göre düzelt

Kimliği yalnız tarayıcıda sayfa açıldığında rastgele oluşturuyorsan, sayfa yenilendiğinde yeni kimlik çıkabilir. Siparişin güvenilir kaydında oluşturulmuş ticari kimliği ilgili gönderimlere tutarlı biçimde taşımak daha incelenebilir bir tasarımdır. Bu, burada önerdiğimiz veri sözleşmesidir; mevcut platform entegrasyonuna uyarlaması ayrıca yapılmalıdır.

• Tetikleyici: Satın alma olayı hangi doğrulanmış durumdan sonra üretiliyor?
• Kimlik: Aynı iş olayının tekrarında aynı değer korunuyor mu?
• Yeniden deneme: İletim hatası yeni sipariş gibi kayda geçiyor mu?
• Birden fazla kaynak: Tarayıcı, sunucu ve varsa eklenti aynı olayı nasıl tanıyor?
• Yeni işlem: Ayrı sipariş gerçekten yeni kimlik alıyor mu?

Birden fazla eklenti veya etiket aynı işi yapıyorsa hangisinin olay üretiminden sorumlu olduğunu belirle. İkinci kaynağı körlemesine kapatmak ölçüm kapsamını da azaltabilir. Önce kaynakları say, ne gönderdiklerini göster ve sorumluluk sözleşmesini düzelt. Düzeltmenin amacı güvenilir tekil olay üretimi ve incelenebilir gönderimdir.

Yayına geçmeden anlamlı senaryoları doğrula

Tek bir başarılı satın alma testi yeterli değildir. Uygulamanın tekrar ve istisna davranışını da kontrol et. Aynı işlemi tekrar okuduğunda veya gönderim geciktiğinde ticari olayın kimliği değişiyor mu? Ödeme başarısız olduğunda purchase çıkıyor mu? Yeni ve ayrı siparişin kimliği öncekiyle çakışıyor mu?

Google e-ticaret ölçüm rehberi satın alma ve iade için ayrı olaylar tanımlar. Bu yüzden iade testini satın alma tekrarından ayrı değerlendir. Test ortamındaki kayıtları gerçek performans raporuna karıştırmama yöntemini de açıkça seç.

Düzeltmeyi ölç, tarihî seriye açıklama ekle

Bir düzeltme sonrasında raporlanan satın alma sayısı düşebilir. Bu durum satışların gerçekten azaldığını göstermeyebilir; önceki fazladan gözlemler ortadan kalkmış olabilir. Uygulama tarihini, değişen ölçüm koşulunu ve beklenen etkisini değişiklik günlüğüne yaz. Aynı dönem için ticari sipariş kayıtlarını da kontrol et.

Yalnız ham olay / sipariş oranına tek bir alarm eşiği koymak yerine kaynak, olay türü ve gönderim durumu bazında incele. Çift kanalın aynı olayı taşıması mimarinin beklenen parçası olabilir. Asıl sorular, ticari kimliğin korunup korunmadığı ve hedefin ilgili sözleşmeye göre işleyip işlemediğidir.

Çalışma dosyasını kullandıktan sonra geliştiriciye “Sayı iki kat” diye genel bir not göndermek yerine örnek kayıt, beklenen işlem, gözlenen parametre ve etkilenmiş kapsamı ver. Düzeltme tamamlandığında aynı senaryoyu yeniden çalıştır ve sonucu kaydet. Böylece tekilleştirme, raporu süsleyen bir ayardan denetlenebilir bir iş kuralına dönüşür.