Çerez Tabanlı mı, Sunucu Tabanlı mı? Affiliate Takibinde Doğru Yöntemi Seçmek

Affiliate programı kuran bir reklamverenin ilk teknik kararı, satışların ağa nasıl bildirileceğidir. Bu kararın iki ana seçeneği vardır ve aradaki çerez tabanlı sunucu tabanlı takip farkı, aylar sonra raporlarınızın ne kadar güvenilir olacağını, yayıncılarınızın size ne kadar güveneceğini ve ekibinizin her ay ne kadar vakit harcayacağını belirler.

Bu yazı, S2S postback'in ne olduğunu sıfırdan anlatmıyor; o konu için S2S postback rehberimize bakabilirsiniz. Burada iki yöntemi aynı masaya koyuyoruz: veri nasıl akıyor, nerede kayboluyor, kurmak ne kadar emek istiyor, bakımı nasıl bir yük getiriyor. Sonunda da sitenizin durumuna göre hangisini seçeceğinizi gösteren bir karar tablosu ve geçiş planı bulacaksınız.

Çerez tabanlı ve sunucu tabanlı takip farkı tek cümlede nedir?

Çerez tabanlı takip, dönüşümü kullanıcının tarayıcısından bildiren; sunucu tabanlı takip ise dönüşümü mağazanın kendi sunucusundan ağın sunucusuna bildiren bir yöntemdir. Geri kalan her fark bu tek ayrımdan doğar.

Çerez tabanlı modelde iş zinciri tarayıcıda tamamlanır. Kullanıcı yayıncının linkine tıklar, ağın takip alan adı tarayıcıya bir çerez yazar, kullanıcı satın alır ve teşekkür sayfasındaki piksel tarayıcıdan ağa "bu tarayıcı satın aldı" der. Ağ, gelen istekteki çerezi okuyarak tıklamayı bulur.

Sunucu tabanlı modelde tarayıcı yalnızca bir taşıyıcıdır. Tıklama sırasında ağ, mağazanın açılış sayfasına URL içinde benzersiz bir click ID (tıklama kimliği) ekler. Mağaza bu kimliği yakalar, oturumda tutar ve sipariş oluştuğunda sipariş kaydına yazar. Sipariş kesinleşince mağazanın arka uç sistemi, kimliği ve sipariş bilgilerini içeren bir HTTP isteğini doğrudan ağa gönderir.

Veri akışı yan yana: bir siparişin iki ayrı yolculuğu

İki yöntemin veri akışı, aynı sipariş üzerinden izlendiğinde farkı en net biçimde gösterir. Varsayımsal bir örnek alalım: bir kullanıcı salı akşamı bir yemek blogundaki linke tıklıyor ve perşembe öğlen bir mutfak gereçleri sitesinden 1.250 TL'lik sipariş veriyor.

Çerez tabanlı yolculuk:

1. Tıklama ağın takip alan adına gider; ağ tarayıcıya tıklama bilgisini taşıyan bir çerez yazar ve kullanıcıyı mağazaya yönlendirir.
2. Kullanıcı iki gün boyunca siteyi kapatıp açar, belki farklı bir sekmeden döner.
3. Perşembe günü ödeme tamamlanır ve teşekkür sayfası yüklenir.
4. Sayfadaki piksel, tarayıcıdan ağa sipariş tutarı ve numarasıyla istek gönderir; istek, salı günü yazılan çerezi de taşır.
5. Ağ çerezi okur, tıklamayı bulur, dönüşümü yayıncıya yazar.

Sunucu tabanlı yolculuk:

1. Tıklama ağdan geçer; kullanıcı ?click_id=... parametresiyle mağazaya gelir.
2. Mağaza, kimliği kendi alan adındaki bir çereze veya kullanıcı hesabına kaydeder.
3. Perşembe günü sipariş veritabanına yazılırken click ID de siparişin bir alanı olarak saklanır.
4. Ödeme onaylanınca mağazanın sunucusu ağa postback gönderir.
5. Kargo sonrası iade gelirse aynı sunucu ikinci bir bildirimle durumu günceller.

Dikkat ederseniz çerez tabanlı akışta beş adımın üçü kullanıcının tarayıcısına bağlıdır. Sunucu tabanlı akışta tarayıcıya bağımlı tek kritik nokta, ilk gelişte kimliğin yakalanmasıdır; sonrası tamamen sizin kontrolünüzdeki sistemlerde gerçekleşir.

Kayıp noktaları: dönüşüm nerede kayboluyor?

Çerez tabanlı takipte kayıp noktaları tarayıcının içindedir ve sizin müdahale alanınız dışındadır; sunucu tabanlı takipte ise kayıp noktaları çoğunlukla sizin kodunuzdadır ve düzeltilebilir. Bu ayrım, hangi yöntemin "daha doğru" olduğundan çok, hatayı kimin düzeltebileceğini belirler.

Tablonun son satırı çoğu zaman gözden kaçar. Çerez tabanlı takip yalnızca "satış oldu" diyebilir. Siparişin iptal edildiğini, kısmen iade edildiğini veya tutarın değiştiğini söyleyemez; bunları panelden elle düzeltmeniz gerekir. Bu konudaki ayrıntılar için ödeme yönlendirmelerinde dönüşüm kaybı ve Safari'nin takip önleme mekanizması yazılarımıza göz atabilirsiniz.

Dikkat: Ağ raporunuz ile kendi sipariş sisteminiz arasında sürekli bir açık varsa ve bu açık Safari ile uygulama içi tarayıcılardan gelen trafikte yoğunlaşıyorsa, sorun büyük olasılıkla çerez tabanlı takibin yapısal sınırıdır, kodunuzdaki bir hata değil.

Kurulum eforu: kim, ne kadar sürede, neye dokunuyor?

Çerez tabanlı takip genellikle bir pazarlama uzmanının bir saat içinde kurabileceği bir iştir; sunucu tabanlı takip ise geliştirici katılımı ve birkaç günlük test gerektirir. Ancak bu farkı yalnızca süreyle ölçmek yanıltıcıdır, çünkü dokunulan sistemler de farklıdır.

Çerez tabanlı kurulumda yapılanlar:

• Ağın verdiği piksel kodu teşekkür sayfasına veya bir etiket yöneticisine eklenir.
• Sipariş tutarı ve numarası sayfadaki değişkenlerden piksele aktarılır.
• Bir test siparişiyle pikselin tetiklendiği kontrol edilir.

Bu kurulum için etiket yöneticisiyle piksel kurulumu yazımız adım adım rehber sunar.

Sunucu tabanlı kurulumda yapılanlar:

• Açılış sayfalarının tamamında click ID parametresini yakalayan bir ara katman yazılır.
• Kimlik, mağazanın kendi alan adına uzun ömürlü bir çerezde veya oturumda saklanır.
• Sipariş tablosuna click ID için bir alan eklenir ve sipariş oluşurken doldurulur.
• Sipariş durumu "ödendi" olduğunda tetiklenen bir iş, ağın postback adresine istek gönderir.
• İptal ve iade durumları için ikinci bir bildirim akışı tanımlanır.
• Başarısız istekler için tekrar deneme ve loglama eklenir.

Özel yazılımlı bir sitede bu adımları uygulamak için sunucu tarafı postback kurulum rehberimizi kullanabilirsiniz. Hazır bir altyapı kullanıyorsanız işin büyük kısmı bir eklenti veya webhook ayarına iner.

Adfacten'de: Postback ucu tektir ve token ile korunur: https://trk.adfacten.com/pb?token=…&click_id=…&goal=…&amount=…&currency=…&order_id=…. Click ID'ler imzalı ve sürelidir; yani sahte veya süresi geçmiş bir kimlikle gelen istek dönüşüm olarak kabul edilmez. Teknik belgelere developers.adfacten.com adresinden ulaşabilirsiniz.

Bakım yükü: kurulumdan sonraki aylar

Çerez tabanlı takibin bakımı görünürde hafif ama sessizce bozulmaya açıktır; sunucu tabanlı takibin bakımı ise kurulumda ağır, sonrasında kararlıdır. Reklamverenlerin çoğu bu farkı ilk tema güncellemesinde öğrenir.

Piksel, sayfa şablonunun bir parçasıdır. Tasarım ekibi teşekkür sayfasını yenilediğinde, ödeme akışı tek sayfalık bir yapıya geçtiğinde veya çerez onay bannerı değiştiğinde piksel tetiklenmeyi bırakabilir ve bunu kimse fark etmez. Fark edildiğinde de genellikle bir yayıncının "satışlarım düştü" mesajıyla olur; arada geçen günlerin dönüşümleri ise çoğunlukla geri getirilemez.

Postback ise sipariş yaşam döngüsüne bağlıdır. Ön yüz tamamen değişse bile sipariş tablosu ve durum geçişleri aynı kaldığı sürece bildirim çalışmaya devam eder. Bakım gerektiren an, sipariş sistemini veya ödeme altyapısını değiştirdiğiniz andır. Böyle bir değişiklik zaten planlı bir proje olduğundan, takibin de test listesine girmesi kolaydır.

Bakım açısından yapmanız gereken üç rutin şunlardır:

• Haftalık mutabakat: Ağdaki dönüşüm sayısı ile kendi sisteminizdeki affiliate kaynaklı sipariş sayısını karşılaştırın.
• Log incelemesi: Postback isteklerinden hata kodu dönenleri listeleyin; tekrar denenip denenmediğini kontrol edin.
• Sürüm sonrası test: Her ödeme veya tema güncellemesinden sonra bir test siparişi geçirin.

Uyuşmazlık analizinin nasıl yapılacağını ağ raporu ile analitik arasındaki farkları anlattığımız yazıda bulabilirsiniz.

Karar tablosu: hangi durumda hangisini seçmeli?

Doğru takip yöntemi; geliştirici kaynağınız, ödeme akışınız, trafiğinizin tarayıcı dağılımı ve iptal-iade oranınız birlikte değerlendirilerek seçilir. Aşağıdaki tablo bu dört değişkeni somut durumlara çevirir.

Tablodaki satırların çoğunun sunucu tabanlı yönteme çıkması tesadüf değil. Piksel, kurulumu kolay olduğu için hâlâ yaygın; ancak bugünkü tarayıcı ortamında tek başına asıl kaynak olarak tutulması, programın büyüdükçe daha çok dönüşüm kaybetmesi anlamına gelir.

Hibrit kurulum: ikisini birlikte çalıştırmanın doğru yolu

Hibrit kurulum, postback'i asıl dönüşüm kaynağı yapıp pikseli yedek veya karşılaştırma aracı olarak çalıştırmaktır. Geçiş döneminde ve özellikle ilk aylarda en güvenli yaklaşım budur.

Hibrit kurulumun çalışması için tek bir şart vardır: iki kanal da aynı siparişi aynı kimlikle bildirmelidir. Piksel ve postback aynı order_id ve aynı goal değerini gönderirse ağ ikinci bildirimi mükerrer olarak işaretler ve satış bir kez sayılır. Sipariş numarası bir kanalda "10045", diğerinde "#10045" olarak giderse iki ayrı satış oluşur. Bu konuyu dönüşüm tekilleştirme yazımızda ayrıntılı ele aldık.

Hibrit dönemin size kazandırdığı en değerli şey ölçümdür. Belirli bir süre boyunca hangi siparişlerin yalnızca postback ile, hangilerinin yalnızca piksel ile geldiğini karşılaştırırsanız, çerez tabanlı takipte ne kadar kayıp yaşadığınızı kendi verinizle görürsünüz. "Yalnızca piksel ile gelen" sipariş varsa bu, postback akışınızda bir kaçak olduğunu gösterir; örneğin click ID'nin bazı açılış sayfalarında yakalanmadığını.

İpucu: Hibrit dönemi sonsuza kadar sürdürmeyin. Postback'in sipariş sisteminizdeki affiliate kaynaklı siparişlerin tamamını yakaladığından emin olduğunuzda pikseli kaldırın veya yalnızca izleme amaçlı tutun. İki kanalın uzun süre birlikte çalışması, ileride yapılacak her değişikliği iki kez test etmeniz anlamına gelir.

Pikselden sunucu tabanlı takibe geçiş planı

Geçiş, pikseli kapatmadan postback'i devreye alıp iki kanalı karşılaştırarak yapılır; piksel ancak postback kendini kanıtladıktan sonra kaldırılır. Aşağıdaki sıra, veri kaybı yaşamadan geçmenin pratik yoludur.

1. Envanter çıkarın: Hangi açılış sayfalarına affiliate trafiği geldiğini, ödeme akışında kaç yönlendirme olduğunu ve sipariş durumlarınızın neler olduğunu listeleyin.
2. Click ID yakalamayı kurun: Tüm giriş sayfalarında parametreyi okuyup birinci taraf çereze ve oturuma yazan kodu yayına alın.
3. Sipariş kaydına alan ekleyin: Click ID'yi siparişle birlikte saklayın; boş gelen affiliate siparişlerini loglayın.
4. Postback'i test ortamında deneyin: Ağın test aracıyla birkaç sahte siparişin doğru tutar, para birimi ve sipariş numarasıyla geldiğini doğrulayın.
5. Canlıda hibrit çalıştırın: Piksel açık kalsın; postback de aynı sipariş numarasıyla göndersin.
6. Karşılaştırın: En az bir iki haftalık veride, iki kanalın yakaladığı siparişleri sipariş numarası üzerinden eşleştirin.
7. İptal ve iade akışını ekleyin: Durum değişikliklerinin ağa iletildiğini bir test iadesiyle kontrol edin.
8. Pikseli emekliye ayırın: Kayıp kalmadığında pikseli kaldırın ve yayıncılarınıza takip yöntemini güncellediğinizi duyurun.

Bu sürecin her adımı için test siparişiyle uçtan uca doğrulama yazımızdaki kontrol listesini kullanabilirsiniz. Daha geniş bir altyapı değişikliği planlıyorsanız takip altyapısı geçişinde veri kaybını önleme rehberi de faydalı olur.

Programınızı hangi yöntemle kuracağınıza karar vermeden önce platformun neler sunduğunu görmek isterseniz reklamveren sayfamızı inceleyebilir veya doğrudan ücretsiz reklamveren hesabı açabilirsiniz.

Yayıncı güveni açısından takip yöntemi neden önemli?

Takip yöntemi, yayıncıların programınıza ne kadar trafik ayıracağını doğrudan etkiler; çünkü deneyimli yayıncılar kayıp riskini kazanç hesabına katar. Aynı komisyonu veren iki programdan sunucu tabanlı takip yapanı, tıklama başına kazancı daha öngörülebilir olduğu için tercih edilir.

Bunun pratik bir sonucu vardır. Çerez tabanlı takipte kaybolan her satış, yayıncının gözünde "bu reklamveren satışımı yemiyor mu?" sorusunu doğurur. Kayıp satış bildirimleri artar, destek ekibiniz bunları tek tek incelemek zorunda kalır. Sunucu tabanlı takipte ise kayıp azaldığı gibi, red kararları da gerekçeli olur: iptal edilen sipariş "order_cancelled", iade edilen sipariş "order_returned" sebebiyle düşer ve yayıncı nedenini görür.

Adfacten'de: Kampanya sayfalarında son 30 günün ağ geneli EPC, dönüşüm oranı ve onay oranı gösterilir. Takip yöntemi sağlam bir program, bu metriklerde daha istikrarlı görünür ve yayıncı dizininde daha fazla erişim talebi alır.

Adfacten ile başlayın

Çerez tabanlı ve sunucu tabanlı takip arasındaki seçim aslında bir zaman meselesidir: piksel bugün başlamanızı, postback ise yarın da doğru ölçmenizi sağlar. Önerimiz açık: programı hızla test etmeniz gerekiyorsa pikselle başlayın, ama ilk günden sunucu tabanlı geçişi takvime koyun ve hibrit bir dönemle doğrulayın.

Adfacten, 2014'ten beri faaliyet gösteren, Türkiye merkezli ve dünya geneline hizmet veren bir performans pazarlama ağıdır. S2S postback öncelikli takip, imzalı click ID, sipariş numarası ve hedef bazlı tekilleştirme, kampanya bazında atıf penceresi ve iptal-iade senkronizasyonu tek panelde sunulur. Teknik ayrıntılar için teknoloji sayfamıza göz atabilirsiniz.

Programınızı kurmaya hazırsanız reklamveren olarak kaydolun; entegrasyon sürecinde takip yöntemini sitenizin yapısına göre birlikte belirleyelim.