Sorun CAPI'de değil, iki kaynağın buluşma noktasında
Conversions API'yi kurduktan sonra en sık duyulan iki şikâyet birbirinin zıddıdır: "satışlar iki katına çıktı" ve "eşleşme kalitesi düştü". İkisi de aynı yerden gelir — aynı satın alma olayı hem tarayıcıdan (Pixel) hem sunucudan (CAPI) gönderilir ve Meta'nın bu iki kaydı tek olay olarak birleştirmesi gerekir. Bu birleştirmeye tekilleştirme (deduplication) deniyor.
Meta'nın kendi dokümantasyonu net: aynı olayı iki kanaldan gönderiyorsanız tekilleştirmeyi kurmak zorundasınız. Kurmuyorsanız, raporlanan dönüşüm sayısı gerçek sipariş sayısından yüksek çıkar; optimizasyon da bu şişmiş sinyale göre öğrenir. Yani sorun yalnızca raporu yanlış okumak değil, algoritmayı yanlış beslemektir.
Doğru yöntem: event_id ve event_name birebir aynı olmalı
Önerilen yöntem, her olaya benzersiz bir kimlik vermek. Tarayıcı tarafında `fbq('track','Purchase',{...},{eventID:'SIPARIS-12345'})` çağrısındaki `eventID` ile sunucudan gönderilen `event_id` birebir aynı string olmalı. Aynı şekilde tarayıcıdaki `event` ile sunucudaki `event_name` de eşleşmeli. Meta iki olayın aynı olup olmadığını kimlik ve ad üzerinden belirliyor.
Uygulamada en dayanıklı yaklaşım, kimliği sipariş numarasından türetmektir. Rastgele üretilen bir UUID, tarayıcıya bir değer sunucuya başka bir değer gitme riskini doğurur; sipariş numarası ise iki tarafta da aynı kaynaktan okunur. Ön ek kullanacaksanız (örneğin `purchase-12345`) aynı ön eki her iki tarafta da uygulayın; büyük/küçük harf farkı bile eşleşmeyi bozar.
48 saat kuralı: sunucu olayını geciktirmeyin
Tekilleştirmenin sessiz sınırı zamandır. Meta, olayları yalnızca aynı `event_id` ile gelen ilk olayın alınmasından sonraki 48 saat içinde alınırlarsa tekilleştiriyor. Bu pencerenin dışında gelen ikinci kayıt ayrı bir dönüşüm olarak sayılır.
Bu, gece toplu iş (batch) olarak gönderilen sunucu olaylarını riskli hale getirir. Sipariş cuma akşamı düşüp CAPI olayı pazartesi sabahı gönderildiğinde çift sayım kaçınılmazdır. Ayrıca sunucu olayının `event_time` değeri gönderim anından en fazla 7 gün geriye ait olabilir; bu sınırı aşan tek bir kayıt varsa istek tamamen başarısız olur ve o partideki diğer olaylar da işlenmez.
Pratik kural: sunucu olayını siparişin oluştuğu anda, en kötü ihtimalle dakikalar içinde gönderin. Kuyruk kullanıyorsanız kuyruk gecikmesini izleyin; bu gecikme bir altyapı metriği değil, doğrudan bir ölçüm metriğidir.
İkinci yöntem neden emniyetli değil?
Meta ikinci bir tekilleştirme yöntemi daha tanımlıyor: `event_name` ile birlikte `fbp` (tarayıcı kimliği) ve/veya `external_id` eşleşmesi. Bu yöntem genel olarak yalnızca önce tarayıcıdan, sonra sunucudan gönderilen olaylarda çalışıyor.
Buradaki risk şu: kullanıcı reklam engelleyici kullanıyorsa ya da tarayıcı olayı hiç ulaşmadıysa, sunucu olayı eşleştirilecek bir karşılık bulamaz. Bu durumda o olay elenmez — ki zaten elenmemesi gerekir. Ama tarayıcı olayı gecikmeli olarak sonradan gelirse aynı satış iki kez sayılabilir. Ek olarak, iki olayın içeriği anlamlı biçimde farklı değilse Meta genelde önce geleni tercih ediyor; bu da hangi kaydın hangi parametrelerle atıfa gireceğini belirsizleştirir.
Sonuç: `fbp`/`external_id` yöntemini yedek olarak bırakın, ana yöntem olarak `event_id` kullanın.
Sunucu olayında zorunlu alanlar
CAPI olayında dört alan zorunlu: `event_name`, `event_time`, `user_data` ve `action_source`. Web olaylarında ayrıca `event_source_url` gerekiyor. `action_source` yalnızca bir etiket değil; olayın nereden geldiğini (`website`, `app`, `phone_call`, `physical_store`, `business_messaging` gibi) bildirir ve atıf mantığını etkiler.
Bu alan özellikle çok kanallı satan işletmeler için önemli. Telefonla alınan sipariş ya da mağazada gerçekleşen satış da CAPI ile gönderilebilir; doğru `action_source` ile gönderildiğinde bu satışlar reklam etkisinin ölçümüne girer. Yanlış etiketlenirse web dönüşümü gibi görünüp online performansı olduğundan iyi gösterir.
Sessiz kayıp: hash ve normalizasyon hataları
Çift sayım en azından fark edilir. Asıl sinsi sorun, müşteri bilgisinin yanlış normalize edilip hash'lenmesidir: panelde hiçbir hata çıkmaz, sadece eşleşme oranı düşer. Meta'nın kuralı açık — e-posta, telefon, ad, soyad, doğum tarihi, cinsiyet, şehir, il, posta kodu ve ülke SHA-256 ile hash'lenmeli; `external_id` için hash öneriliyor. Buna karşılık IP adresi, kullanıcı aracısı (user agent), `fbc`, `fbp`, `lead_id`, `page_id` gibi alanlar hash'lenmeden gönderilmeli.
Kritik nokta: normalizasyon hash'ten önce yapılır. Hash aldıktan sonra düzeltme şansınız yoktur, çünkü tek karakterlik fark bambaşka bir çıktı üretir. Aşağıdaki maddeler Türkiye'de en sık kırılan noktalardır.
- Telefon: sembolleri ve baştaki sıfırı kaldırıp ülke kodu ekleyin — "0532 xxx xx xx" değil, "90532xxxxxxx"
- E-posta: baş ve son boşlukları kırpın, tamamını küçük harfe çevirin
- Ad/soyad: küçük harf, noktalama yok; özel karakter kullanılacaksa UTF-8 kodlaması şart
- Türkçe karakter tuzağı: küçük harfe çevirme işlemi dile bağlıdır — "İstanbul" ve "IZMIR" gibi değerlerin çıktısını gözle doğrulayın, i/ı farkı eşleşmeyi bozar
- Şehir/il: küçük harf, boşluk ve noktalama yok ("istanbul", "kocaeli")
- Doğum tarihi: YYYYAAGG biçimi (ör. 19850312)
- Ülke: ISO 3166-1 alpha-2, küçük harf ("tr")
- external_id: tüm kanallarda aynı biçimde üretilmeli; web'de farklı, mobilde farklı üretilen kimlik hiçbir işe yaramaz
Kurulumdan sonra üç kontrol
Birinci kontrol: gerçek bir test siparişi verin ve aynı `event_id` ile hem tarayıcı hem sunucu olayının ulaştığını, tek dönüşüm olarak sayıldığını doğrulayın. İkinci kontrol: haftalık toplam sipariş sayınızı e-ticaret panelinizden alıp Meta'nın raporladığı dönüşüm sayısıyla karşılaştırın — arada sistematik bir kat varsa tekilleştirme çalışmıyordur.
Üçüncü kontrol: müşteri bilgisi alanlarının hangilerinin gerçekten dolu gittiğini sayın. Çoğu kurulumda yalnızca e-posta gönderilir; telefon, ad-soyad ve `external_id` eklendiğinde eşleşme belirgin biçimde iyileşir. Eşleşen olaylar atıf ve optimizasyona girer, eşleşmeyenler yalnızca temel ölçüme yarar — yani optimizasyonu besleyen kısım tam da bu alanlardır.
Kurulumunuzu bu üç kontrolden geçirmediyseniz, mevcut ölçüm altyapınızın ücretsiz bir gözden geçirmesini talep edebilirsiniz.