Pixel mi Conversions API mi yoksa ikisi birden mi

Pixel mi Conversions API mı sorusunun kısa cevabı şudur: bu ikisi birbirinin alternatifi değil, aynı olayın iki farklı taşıma yolu. Tarayıcı tarafı ölçüm satın alma, sepete ekleme veya form gönderimi gibi olayları kullanıcının cihazında oluşturur ve oradan gönderir. Sunucu tarafı ölçüm aynı olayı sizin altyapınızda oluşturur ve reklam platformuna sizin sunucunuzdan iletir. Dolayısıyla verilecek karar "hangisi daha iyi" değil, "sunucu tarafını da eklemek bu hesapta şu an mantıklı mı" kararıdır.

Pixel mi Conversions API mı ikilemi neden yanlış kurulur

Soru çoğunlukla iki ürün arasında seçim yapma isteğiyle sorulur. Oysa ikisi aynı veri kümesini besleyen iki kaynaktır ve aynı anda açık olabilirler. Tarayıcı tarafını kurup sunucu tarafını hiç açmamak çok yaygın bir durumdur, tersi ise nadirdir. Bu yazının konusu kurulum değil karar; tarayıcı tarafındaki kurulumun kendisini Facebook Pixel nedir yazısında ele almıştık.

İkisini birlikte çalıştırdığınızda aynı satın almanın iki kez sayılmaması için olaylara ortak bir event_id verilir. Bu eşleştirmenin nasıl kurulduğu ve hangi durumlarda sessizce bozulduğu başlı başına ayrı bir konudur. Burada tek not edeceğiniz şey şu: iki kaynak birden açıksa tekilleştirme de kurulmuş olmalıdır.

İki taşıma yolunun gerçekten ayrıştığı noktalar

Karşılaştırmayı özellik listesi üzerinden değil, üç somut soru üzerinden yapmak daha faydalı olur.

• Olay nerede doğuyor? Tarayıcı tarafında olay kullanıcının cihazında tetiklenir. Sunucu tarafında ise sizin sisteminizde, çoğunlukla sipariş kaydı oluştuğu anda tetiklenir.
• Araya kim girebiliyor? Cihazda çalışan bir şey cihazda engellenebilir: reklam engelleyici eklentiler, tarayıcı izleme korumaları, çerez onayının reddedilmesi, sayfa yüklenmeden sekmenin kapanması. Sunucunuzdan giden istekler reklam engelleyici eklentiler ve sayfa yükleme sorunları gibi tarayıcı katmanlarına genellikle takılmaz. Buna karşılık sunucu tarafı kendi hata kaynaklarını getirir; kırılan bir entegrasyon hiçbir uyarı vermeden veri göndermeyi bırakabilir.
• Hangi bilgiyi taşıyabiliyor? Tarayıcı tarafı kullanıcının site içindeki davranışını ve oturum bağlamını bilir. Sunucu tarafı ise yalnızca sizin veri tabanınızda olan şeyi bilir: onaylanmış sipariş, gerçek tahsil edilen tutar, iade, çağrı merkezinde kapanan satış. Her iki taraf da diğerinin göremediği bir şeyi görür.

Tek bir kaynakla kaldığınızda ne kaybediyorsunuz

Yalnızca tarayıcı tarafıyla çalışan bir hesapta kayıp sessizdir. Rapor eksik gösterir ama hiçbir ekranda "şu kadar olay kayboldu" yazmaz. Bu eksiklik sadece raporu bozmaz; kampanya optimizasyonu da platforma ulaşan olaylara göre çalıştığı için karar zinciri baştan eksik veriyle beslenir.

Yalnızca sunucu tarafıyla çalışmak ise bambaşka bir açık üretir. Satın alma sunucudan temiz gider, ancak ürün görüntüleme, arama, sepete ekleme gibi ara adımlar sizin altyapınızda kayıt altına alınmıyorsa hiç gitmez. Yeniden pazarlama kitlelerinizin büyük kısmı tam olarak bu ara adımlara dayanır. Yani sunucu tarafı, satış tarafını sağlamlaştırırken kitle tarafını inceltebilir.

Kendi hesabınızdaki açığı 30 günde ölçmek

Bu kararı vermek için sektör ortalamasına ihtiyacınız yok, kendi açığınızı ölçebilirsiniz. Son 30 günü seçin ve iki sayıyı yan yana koyun: reklam platformunun raporladığı satın alma sayısı ile e-ticaret veya sipariş yönetim panelinizdeki gerçek sipariş sayısı. Örnek olarak platform tarafında 300, kendi panelinizde 380 sipariş göründüğünü varsayalım. Fark 80 sipariştir ve gerçek sipariş sayısına oranı 80 ÷ 380 = 0,21, yani yaklaşık %21 eder.

Bu %21 bir sektör verisi değil, sadece bu örnekteki iki sayıdan çıkan orandır; sizin hesabınızda tamamen başka bir sonuç çıkabilir. Ayrıca bu oran 30 günlük bir ölçümdür, birazdan yapacağımız maliyet hesabı ise 12 aylıktır. İkisini aynı cümlede karıştırmayın.

Farkın tamamının tarayıcı tarafı kaybından geldiğini de varsaymayın. Yanlış kurulmuş bir olay, iki kez tetiklenen bir teşekkür sayfası veya iptal edilen siparişler de aynı farkı üretebilir. Bu ayrımı yapmadan sunucu tarafına geçmek, yanlış sorunu pahalı bir çözümle kapatmak olur; önce olası ölçüm hatalarını Pixel verileri yanlış yazısındaki kontrol listesiyle eleyin.

İkisi birden kararının maliyet tarafı

Sunucu tarafı ölçüm ücretsiz değildir: kurulum işi, geliştirici zamanı, çoğu kurulumda barındırma ve sonrasında süregiden bakım. Karar, bu maliyeti hesabınızın büyüklüğüne oranladığınızda netleşir.

Bir örnek üzerinden gidelim. Aylık reklam harcaması 60.000 TL olan bir hesabın 12 aylık harcaması 12 × 60.000 = 720.000 TL eder. Kurulum ve ilk 12 ayın bakımı için aldığınız teklifin toplamı 24.000 TL olsun. Bu durumda ölçüm yatırımı 24.000 ÷ 720.000 = 0,033 ile 12 aylık harcamanızın yaklaşık %3,3'ü kadardır.

Şimdi aynı teklifi aylık 5.000 TL harcayan bir hesaba taşıyın. O hesabın 12 aylık harcaması 12 × 5.000 = 60.000 TL'dir ve aynı 24.000 TL, 24.000 ÷ 60.000 = 0,4 ile 12 aylık harcamanın %40'ına denk gelir. Kurulum aynı, fiyat aynı, karar tamamen farklı. Harcama on iki kat küçüldüğünde oransal yük de tam olarak on iki kat büyür, çünkü 720.000 ÷ 60.000 = 12.

Buradan çıkan pratik kural şu: sunucu tarafı ölçüm, kayıp sinyalin size maliyeti kurulum ve bakım tutarını aştığında mantıklıdır. Küçük harcamalı bir hesapta bu eşiğe ulaşmak zordur ve önce tarayıcı tarafındaki hataları düzeltmek çok daha yüksek getirili bir iştir.

Ölçüm katmanını değiştirdiğinizde raporlanan dönüşüm sayısı, dolayısıyla raporlanan ROAS da kayar. Öncesi ile sonrasını karşılaştırırken iki dönemi de aynı formülle hesaplayın; ROAS hesaplama aracı bunun için yeterli. Aksi halde ölçüm değişikliğinin yarattığı kaymayı performans artışı sanırsınız.

Karar vermeden önce resmî dokümandan doğrulayacaklarınız

Bu alan sık değişiyor. Bu yüzden aşağıdaki maddeleri burada yazdığı için değil, Meta'nın güncel resmî dokümanından doğruladığınız için kabul edin.

• Sunucu tarafı gönderim için hangi müşteri bilgisi alanlarının kabul edildiği ve bu alanları göndermenin sizin tarafınızda KVKK açısından nasıl karşılandığı.
• Erişim ve izinlerin kimde olması gerektiği: reklam hesabı yöneticisi mi, işletme yöneticisi mi, ayrı bir sistem kullanıcısı mı.
• Hangi olay türlerinin sunucu tarafından desteklendiği ve bunların tarayıcı tarafındaki karşılıklarıyla aynı isimle gönderilmesinin gerekip gerekmediği.
• Kullandığınız e-ticaret altyapısının hazır bir entegrasyonu olup olmadığı ve o entegrasyonun hangi olayları kapsadığı.

Bir ajans veya geliştiriciyle çalışacaksanız bu dört maddeyi teklif almadan önce sorun. "Conversions API kuruyoruz" cümlesi tek başına neyin kapsam içinde olduğunu söylemez.

Kararı üç cümleye indirmek

Pratikte üç durum var. Yeni başlıyorsanız ve harcamanız küçükse, tarayıcı tarafını doğru kurun, açığı ölçün ve şimdilik orada durun. Açığı ölçtünüz, fark anlamlı çıktı ve harcamanız kurulum maliyetini oransal olarak küçültecek düzeydeyse ikisini birden çalıştırmak makul bir yatırımdır. Yalnızca sunucu tarafıyla ilerlemek ise ancak sitede ölçülebilir bir gezinme akışı yoksa, örneğin satış telefonda veya sahada kapanıyorsa tek başına anlamlıdır.

Ölçüm kararı sonunda hedefleme kararına bağlanır. Platformun kitle ve teklif tarafındaki otomatik sistemleri yalnızca kendisine ulaşan olaylara bakabilir; yapay zeka destekli hedefleme tarafında ne kurarsanız kurun, girdi eksikse çıktı da eksik olur. Bu yüzden ölçüm işini kampanya optimizasyonundan önce bitirin.