Sunucu Taraflı Takip (Server-Side Tracking): Neyi Kurtarır, Neye Mal Olur?

Meta (Facebook) reklam hesabınız mağazanızdaki gerçek sipariş sayısından daha az dönüşüm raporluyorsa yanılmıyorsunuz. Safari ITP, reklam engelleyiciler (AdBlock), üçüncü taraf çerezlerin kısıtlanması ve Apple iOS App Tracking Transparency (ATT) derken dönüşümlerin önemli bir kısmı reklam platformuna hiç ulaşmıyor.

Bunun sonucu sadece eksik raporlama değildir. Reklam platformunun yapay zekası yalnızca görebildiği dönüşümlere göre optimizasyon yapar. Satışların sadece %60'ını görüyorsa eksik ve taraflı bir kitleye göre reklam yayınlar — ve takip engeli koyan kitleyi (ki birçok pazarda bu kitle en yüksek alım gücüne sahip kitledir) sistematik olarak görmezden gelir.

Sunucu taraflı dönüşüm takibi (Server-Side Tracking / CAPI) bu sorunun büyük kısmını çözer. Ancak ajansların söylediğinden daha fazla teknik emek gerektirir. İşte meselenin dürüst ve net hali:

Neden tarayıcı takibi bozuluyor?

Üçüncü taraf çerezler. Safari ve Firefox bunları tamamen engelliyor. Chrome kısıtlamaları artırıyor. Geleceği çerezlere bağlamak artık akılcı değildir.

Safari ITP (Intelligent Tracking Prevention). Safari, JavaScript ile oluşturulan birinci taraf çerezleri 7 günle, takip parametresiyle gelenleri ise 24 saatle sınırlandırıyor. Reklamı görüp 9. günde satın alan bir kullanıcı tamamen takip edilemez hale geliyor.

Reklam Engelleyiciler (AdBlockers). Kullanıcıların %25 ila %40'ı reklam engelleyici kullanıyor. Teknik ve genç kitlelerde bu oran daha da yüksektir. Engellenen bir piksel kodu hiç tetiklenmez.

iOS ATT. Çoğu iPhone kullanıcısı uygulama takibini reddediyor. Özellikle Meta için bu durum mobil uygulamadan web sitesine giden dönüşüm takibini büyük ölçüde kesti.

Bunları üst üste koyduğunuzda tarayıcı taraflı takip standart olarak dönüşümlerin %20 ila %40'ını kaçırır.

Sunucu taraflı takip nasıl çalışır?

Dönüşüm olayını reklam platformuna tarayıcıdaki bir JavaScript kodunun göndermesi yerine, doğrudan kendi sunucunuz gönderir:

Tarayıcı  →  Kendi Sunucunuz  →  Reklam Platformu API'si

İstek, tarayıcının engelleyebileceği bir script'ten değil, kendi altyapınızdan çıkar. Çerezde saklanan tahminler yerine sunucunuzun zaten elinde olan kesin verileri taşır: sipariş tutarı, para birimi ve yeni satın alan müşterinin güvenli şekilde hash'lenmiş (şifrelenmiş) e-posta adresi.

Meta buna Conversions API (CAPI), Google Gelişmiş Dönüşümler (Enhanced Conversions), TikTok ise Events API adını verir. Temel mantık hepsinde aynıdır.

İnsanların en çok hata yaptığı yer: Tekilleştirme (Deduplication)

Neredeyse her zaman hem tarayıcı hem de sunucu takibini birlikte çalıştırırsınız. Tarayıcı zengin oturum verisi toplar; sunucu ise kesin ve güvenilirdir. İkisini birden gönderdiğinizde tarayıcıda başarılı olan her satışı iki kez saymış olursunuz.

Çözüm, her iki tarafın da paylaştığı benzersiz bir event_id (olay kimliği) kullanmaktır:

// tarayıcı
const eventId = crypto.randomUUID();
fbq('track', 'Purchase', { value: 129.90, currency: 'EUR' }, { eventID: eventId });

// sunucu, aynı eventId ile
{ "event_name": "Purchase", "event_id": eventId, "user_data": { ... } }

Platform her iki isteği de görür, olay kimliğini eşleştirir ve tek bir dönüşüm olarak sayar. Burada hata yaparsanız raporlanan ROAS'ınız kağıt üzerinde iki katına çıkar, gerçek olmayan bir sayıya bakarak bütçe büyütürsünüz ve gerçeği bir ay sonra banka hesabınızda görürsünüz.

Platformun Olay Yöneticisi'nde (Events Manager) tekilleştirme oranını mutlaka denetleyin. %90'ın altındaki eşleşmeler ID'lerin doğru aktarılmadığını gösterir.

Kullanıcı rızası (KVKK / GDPR) isteğe bağlı değildir

Sunucu taraflı takip yapmak sizi yasal kullanıcı rızası alma zorunluluğundan muaf tutmaz. Hatta sorumluluğu artırır: Artık kişisel verileri kendi sunucunuzda işleyip üçüncü bir tarafa iletiyorsunuzdur.

Pratikte:

• Çerezi reddeden kullanıcı için sunucudan da veri göndermeyin. Kullanıcının onay durumu sunucuya olayla birlikte iletilmelidir. Tarayıcıda reddedildi diye arkadan sunucuyla göndermek açık bir mevzuat ihlalidir.
• Kişisel verileri hash'leyin. E-posta adreslerini sunucudan çıkarmadan önce mutlaka SHA-256 ile şifreleyin.
• Gizlilik politikanızda açıkça belirtin. "Çerez kullanıyoruz" ifadesi sunucudan sunucuya müşteri verisi aktarımını kapsamaz.

Gerçekçi olarak neleri geri kazandırır?

Piyasadaki bazı vaka analizleri %100'e varan artışlar iddia eder. Bu abartılı sayılara şüpheyle yaklaşın.

Bizim pratikte gördüğümüz:

• Düzgün tekilleştirilmiş bir kurulumda platformda %10–30 daha fazla eşleşen dönüşüm
• Daha yüksek Olay Eşleşme Kalitesi (Event Match Quality) — bu en büyük gizli avantajdır: Daha iyi veri yapay zekanın daha doğru kitle hedeflemesini sağlar
• Özellikle iOS cihazlarda çok daha stabil dönüşüm takibi

Kurulumu yaptıktan sonraki ilk iki ay raporlarınızda sanki ciro patlaması olmuş gibi görünecektir. Bu yeni bir ciro değildir. Zaten gerçekleşen ama daha önce göremediğiniz satışların artık görünür olmasıdır.

Neleri ÇÖZMEZ?

Tek bir mutlak gerçeklik yaratmaz. Reklam platformları hala aynı satışı sahiplenmeye devam eder. Hem Meta hem Google aynı satışı kendi hanesine yazabilir. Sunucu takibi bu iddiaları daha eksiksiz yapar; aralarındaki çakışmayı uzlaştırmaz.

Kendi veritabanınızın yerini tutmaz. Asıl gerçeklik kaynağınız kendi e-ticaret altyapınız ve muhasebenizdir. Meta 340 satış iddia ediyor ama mağazanızda toplam 210 sipariş varsa, sorun takip kapsamı değildir.

Kötü bir ürünü veya teklifi düzeltmez. Çalışmayan bir kampanyayı daha hassas ölçmek, sadece onun çalışmadığını daha net görmenizi sağlar.

Uygulama yöntemleri

Platform Sunuculu (CAPI Gateway). En hızlısı ama en az kontrole sahip olanı. Veri akışınızı üçüncü bir aracıya emanet edersiniz.

Sunucu Taraflı Google Tag Manager (sGTM). Kendi bulut sunucunuzda (Cloud Run, AWS vb.) çalışan bir GTM kapsayıcısı. Veriyi alır ve tüm platformlara dağıtır. En yaygın profesyonel çözümdür; aylık 50–150$ arası bir sunucu maliyeti olur.

Doğrudan API Entegrasyonu. Sipariş tamamlandığında backend yazılımınızın doğrudan reklam platformu API'sini çağırmasıdır. En güvenilir yöntemdir; çünkü teşekkür sayfasının yüklenmesine değil, siparişin veritabanında gerçekten oluşmasına bağlıdır.

Uygulama sırası

1. Önce platform verileri ile gerçek siparişleriniz arasındaki farkı ölçün.
2. En çok reklam harcaması yaptığınız tek bir platformla başlayın.
3. Olay kimliği (deduplication) ile birlikte sunucu takibini kurun ve eşleşme oranını doğrulayın.
4. İki hafta test edin ve verileri karşılaştırın.
5. Ancak bundan sonra diğer platformlara yayın.

Aylık reklam harcamanız 2.000–3.000 doların altındaysa bu teknik kurulum maliyetini çıkarmak zordur. Ancak aylık 10.000 doların üzerinde reklam harcıyorsanız, sunucu takibine sahip olmamak kendi verinizin eksik bir parçasına bakarak bütçe yönetmek demektir.