Pixel ve CAPI olay tekilleştirme nasıl kurulur

Pixel ve CAPI olay tekilleştirme, aynı satın almanın hem tarayıcıdan hem sunucudan Meta'ya ulaştığında iki ayrı dönüşüm olarak sayılmasını engelleyen eşleştirme mekanizmasıdır. İki kanalı birlikte çalıştırıyorsanız Meta her satın alma için iki mesaj alır. Eşleştirme kuruluysa panelde tek bir satın alma görürsünüz; kurulu değilse aynı sipariş iki kez yazılır. Bunu fark etmeniz haftalar sürebilir, çünkü hiçbir yerde kırmızı bir hata uyarısı çıkmaz.

Bu yazı kurulum adımlarını anlatmıyor. Sunucu tarafı gönderimin zaten ayakta olduğunu varsayıyor ve tek bir soruya odaklanıyor: iki kanal aynı anda çalışırken sayı neden şişer, bunu panelde nasıl görürsünüz ve hangi değişiklikler eşleştirmeyi sessizce bozar.

Pixel ve CAPI olay tekilleştirme tam olarak neyi eşleştirir

Meta gelen iki kaydı karşılaştırırken iki alana bakar: event_name ve event_id. İkisi de birebir aynıysa ikinci kayıt elenir ve olay bir kez sayılır. Alanlardan biri farklıysa eşleştirme kurulmaz, iki bağımsız olay panele yazılır. Burada benzerlik toleransı yok. Karakter karakter aynı olacak.

Eşleştirmenin bir de zaman sınırı var. Meta gelen olayı sınırlı bir pencere içinde daha önce aldığı kayıtlarla karşılaştırır; o pencerenin dışında gelen ikiz olay artık eleyecek bir eş bulamaz. Bu sürenin güncel değerini Meta'nın resmî dokümanından doğrulayın, çünkü kuyrukta bekleyen veya toplu gönderilen sunucu olaylarında pratikte belirleyici olan tek şey budur.

event_id'yi doğru üretmenin tek kuralı

Kural şu: event_id kullanıcının yaptığı eyleme ait olmalı, olayın gönderimine değil. Aynı satın alma için tarayıcı tarafında ve sunucu tarafında birbirinden bağımsız hesaplandığında ikisi de aynı değeri bulmalı. Bu cümleyi geçen her tasarım çalışır, geçmeyen hiçbiri çalışmaz.

İyi bir event_id nasıl görünür

Satın alma için en sağlam kaynak sipariş numarasıdır; hem teşekkür sayfasına dönen veride hem de sunucuda aynı değerdir. Sipariş numarasına olay adını ekleyerek türetmek de yaygındır, böylece aynı siparişin Purchase ve InitiateCheckout kayıtları birbirine karışmaz. Form ve potansiyel müşteri olaylarında kayıt kimliği ya da sunucunun ürettiği işlem kimliği aynı işi görür.

En sık yapılan üç event_id hatası

• Rastgele üretmek. İki tarafta ayrı ayrı rastgele değer üreten kod her seferinde iki farklı kimlik verir. Eşleşme ihtimali sıfırdır ve kod incelendiğinde kusursuz görünür, çünkü teknik olarak hata yoktur.
• Zaman damgası kullanmak. Tarayıcı olayı ile sunucu olayı aynı saniyede oluşmaz. Saniye hassasiyetli damga tam olarak bu yüzden kayar ve kayma rastgele olduğu için olayların bir kısmı eşleşir, bir kısmı eşleşmez.
• Yalnızca tek tarafa eklemek. event_id sunucu isteğinde vardır ama tarayıcı olayında yoktur. Meta karşılaştıracak alan bulamaz ve iki kaydı da geçerli sayar.

event_name'de tek harf farkı yeter

event_id doğru olsa bile olay adları uyuşmazsa eşleştirme hiç başlamaz. En sık görülen üç uyuşmazlık şudur: sunucudan standart adın küçük harfli hâlinin gitmesi, taraflardan birinin standart olay yerine özel olay adı kullanması, iki tarafın farklı isimlendirme alışkanlığıyla kurulmuş olması. Tarayıcı Purchase gönderirken sunucunun satin_alma göndermesi teknik olarak hatasızdır; Meta bunları iki ayrı olay tipi kabul eder ve zaten eşleştirmeye kalkışmaz.

Denetime olay adından başlamak bu yüzden mantıklı. Olay yöneticisinde aynı veri kümesi altında beklemediğiniz bir olay adı duruyorsa, sorunun kaynağını çoğu zaman orada bulursunuz. Piksel tarafındaki daha genel kurulum ve veri hatalarını Pixel verileri yanlış geldiğinde yazısında ayrıca ele almıştık.

Tekilleştirme raporunu okumak

Olay yöneticisinde veri kümesini açıp bir olayın detayına indiğinizde, o olayın hangi kanaldan kaç kez alındığını ve kaçının elendiğini gösteren bir kırılım bulunur. Bakmanız gereken üç sayı var: tarayıcıdan alınan olay sayısı, sunucudan alınan olay sayısı ve tekilleştirilmiş olarak işaretlenen sayı.

Sağlıklı bir kurulumda ilk iki sayı birbirine yakındır ve elenen sayı, ikisinden küçük olanına yakın seyreder. Örnek üzerinden gidelim. Bir hafta boyunca Purchase olayı için tarayıcıdan 100, sunucudan 100 kayıt geldiğini, tekilleştirilmiş olarak işaretlenen sayının ise 75 olduğunu görüyorsunuz. Toplam gelen kayıt 100 + 100 = 200. Bunun 75'i elendiğine göre panele yazılan olay sayısı 200 eksi 75, yani 125 olur. Gerçekte 100 satın alma yaşanmıştı; 25 olay fazladan sayıldı.

Bu kırılımı haftalık okumanın asıl faydası, elenen sayının yavaşça düşmesini fark edebilmektir. Tekilleştirme genelde bir gecede tamamen çökmez. Önce tek bir sayfada ya da tek bir ödeme yönteminde bozulur, oran sessizce erir ve siz haftalar sonra yalnızca sonucu görürsünüz.

Şişen sayının bedelini bir hafta üzerinden hesaplayın

Yukarıdaki örneği paraya çevirelim ve aynı hafta içinde kalalım. Reklam harcamanız 20.000 TL, ortalama sipariş değeriniz 400 TL olsun. Panelin gördüğü 125 satın alma 125 × 400 = 50.000 TL gelir anlamına gelir; raporlanan ROAS 50.000 ÷ 20.000 = 2,5 çıkar. Gerçekte olan 100 satın alma ise 100 × 400 = 40.000 TL gelirdir ve gerçek ROAS 40.000 ÷ 20.000 = 2,0'dır. Panel, gerçeğin 1,25 katı bir sonuç gösteriyor.

Hedef ROAS'ınız 2,2 ise bu fark doğrudan yanlış karara dönüşür. Panele bakıp bütçeyi artırırsınız, oysa kampanya hedefin altındadır. Kendi hesabınızda aynı karşılaştırmayı yapmak için ROAS hesaplama aracını kullanıp panelin gösterdiği sayı ile mükerrer olayları düştüğünüz sayıyı yan yana koyabilirsiniz.

Bir uyarı: panel ile mağaza raporu arasındaki farkın tek sebebi tekilleştirme değildir. İade, iptal ve atıf penceresi de fark yaratır. Yukarıdaki örnek bilerek yalnızca mükerrer olayın etkisini yalıtıyor, mutabakatın tamamını değil.

Tekilleştirme sessizce nasıl bozulur

Kurulum günü çalışan bir yapı, kimse ona dokunmadan da bozulabilir. Sahada en sık karşılaşılan durumlar şunlar:

• Tema veya uygulama güncellemesi. Teşekkür sayfasındaki olayı basan şablon değişince event_id'yi taşıyan değişken boşalır. Olay hâlâ gider, içindeki kimlik gitmez.
• İkinci bir piksel. Bir uygulama ya da eski bir kod parçası kendi Purchase olayını basar. Bu ikinci olayda event_id yoktur, dolayısıyla eleneceği bir eşi de yoktur.
• Teşekkür sayfasının yenilenmesi. Kullanıcı sayfayı yenilerse tarayıcı olayı tekrar tetiklenir. event_id sipariş numarasına bağlıysa ikinci kayıt elenir; oturuma veya zamana bağlıysa yeni bir kimlikle gider ve sayılır.
• Gecikmeli sunucu gönderimi. Kuyruk birikince sunucu olayı eşleştirme penceresinin dışına düşer. Alanlar doğrudur, zamanlama değildir.
• Kısmi kapsam. Sunucu olayı yalnızca belirli bir ödeme yöntemi için tetikleniyorsa, diğer yöntemlerde tek kanal çalışır ve tablo ilk bakışta normal görünür.

Haftada on dakikalık kontrol

Bu işi kalıcı kılan şey kurulum değil, düzenli bakış. Şu dört adımı haftalık rutine alın:

• Purchase olayında tarayıcı, sunucu ve elenen sayıları not edin; geçen haftaya göre elenen oranın düştüğü hafta araştırma haftasıdır.
• Bir test siparişi geçip her iki kanalın da aynı event_id ile geldiğini olay yöneticisinden teyit edin.
• Tema, ödeme altyapısı ya da uygulama güncellemesi yapıldıysa bu kontrolü güncelleme sonrası aynı gün tekrarlayın.
• Veri kümesi altında beklemediğiniz olay adları oluşmuş mu bakın; yeni bir ad genelde yeni bir mükerrer kaynağı demektir.

Mükerrer olaylar yalnızca raporu bozmaz. Otomatik teklif ve yapay zekâ destekli hedefleme tarafındaki her karar, hangi kullanıcının gerçekten dönüştüğü bilgisine dayanır; aynı kişiyi iki kez dönüşmüş gibi göstermek bu girdiyi kirletir. Pikselin temel çalışma mantığını tazelemek isterseniz Facebook Pixel nedir yazısı iyi bir başlangıç noktası, ama tekilleştirme tarafında iş her zaman aynı iki alana bakıp aynı üç sayıyı okumaya iner.