Deduplication Nedir?

Sayılarla ne demek?

Ölçüm sistemlerinde aynı olayın birden çok kez kaydedilmesinin çok sayıda sebebi var: tarayıcı ve sunucudan çift gönderim, sayfanın yenilenmesi, kullanıcının geri tuşuna basması, aynı etiketin iki kez kurulması.

Tekilleştirme, bunları tek gerçek olaya indirgeme işidir. Yapılmadığında raporlar şişer ve ne kadar şiştiği bilinmez; bu, eksik veriden daha tehlikelidir çünkü iyi görünür.

Eşleşmenin anahtarı genelde olay kimliğidir. Burada ele alınan, kimliğin nasıl üretildiği değil; hangi durumlarda tekrar oluştuğu ve nasıl fark edileceği.

Tekrar nereden gelir?

Son satır ayrı bir tuzak. Meta, Google ve TikTok aynı satışı kendi paneline yazıyor; panellerin toplamı sipariş sayısını aşıyor. Bu bir teknik hata değil, atıf farkı ve hiçbir ayarla giderilemiyor.

Nasıl doğrulanır?

1. Siparişle kıyaslayın. Platform sayısı siparişi aşıyorsa tekrar var.
2. Eşleşme oranına bakın. Platform birleşen kayıtları gösteriyor.
3. Sayfayı yenileyin. Olay ikinci kez gidiyor mu?
4. Kurulumu tarayın. Aynı etiket iki yerde mi?
5. Panelleri toplamayın. Kanal toplamı sipariş değildir.

Uygulamada ne oluyor?

En tehlikeli durum, şişmenin hiç fark edilmemesi. Platform sipariş sisteminden fazla satış gösteriyor, getiri oranı yüksek görünüyor ve bütçe olmayan bir başarıya göre büyütülüyor.

İkinci gözlem, teşekkür sayfasının her yüklemede olay göndermesi. Kullanıcı sayfayı yeniliyor ya da e-postadaki bağlantıdan tekrar açıyor ve aynı sipariş yeniden sayılıyor.

Üçüncüsü, etiket yöneticisine geçişte eski kodun kaldırılmaması. Yeni kurulum çalışıyor, eski kurulum da çalışıyor ve bütün olaylar iki kez gidiyor.

Dördüncüsü, çift gönderimde kimliğin tutmaması. Sunucu tarafı eklenmiş ama eşleşme kurulamamış; sonuç tam olarak ikiye katlanmış bir rapor.

Beşincisi, analitik tarafında sipariş numarasının gönderilmemesi. Aynı işlem numarasıyla gelen tekrarları sistem ayıklayabiliyor; numara yoksa bu koruma çalışmıyor.

Altıncısı, platform toplamlarının sipariş sanılması. Üç kanalın raporu toplanıp yönetime sunuluyor ve gerçek ciro olduğundan yüksek gösteriliyor.

Yedincisi, düzeltmenin geriye dönük beklenmesi. Tekrar sorunu giderildiğinde geçmiş veri düzelmiyor; kıyaslar düzeltme tarihinden sonra anlamlı.

Sekizincisi, iade ve iptallerin tekilleştirmeyle karıştırılması. İptal edilen sipariş tekrar değil, ayrı bir durum; ayrıca bir iade olayıyla düşülmesi gerekiyor.

Dokuzuncusu, ara olayların gözden kaçması. Satın almada tekilleştirme kurulmuş ama sepete ekleme çift gidiyor; huni oranları tutarsız görünüyor.

Onuncusu, sorunun yalnızca ani sıçramalarla fark edilmesi. Kurulum baştan hatalıysa sıçrama olmuyor; rapor hep şişik olduğu için normal sanılıyor.

On birincisi, aylık mutabakatın yapılmaması. Platform sayısı ile sipariş sisteminin her ay yan yana konması, tekrar sorunlarının neredeyse tamamını tek bir tabloda ortaya çıkarıyor ve en ucuz kontrol yöntemi.

On ikincisi, tekilleştirmenin tek seferlik bir düzeltme sanılması. Site güncellemeleri, yeni eklentiler ve etiket değişiklikleri tekrarı sessizce geri getirebiliyor; bu yüzden kontrol her büyük değişiklikten sonra yinelenmeli.

Neyi çözmez?

Tekilleştirme, kanallar arası sahiplenmeyi çözmez. Her platform aynı satışı kendine yazmaya devam eder; gerçek toplamı yalnızca sipariş sistemi verir.

Sıkça sorulan sorular

Tekrar olduğunu nasıl anlarım?

Platformun gösterdiği satın alma sayısını aynı dönemin sipariş sayısıyla karşılaştırın.

Panellerin toplamı neden siparişi aşıyor?

Her platform aynı satışı kendine atfediyor. Bu teknik bir tekrar değil, atıf farkı.

Geçmiş veri düzelir mi?

Düzelmez. Kıyaslar düzeltmenin yapıldığı tarihten sonra anlamlı olur. Aynı süreçte karşınıza çıkabilecek CAPI Gateway, Conversions API'yi kod yazmadan, hazır bir sunucu üzerinden hızlıca kurmayı sağlayan Meta çözümüdür.

Bu kavramın bütün resim içindeki yerini Dönüşüm Takibi ve Ölçümleme Rehberi içinde ayrıntılı anlattım.