Meta Pixel ve Conversions API neden birlikte kullanılmalı?

Meta reklamlarında ölçüm uzun süre tek bir JavaScript parçasına emanet edildi: Pixel. O parça bugün hâlâ gerekli, ama tek başına yeterli değil. Tarayıcılar izleme sinyallerini kıstıkça, reklam engelleyiciler yaygınlaştıkça ve mobil işletim sistemleri izin katmanları ekledikçe, tarayıcı üzerinden gönderilen dönüşüm olaylarının bir bölümü Meta’ya hiç ulaşmıyor.

Mesele burada bitmiyor. Eksik olay yalnızca raporu küçültmez; algoritmanın öğrendiği veriyi de bozar. Aşağıda Pixel’in tam olarak ne yaptığını, tarayıcının neden güvenilir bir taşıyıcı olmaktan çıktığını, Conversions API’nin sunucu tarafında hangi boşluğu kapattığını, tekilleştirmenin neden pazarlık konusu olmadığını ve ölçüm bozulduğunda işletmede neyin kırıldığını anlatıyoruz.

Meta Pixel tam olarak ne yapar?

Pixel, sitenize yerleştirdiğiniz bir JavaScript parçasıdır. Ziyaretçi bir sayfayı açtığında, ürün görüntülediğinde, sepete eklediğinde veya satın aldığında tarayıcı üzerinden Meta’ya bir olay gönderir. Olayın yanında eşleştirmeye yarayan sinyaller de gider: Meta’nın kendi birinci taraf çerezleri, reklam tıklamasından gelen tıklama kimliği, tarayıcı bilgisi ve IP adresi.

Meta bu sinyalleri kullanarak olayı bir kişiyle, o kişiyi de gördüğü reklamla eşleştirir. Buradan iki çıktı doğar:

• Atıf. Hangi kampanyanın, hangi reklam setinin, hangi kreatifin satış ürettiğini görürsünüz.
• Optimizasyon sinyali. Teslim algoritması “bu profildeki insanlar dönüşüyor” bilgisini bu olaylardan öğrenir.

Pixel bir raporlama aracı değil, besleme kanalıdır

Pek çok ekip Pixel’i yalnızca rapor üreten bir sayaç sanır. Asıl işlevi beslemedir. Satın alma olayı Meta’ya ulaşmadığında, o satın almayı yapan kişi algoritmanın “dönüşen kullanıcı” havuzuna hiç girmez. Sistem kime benzeyen kişileri arayacağını eksik öğrenir. Rapor küçük görünür; teslim ise sessizce yanlış yöne kayar. İkincisi çok daha pahalıdır.

Tarayıcı artık güvenilir bir taşıyıcı değil

Tarayıcı taraflı ölçüm, tanımı gereği kullanıcının cihazından ve tarayıcı ortamından geçer. O ortam son yıllarda sistematik olarak daraldı.

Çerez ömrü kısıtları ve izleme önleme

Safari’nin izleme önleme mekanizması ve benzeri tarayıcı politikaları, JavaScript ile yazılan birinci taraf çerezlerinin ömrünü belirgin biçimde kısaltıyor. Ziyaretçi reklamı gördüğü gün satın almazsa, tıklamayı taşıyan kimlik satın alma anına kadar yaşamayabilir. Olay yine gönderilir, ama reklamla eşleşmesi zayıflar ya da tamamen kopar.

Reklam engelleyiciler ve içerik blokerleri

Reklam engelleyici, Pixel dosyasının yüklenmesini komple durdurur. Bu durumda “eksik veri” bile üretilmez — olay hiç var olmaz. Aynı sonuç, betik yüklenmeden kapatılan sayfalarda, zayıf mobil bağlantılarda ve bazı uygulama içi tarayıcılarda da ortaya çıkar.

iOS izin katmanı ve modelleme

iOS’un uygulama takibi izni, kullanıcı izin vermediğinde cihaz düzeyindeki eşleştirme sinyallerini sınırlar. Meta bu boşluğu kısmen modelleme ile doldurur. Modellenmiş dönüşüm bir tahmindir ve ölçülmüş dönüşümün yerine geçmez.

Bu kayıpların en can sıkıcı tarafı rastgele olmamasıdır. Kayıp; tarayıcı tercihine, cihaz tipine ve kullanıcı davranışına göre yoğunlaşır. Yani veri yalnızca azalmaz, aynı zamanda yanlı hale gelir: belirli bir segment sistematik olarak eksik raporlanır ve algoritma o segmentin değerini olduğundan düşük görür.

Conversions API ne ekler?

Conversions API, olayı tarayıcı yerine sizin sunucunuzdan Meta’ya gönderir. Kaynak e-ticaret altyapınız, ödeme sağlayıcınızın onay adımı, CRM’iniz veya sunucu taraflı bir etiket yöneticisi olabilir. Üç fark yaratır:

1. Dayanıklılık. Sunucudan giden olay; reklam engelleyicilerden, çerez ömründen ve tarayıcı ayarlarından etkilenmez.
2. Kapsam. Tarayıcının hiç görmediği olayları da bildirebilirsiniz: ödeme sağlayıcısından saatler sonra gelen onay, iptal ve iade, telefonla alınan sipariş, CRM’de nitelikli hale gelen bir lead.
3. Eşleşme kalitesi. Kullanıcının izin verdiği ölçüde e-posta, telefon, ad-soyad veya şehir bilgisi şifrelenmiş biçimde gönderilebilir. Bu, olayın doğru kişiyle eşleşme olasılığını yükseltir.

Kritik nokta şu: Conversions API, Pixel’in yerine geçmez. Tarayıcı tarafı hâlâ tek başına taşıdığı sinyalleri üretir — tıklama kimliği, çerez, referans sayfası, tarayıcı ortamı. En sağlam kurulum, aynı olayın her iki kanaldan da gönderildiği kurulumdur. Fazlalık burada israf değil, sigortadır.

Aynı satış iki kez sayılmasın: event_id ile tekilleştirme

Aynı satın almayı hem tarayıcıdan hem sunucudan gönderiyorsanız, Meta’nın bunların tek bir olay olduğunu anlaması gerekir. Bunu sağlayan mekanizma tekilleştirmedir ve iki alana dayanır: olayın adı ve olayın kimliği.

Kural tek cümledir: aynı dönüşüm için iki kanal da aynı event_name ve aynı event_id değerini göndermelidir.

En temiz yol, kimliği olayın kendisinden türetmektir. Varsayımsal bir örnek: sipariş numarası 10422 olan bir satın almada tarayıcı tarafındaki fbq çağrısına eventID: order-10422 verilir; sunucu tarafındaki istekte de event_name alanı Purchase, event_id alanı order-10422 olur. Meta iki kaydı eşleştirir, birini eler ve tek satış olarak raporlar.

Sahada en sık görülen dört hata:

• İki tarafta ayrı ayrı rastgele kimlik üretmek. İki farklı kimlik, Meta için iki farklı satıştır.
• Kimlik olarak zaman damgası kullanmak. Tarayıcı ile sunucunun saati aynı milisaniyede değildir.
• Olay adlarını farklı yazmak. Bir tarafta Purchase, diğer tarafta satin_alma yazıldığında eşleşme hiç denenmez.
• Sunucu olaylarını gün sonunda toplu göndermek. Tekilleştirme sınırsız bir zaman aralığında çalışmaz; olay geciktikçe eşleşme kaçar.

Kurulumdan sonra Events Manager içindeki test aracı ve tekilleştirme raporu, iki kanalın gerçekten birleşip birleşmediğini gösteren tek doğrulama noktasıdır. “Kurduk, çalışıyordur” burada en pahalı varsayımdır.

Ölçüm bozulunca işletmede ne kırılır?

Eksik ölçüm bir raporlama sorunu gibi görünür. Pratikte bir bütçe dağıtımı sorunudur.

Algoritma yanlış kişileri arar

Teslim modeli, dönüşen kullanıcıların özelliklerinden öğrenir. Satın almaların bir kısmı sisteme hiç ulaşmıyorsa model eksik ve yanlı bir örneklem üzerinden çalışır. Sonuç genellikle sessizdir: kimse ayar değiştirmemiştir, ama edinme maliyeti haftalar içinde yukarı kayar.

Bütçe kazanan yapıdan çekilir

Atıfı eksik ölçülen bir kampanya panelde olduğundan kötü görünür. Ekip mantıklı görüneni yapar ve bütçeyi oradan alır. Gerçekte gelir üreten yapı kapatılmış olur. Ölçüm hatasının doğrudan gelire dönüştüğü nokta burasıdır.

Dışlama ve yeniden pazarlama listeleri delinir

Satın alma olayı düşmeyen müşteri, “satın alanları hariç tut” listesine girmez. Zaten ödeme yapmış kişilere reklam göstermeye devam edersiniz. Frekans yükselir, bütçe erir, müşteri deneyimi bozulur.

Raporlama tartışmaya döner

Panel bir rakam, e-ticaret altyapısı başka bir rakam söylediğinde toplantılar veri okumaktan çıkıp rakam savunmaya döner. Ölçüm altyapısı oturmadan hiçbir performans tartışması sonuçlanmaz.

Kurulumdan sonra kontrol listesi

1. Pixel ve Conversions API aynı olay setini mi gönderiyor?
2. Her dönüşüm için tek bir kimlik üretilip iki kanala da aynı değer veriliyor mu?
3. Tekilleştirme raporu olayların birleştiğini gösteriyor mu?
4. Parametreler eksiksiz mi? Değer ve para birimi yoksa ROAS hesaplanamaz; içerik kimlikleri yoksa katalog kampanyaları çalışmaz.
5. Eşleşme kalitesi izleniyor mu, düşükse hangi alan eksik gidiyor?
6. Rıza yönetimiyle uyumlu mu? Sunucu taraflı gönderim bir muafiyet değildir: kullanıcı reklam çerezlerini reddettiyse Conversions API de tetiklenmemelidir.
7. Test olaylarının yanında canlı trafikte de doğrulama yapıldı mı?

Ölçüm kurulumunuzu birlikte gözden geçirelim

Pixel ile Conversions API’yi birlikte kurmak teknik bir lüks değil; reklam bütçesinin doğru yere gitmesinin ön koşulu. Bu altyapıyı kampanya yönetiminin neresine oturttuğumuzu Meta Ads hizmet sayfamızda anlattık; ölçüm doğru olduğunda bile ROAS’ın neden tek başına karar verdirmediğini ise ayrı bir yazıda ele aldık.

Hesabınızda hangi olayların eksik gittiğini, tekilleştirmenin çalışıp çalışmadığını ve bunun bütçenizde neye mal olduğunu görmek istiyorsanız ücretsiz ön analiz için bize yazın. Bağlayıcı değildir ve ön analiz için reklam hesabınıza tam erişim vermeniz gerekmez.

Sık sorulan sorular

Sadece Conversions API kursam yeterli olmaz mı?

Olmaz. Tarayıcı tarafı, sunucunun üretemeyeceği sinyalleri taşır: reklam tıklamasından gelen kimlik, birinci taraf çerez, referans sayfası, tarayıcı ortamı. Bunlar eşleşme kalitesini doğrudan etkiler. Ayrıca bazı olaylar yalnızca istemci tarafında oluşur. Doğru kurulum “ya biri ya diğeri” değil, ikisinin aynı olayı paralel göndermesidir.

İki kanaldan gönderince dönüşümler iki kat mı görünür?

Kimlikler doğru eşleşiyorsa hayır — Meta olayı tekilleştirir. Eşleşmiyorsa evet, çift sayım olur ve ROAS olduğundan yüksek görünür. Bu yüzden kurulumun kabul kriteri “olaylar gidiyor mu” değil, “tekilleştirme raporu birleştiğini gösteriyor mu” olmalıdır.

Conversions API kurmak için mutlaka yazılımcı gerekir mi?

Her zaman değil. Yaygın e-ticaret altyapılarının çoğunda hazır bir entegrasyon veya uygulama bulunur; sunucu taraflı etiket yöneticileri de araya kod yazmadan kurulabilir. Özel akışlar — CRM’de nitelenen lead’ler, çok adımlı ödeme süreçleri, abonelik yenilemeleri — geliştirici desteği ister.

KVKK açısından sunucu taraflı ölçüm sorun yaratır mı?

Sunucu taraflı olmak bir muafiyet sağlamaz. Aydınlatma yükümlülüğü, açık rıza ve veri minimizasyonu aynen geçerlidir. Kişisel veriler yalnızca şifrelenmiş biçimde ve yalnızca gerekli alanlarla gönderilmeli, kullanıcı reklam çerezlerini reddettiğinde sunucu taraflı gönderim de durmalıdır.