Meta hangi satışın senden geldiğini bilmiyor

Klasik Meta Pixel tarayıcıda çalışan bir JavaScript parçasıdır. Yani satın alma olayının Meta'ya ulaşması, kullanıcının tarayıcısının o isteği göndermesine bağlıdır — ve tarayıcılar son yıllarda tam da bu tür istekleri kısıtlamak üzere yeniden tasarlandı.

Safari'nin arkasındaki WebKit, 2020'de çapraz site kaynakları için çerezlerin varsayılan olarak tamamen engellendiğini duyurdu ve aynı güncellemeyle script'in yazabildiği tüm depolama biçimlerine — LocalStorage, IndexedDB, SessionStorage, Service Worker kayıtları dâhil — yedi günlük bir üst sınır getirdi: kullanıcı siteyle etkileşime girmezse bu veriler siliniyor (WebKit, 2020). Buna reklam engelleyicileri, ağ hataları ve "teşekkürler" sayfasına hiç uğramadan biten ödeme akışlarını da ekle.

Sonuç: tarayıcı tarafında ölçülen her satın alma, gerçekleşen her satın almanın yalnızca bir alt kümesidir. Meta'nın buna cevabı sunucu taraflı Conversions API — olayı kullanıcının tarayıcısı yerine kendi sunucundan göndermek. Doğru kurulum bugün "Pixel ya da CAPI" değil, ikisinin birlikte ve birbirini tanıyarak çalışmasıdır.

Kurulum "var/yok" ikilisi değil, bir kalite ölçeği. Meta'nın Dataset Quality dokümantasyonu, bir veri kümesinin sağlığını ölçmek için birbirinden bağımsız birkaç metrik tanımlıyor — ve bunların hepsi Events Manager'da görünür (Meta for Developers). Pratikte en sık şu beş noktada kırılıyor:

1. Purchase olayı değersiz gidiyor

Meta'nın Pixel referansına göre Purchase olayında currency ve value zorunlu alanlar (Meta for Developers). Bunlar boş giderse Meta satışın olduğunu bilir ama kaç liralık olduğunu bilmez — ROAS hesabın ve değer optimizasyonun temelsiz kalır. Aynı referans, AddToCart ve ViewContent için contents/content_ids alanlarını Advantage+ katalog reklamlarında zorunlu tutuyor; katalog reklamı yayınlıyorsan bu alanların eksikliği doğrudan formatın çalışmaması demek.

2. Sunucu tarafı olayların kapsamı düşük

Conversions API'yi "kurmak" tek bir olayı sunucudan göndermek değil. Meta bunu event coverage adıyla ölçüyor: Pixel olaylarının yüzde kaçının, deduplication anahtarlarını paylaşan bir Conversions API olayıyla karşılandığının 7 günlük ortalaması. Dokümantasyondaki örnek net: bir reklamverenin ViewContent, AddToCart ve Purchase olayları varsa ve sunucudan yalnızca Purchase gönderiliyorsa event coverage %33 olur. Aynı doküman %75'i eşik olarak kullanıyor (Meta for Developers).

3. Eşleşme anahtarları zayıf

Event Match Quality (EMQ), sunucundan gönderdiğin müşteri bilgilerinin olayı bir Meta hesabıyla eşleştirmede ne kadar etkili olabileceğini gösteren 10 üzerinden bir puan. Meta'ya göre bu puan, hangi müşteri bilgisi parametrelerinin geldiğine, gelen bilginin kalitesine ve olay örneklerinin yüzde kaçının bir Meta hesabıyla eşleştiğine bakılarak hesaplanıyor; ve yüksek kaliteli eşleşme reklam atfını ve performansını iyileştirebiliyor (Meta for Developers). Dikkat: Meta bunu "iyileştirir" diye değil, "iyileştirebilir" diye yazıyor — biz de öyle aktarıyoruz.

4. Olaylar geç gidiyor

Data freshness, olayın gerçekleşmesiyle Meta'ya ulaşması arasındaki gecikmeyi ölçer. Pixel varsayılan olarak gerçek zamanlı gönderir; sunucu tarafında ise günlük toplu (batch) gönderim yapan kurulumlar yaygındır. Meta olayların gerçek zamanlı ya da mümkün olduğunca gerçek zamana yakın paylaşılmasını öneriyor ve gecikmeli gönderilen olayların reklamların doğru kitlelere ne kadar etkili ulaştırılabileceğini etkileyebileceğini belirtiyor (Meta for Developers).

5. Sunucu yanlış IP gönderiyor

Dokümantasyondaki tanı (diagnostics) örneklerinden biri doğrudan bu konuda: sunucunun, Meta Pixel'inkiyle eşleşmeyen istemci IP adresleri göndermesi — Meta'nın kendi ifadesiyle bu, kampanyalarının atfını ve optimizasyonunu etkileyebilir. Çözüm olarak sunucu yükünde müşteri etkileşiminden alınan client_ip_address değerinin gönderilmesi öneriliyor. Bu, sunucu tarafı kurulumu bir geliştiriciye "kur gitsin" diye bıraktığında en sık atlanan ayrıntılardan biri.

Pixel ve Conversions API'yi aynı olaylar için birlikte kullanıyorsan Meta aynı satın almayı iki kanaldan alır. Bunları tek olaya indirgemesi için deduplication kurulmuş olmalı — kurulmamışsa panelde şişmiş, gerçekte olmayan satışlar görürsün.

Bir olayın deduplicate edilmesi için: Facebook Pixel'in eventID değeri Conversions API'nin event_id değeriyle eşleşmeli ve Pixel'in olay adı Conversions API'nin event_name değeriyle eşleşmelidir.

— Meta for Developers, Deduplicate Pixel and Server Events

Mekaniğin bilmen gereken üç ayrıntısı var (Meta for Developers):

• Aynı event_id + event_name kombinasyonu aynı pixel ID'ye 48 saat içinde ikinci kez gelirse sonraki olaylar atılır. 48 saatten sonra gelen kopya ayrı bir olay sayılır — yani gece toplu gönderim yapan bir sunucu entegrasyonu, gecikme uzarsa çift sayıma dönüşebilir.
• Sunucu ve tarayıcı olayı birbirine yakın zamanda (yaklaşık 5 dakika içinde) gelirse Meta tarayıcı olayını tercih eder.
• Farklı olayları farklı kanallardan göndermek de meşru bir kurulumdur: örneğin Purchase'ı Pixel'den, AddToCart'ı Conversions API'den gönderiyorsan deduplication'ı hiç düşünmen gerekmez. Karar vermen gereken şey, hangi olayın hangi kanaldan gideceği.

Pixel tarafında eventID, fbq('track', ...) çağrısına dördüncü parametre olarak veriliyor; Meta, Conversions API ile birlikte çalışan her kurulumda bunu öneriyor (Meta for Developers). Events Manager'daki deduplication key feedback bölümü de olaylarının yüzde kaçının bu anahtarlarla geldiğini gösterir — orada düşük bir yüzde görüyorsan sorun kurulumun kendisindedir.

Meta'nın bunun için ayrı bir metriği var: Additional Conversions Reported (ACR). Tanımı, Conversions API'yi Meta Pixel ile birlikte kullanmanın işletmene ne kadar fayda sağladığını anlamana yardımcı olan bir metrik olması; Meta'ya göre daha fazla raporlanan dönüşüm, sonuç başı maliyeti düşürmene ve reklamlarını onları ilgili bulacak kişilere göstermene yardımcı olabilir (Meta for Developers).

Burada dürüst olmak gerekiyor, çünkü bu metriğin pazarlama içeriklerinde en çok çarpıtıldığı yer burası: ACR raporlanan dönüşümlerdeki artışı ölçer. Yani daha önce de gerçekleşen ama Meta'nın göremediği satışların artık görünür hâle gelmesi. Ciro artışı değil, körlüğün azalması. Ölçümü düzelttiğinde panelindeki satış sayısının yükselmesi beklenen bir sonuçtur — ama o gece kasana giren para değişmemiştir.

Faydası dolaylı ve gerçektir: daha eksiksiz sinyal, yayınlama sisteminin kimi hedefleyeceğini daha iyi öğrenmesi demektir. Bunun performansa yansıması ise zamanla ve garantisiz olur.

Ölçümün mükemmel çalıştığı durumda bile cevaplanmamış bir soru kalır: Meta'nın sana atfettiği satış, reklamı hiç görmese de olacak bir satış mıydı? Atıf (attribution) ile artımsallık (incrementality) aynı şey değildir.

Bu ayrımın en bilinen akademik kanıtı Facebook'un kendi verisiyle yapılmış bir çalışma. Gordon, Zettelmeyer, Bhargava ve Chapsky, Facebook'ta yürütülen 15 ABD reklam deneyini — 500 milyon kullanıcı-deney gözlemi ve 1,6 milyar reklam gösterimi — rastgele kontrollü deney sonuçlarıyla gözlemsel yöntemlerin sonuçlarını karşılaştırarak inceledi. Bulgu: gözlemsel yöntemler, kapsamlı demografik ve davranışsal değişkenler kontrol edildikten sonra bile çoğu zaman deneylerle aynı etkileri üretemedi (Gordon ve diğerleri, 2019).

Bunun pratikteki karşılığı şu: ölçüm altyapını düzeltmek, gördüğün rakamın doğru sayılmasını sağlar; o rakamın reklamın yarattığı fark olduğunu kanıtlamaz. Bütçeyi ciddi biçimde ölçekleyeceğin noktada ihtiyacın olan şey daha iyi bir pixel değil, bir deney tasarımıdır (kapalı/açık test, coğrafi bölme, marka arama hacmi kontrolü). Kreatif tarafında bu deneyi nasıl kuracağını ve kazananı ne zaman ciddiye alabileceğini beş hook'u test etme yazımızda ayrıntılandırdık.

Events Manager üzerinden yarım saatte yapabileceğin bir denetim listesi:

• Test Events aracıyla bir deneme siparişi geç: ViewContent → AddToCart → InitiateCheckout → Purchase zincirinin tamamı düşüyor mu?
• Purchase olayında value ve currency dolu mu — ve değer sepetin gerçek tutarıyla mı eşleşiyor, yoksa kargo/vergi dâhil edilmiş sabit bir sayı mı?
• Deduplication key feedback: tarayıcı ve sunucu olaylarının yüzde kaçı event_id ile geliyor?
• Event coverage: kaç olayın sunucu tarafı karşılığı var, %75 eşiğinin neresindesin?
• EMQ: Purchase için puanın kaç, hangi eşleşme anahtarları eksik görünüyor?
• Data freshness: sunucu olayların real_time mı, hourly/daily mi?
• Diagnostics sekmesindeki uyarılar — özellikle IP eşleşmezliği — çözülmüş mü?

Bu listenin çoğu, reklam bütçesi harcamadan önce halledilmesi gereken işler. Reklam tarafının bütününe bakmak istersen güzellik markaları için Instagram reklamlarına başlangıç rehberimiz bu kurulumu daha geniş bir çerçeveye oturtuyor; ölçümün yarısı mağaza tarafında kırıldığı için kozmetik markası için Shopify mağaza kurulumu rehberine ve web & e-ticaret hizmetimize de bakmanı öneririz.