Pixel, CAPI ve server-side tracking nedir?

Kısa tanımlar (sonra nasıl çalıştığını ve ne zaman hangisini kullanacağını anlatacağım):

• Pixel (Meta Pixel): Web sitene eklenen bir JavaScript kodu. Ziyaretçinin tarayıcısında çalışır ve sitedeki aksiyonları (PageView, Lead, Purchase vb.) Meta’ya iletir.
  Facebook Geliştiricileri+1
• CAPI (Conversions API): Aynı aksiyonları bu kez tarayıcıdan değil, senin sunucundan / backend’inden Meta’ya gönderen API. Web + app + offline + mesajlaşma gibi farklı kaynaklardan event göndermeyi destekler.
  Facebook Geliştiricileri+1
• Server-side tracking: “Takip verisini tarayıcı yerine sunucu tarafında üretip/aktarma” yaklaşımının genel adı. Meta özelinde bunun en yaygın çıktısı CAPI ile event göndermektir (GTM Server-Side veya CAPI Gateway gibi kurulumlarla).
  Facebook Geliştiricileri+1

Nasıl çalışır? (Pixel vs CAPI veri akışı)

Pixel (browser-side)

1. Kullanıcı siteye girer
2. Tarayıcı Pixel’i çalıştırır
3. Event Meta’ya gider (tarayıcı kısıtlarına/adblock’a takılabilir)

CAPI (server-side)

1. Kullanıcı bir aksiyon yapar (form gönderdi, ödeme aldı, randevu onaylandı)
2. Bu bilgi senin sunucunda oluşur (CRM/rezervasyon/checkout backend)
3. Sunucu Meta’ya event’i gönderir (tarayıcı bağımlılığı daha az)

Meta’nın tanımıyla Pixel “webde kullanıcı aktivitesini izleyen kod”, CAPI ise “reklamverenin pazarlama verisi ile Meta sistemleri arasında doğrudan bağlantı” kurar.
Facebook Geliştiricileri+1

“İkisini birden” kullanınca çifte sayım olur mu?

Olabilir—deduplikasyon doğru yapılmazsa.

Meta, Pixel ve CAPI ile aynı olayı iki kanaldan gönderdiğinde, bunları tek saymak için event_id / eventID eşleştirmesi ister. Pixel tarafındaki eventID, sunucu tarafındaki event_id ile aynı olursa Meta event’i “tek” kabul eder.
Facebook Geliştiricileri+1
Best practice olarak event_name aynı olmalı ve dedup için event_id (veya bazı durumlarda fbp/fbc gibi anahtarlar) kullanılmalı.
Facebook Geliştiricileri+1

Pratik öneri: Hybrid kur (Pixel + CAPI) + event_id ile deduplicate et. Bu, hem ölçümü güçlendirir hem de optimizasyon sinyalini artırır.

Server-side tracking neden önemli?

Çünkü tarayıcı tarafı ölçüm, şu sebeplerle sık sık “eksik” kalır:

• Çerez kısıtları / tarayıcı politikaları
• Adblock’lar
• Kullanıcının tarayıcıdan çıkması, sayfa yüklenmeden aksiyon tamamlaması
• “Gerçek dönüşüm”ün (örn. kapora geldi, randevu onaylandı) CRM’de oluşması

Server-side tracking ile:

• Daha tutarlı event yakalama
• CRM’den “kaliteli lead / onaylı randevu” gibi daha alt-funnel sinyaller gönderme
• Offline/çağrı merkezi kapanışlarını reklama bağlama mümkün olur (CAPI offline da destekler).
  Facebook Geliştiricileri+1

Pixel, CAPI, server-side: Hangisi ne zaman?

Sadece Pixel yeterli olabilir (başlangıç):

• Küçük bütçe, basit funnel (landing → form)
• “Ölçüm mü var mı yok mu?” seviyesinde

CAPI şart olur:

• Bütçe büyüyorsa ve ölçüm kaybı hissediyorsan
• Dönüşüm “backend”de netleşiyorsa (rezervasyon onayı, kapora, CRM’de qualified lead)
• Sağlık turizmi/klinik gibi süreçli satışlarda “kaliteli lead” sinyali göndermek istiyorsan

Server-side tracking (GTM SS / CAPI Gateway) tercih edilir:

• Geliştirici yükünü azaltmak istiyorsan
• Standart bir altyapıyla (gateway) daha hızlı/sağlam kurulum hedefliyorsan
   CAPI Gateway, deduplikasyon anahtarının otomatik üretilip taşınması gibi kolaylıklar sunar.
  Facebook Geliştiricileri

Klinik/otel gibi işletmelerde “doğru event” örnekleri

• ViewContent: hizmet/oda sayfası görüntüleme
• Lead: form/WhatsApp tık (kalitesine dikkat)
• Schedule / CompleteRegistration benzeri: randevu talebi
• Purchase veya özel event: kapora/rezervasyon onayı (en değerli sinyal)

Pixel’in standart event mantığı ve “track” yapısı Meta dokümantasyonunda listelenir.
Facebook Geliştiricileri+1

En sık yapılan 5 hata

1. Deduplikasyon yok → çift sayım
   Facebook Geliştiricileri+1
2. Pixel ve CAPI’de event_name farklı → optimizasyon dağılır
   Facebook Geliştiricileri
3. “Lead” her şeye basılır → kalite sinyali bozulur
4. Sunucudan yanlış zamanda event gönderilir (örn. “randevu istendi” yerine “randevu onaylandı” hedeflenmeli)
5. KVKK/izin akışı düşünülmeden “her veriyi gönderme” yaklaşımı (server-side izin bypass değildir)