S2S Postback Nedir? Server to Server Tracking ile Çerezsiz Dönüşüm Takibi

Postback nedir sorusunun kısa cevabı şudur: bir kullanıcı satın alma, üyelik ya da başvuru gibi bir hedefi tamamladığında, reklamverenin sunucusunun bu bilgiyi affiliate ağının sunucusuna doğrudan bildirdiği bir HTTP isteğidir. Bu yönteme S2S postback (server to server, yani sunucudan sunucuya dönüşüm bildirimi) denir.

Çerezlerin her geçen yıl daha kısa ömürlü hâle geldiği, tarayıcıların takip kodlarını sessizce engellediği bir dönemde, server to server tracking artık "ileri seviye" bir seçenek değil, sağlıklı bir affiliate programının asgari şartıdır. Bu rehberde S2S postback'in nasıl çalıştığını, gerçek bir istek örneğini, tekilleştirme ve güvenlik kurallarını ve entegrasyonu nasıl test edeceğinizi adım adım anlatıyoruz.

Rehber hem teknik ekipler hem de entegrasyonu yöneten pazarlama sorumluları için yazıldı. Affiliate marketing'in temellerine yabancıysanız önce Affiliate Marketing Nedir? yazısına göz atmanızı öneririz.

Postback nedir? S2S postback'in tanımı

S2S postback, dönüşüm bilgisinin kullanıcının tarayıcısı yerine reklamverenin sunucusundan affiliate ağının sunucusuna gönderildiği bir dönüşüm takip yöntemidir. Bilginin taşıyıcısı tarayıcı değil, iki sunucu arasındaki doğrudan bir istek olduğu için çerez, JavaScript veya sayfa yüklenmesi gibi kırılgan unsurlara ihtiyaç duymaz.

Klasik takipte zincir şöyledir: kullanıcı tıklar, tarayıcıya bir çerez yazılır, kullanıcı satın aldığında teşekkür sayfasındaki piksel bu çerezi okuyup ağa haber verir. Zincirin her halkası tarayıcıya bağlıdır ve herhangi biri koptuğunda satış "kayıp" olur. Yayıncı komisyonunu alamaz, reklamveren de hangi kanalın gerçekten çalıştığını göremez.

S2S modelinde zincir kısalır. Tıklamada üretilen benzersiz kimlik (click ID) landing sayfasının URL'ine eklenir, reklamveren bu değeri siparişle birlikte veritabanına yazar ve sipariş tamamlandığında kendi sunucusundan ağa bildirir. Tarayıcı sadece ilk adımda, click ID'yi taşımak için kullanılır.

Terimler bazen karıştırılır, kısaca netleştirelim:

• Postback URL: Dönüşüm bildiriminin gönderildiği adres. Reklamveren için bu, ağın takip sunucusudur.
• Click ID: Her tıklamaya özel, ağın ürettiği kimlik. Dönüşümü doğru yayıncıya bağlayan anahtardır.
• Goal (hedef): Bildirilen olayın türü; satış, kayıt, kurulum, ilk yatırım gibi.
• Yayıncı postback'i: Ağın, dönüşümü yayıncının kendi takip sistemine ilettiği ikinci yöndeki bildirim.

Piksel ile S2S postback karşılaştırması

Piksel tarayıcıda çalışır ve çerezlere dayanır; S2S postback sunucuda çalışır ve click ID'ye dayanır. İkisi arasındaki fark, özellikle mobil trafiğin ve gizlilik odaklı tarayıcıların yoğun olduğu kampanyalarda dönüşüm sayısına doğrudan yansır.

Bu tablo pikselin işe yaramaz olduğu anlamına gelmez. Sunucu tarafı geliştirme kaynağı olmayan küçük bir e-ticaret sitesi için piksel hızlı bir başlangıçtır. En sağlam kurulum ise ikisini birlikte çalıştırmaktır: aynı order_id ile hem piksel hem postback gönderildiğinde sistem bunları tekilleştirir ve tek dönüşüm sayar.

Adfacten'de: Pikselden gelen dönüşümler her zaman bekliyor durumunda başlar ve pikselde status parametresi yok sayılır. Onay, red ve iade yalnızca S2S postback, panel veya API ile yapılır. Gizli postback token'ınız piksel koduna asla yazılmaz; piksel yalnızca herkese açık reklamveren kimliğinizi (org_…) kullanır.

Çerezsiz dünyada server to server tracking neden şart?

Server to server tracking şarttır çünkü tarayıcı tabanlı ölçümün dayandığı üç temel, yani üçüncü taraf çerezler, uzun ömürlü birinci taraf çerezler ve engellenmeyen JavaScript, artık güvenilir değildir. Satışın gerçekleştiği anda bu temellerden biri eksikse piksel hiçbir şey bildirmez.

ITP ve tarayıcı kısıtlamaları. Safari'nin Intelligent Tracking Prevention (akıllı takip önleme) özelliği ve benzer mekanizmalar, takip amaçlı görülen çerezlerin ömrünü kısaltır ya da tamamen engeller. Kullanıcı bugün tıklayıp birkaç gün sonra satın aldığında çerez çoktan silinmiş olabilir. Kampanyanızın atıf penceresi 30 gün olsa bile tarayıcı bu süreye uymayabilir.

Reklam engelleyiciler. Popüler engelleyici listeleri, bilinen takip alan adlarına giden istekleri doğrudan keser. Teşekkür sayfasındaki piksel hiç çalışmaz; reklamverenin sisteminde sipariş vardır ama ağın sisteminde yoktur.

Uygulama içi tarayıcılar. Sosyal medya uygulamalarının içinden açılan linkler, ayrı bir tarayıcı ortamında çalışır. Kullanıcı ürünü orada görüp daha sonra asıl tarayıcısından veya uygulamadan satın aldığında çerez taşınmaz.

Gecikmeli ve çevrimdışı dönüşümler. Kredi başvurusunun onaylanması, sigorta poliçesinin kesilmesi veya B2B bir teklifin imzalanması günler sürebilir. Bu anda kullanıcı ortada yoktur; bildirimi yapabilecek tek taraf reklamverenin sunucusudur.

Bu dört durumun ortak sonucu "kayıp satış"tır. Yayıncılar komisyon alamadıkları kampanyalardan çekilir, reklamveren de en verimli kanallarını yanlışlıkla kısar. S2S postback bu sızıntıyı kapatarak programın uzun vadeli sağlığını korur. Yayıncı perspektifinden konuya Affiliate Marketing ile Para Kazanma rehberinde de değiniyoruz.

Click ID akışı adım adım nasıl işler?

Click ID akışı, tıklamada üretilen benzersiz kimliğin landing sayfasına taşınması, siparişle saklanması ve dönüşümde ağa geri gönderilmesinden oluşur. Aşağıdaki adımlar Adfacten'deki gerçek akışı yansıtır.

1. Kullanıcı yayıncının takip linkine tıklar. Ağ tıklamayı kaydeder, kaynak, ülke, cihaz ve yayıncının eklediği sub1–sub10 alt parametreleriyle birlikte imzalı ve süreli bir click ID üretir.
2. Kullanıcı landing sayfasına yönlendirilir. Kampanyanın landing URL'inde {click_id} makrosu varsa bu makro gerçek değerle değiştirilir. Örneğin https://magaza.com/kampanya?cid={click_id} adresi, kullanıcıya ?cid=... ile ulaşır. Makro yoksa click ID, afclk parametresiyle otomatik eklenir.
3. Reklamveren click ID'yi saklar. Landing sayfası cid (veya afclk) değerini okuyup kullanıcının oturumuna yazar. Kullanıcı sipariş verdiğinde bu değer sipariş kaydına taşınır.
4. Dönüşüm gerçekleşir. Ödeme onaylandığında, kayıt tamamlandığında veya hedef olay her neyse gerçekleştiğinde, reklamverenin backend'i postback isteğini hazırlar.
5. Sunucu ağa postback gönderir. İstek; postback token'ı, click ID'yi, goal'ü, tutarı, para birimini ve sipariş numarasını içerir.
6. Ağ isteği doğrular ve kuyruğa alır. Token, click ID imzası, IP ve (açıksa) HMAC imzası kontrol edilir. Yanıt anında döner, dönüşüm arka planda işlenir.
7. Dönüşüm yayıncıya yazılır. Fraud kuralları, tekilleştirme ve fiyatlandırma uygulanır; yayıncının paneline ve varsa yayıncı postback'ine yansır.

Dikkat: En sık yapılan hata 3. adımdır. Click ID yalnızca landing sayfasında bir değişkende tutulur, kullanıcı birkaç sayfa gezdiğinde veya ödemeye geçtiğinde kaybolur. Değeri sunucu tarafı oturuma ya da kalıcı bir çereze yazın ve siparişin kendisine mutlaka kaydedin.

Örnek S2S postback isteği

Bir S2S postback isteği, takip sunucusuna gönderilen, token, click ID ve dönüşüm detaylarını parametre olarak taşıyan basit bir HTTP çağrısıdır. Adfacten'de en sade hâli şöyledir:

GET https://trk.adfacten.com/pb?token=<POSTBACK_TOKEN>&click_id=<CLICK_ID>&goal=sale&amount=250.00&currency=TRY&order_id=ORD-1001

Aynı alanları POST ile form veya JSON gövdesi olarak da gönderebilirsiniz; JSON'da sepet kalemleri için items dizisi desteklenir. Token'ı yol içinde de verebilirsiniz: https://trk.adfacten.com/pb/<POSTBACK_TOKEN>.

Parametrelerin anlamı:

* Click ID yoksa atıf coupon ile yapılabilir.

Başarılı istekte yanıt anında döner:

{"status": "accepted", "event_id": "5b1f…"}

accepted, dönüşümün onaylandığı değil, isteğin kuyruğa alındığı anlamına gelir. Nihai sonucu (dönüşüm oluştu, tekrar olarak işaretlendi veya reddedildi) panelin Son istekler ekranında ve conversion.* webhook'larında görürsünüz. Hatalı isteklerde ise HTTP kodu ve reason alanı sorunun ne olduğunu söyler; bunları aşağıdaki sorun giderme bölümünde ele alıyoruz.

İpucu: event_time alanını özellikle gecikmeli bildirimlerde kullanın. Sipariş dün gece verildiyse ve postback'i bugün toplu bir işle gönderiyorsanız, gerçek zamanı iletmek raporlarınızın doğru güne yazılmasını sağlar.

Tekilleştirme ve idempotency: çift sayımı önlemek

Tekilleştirme, aynı dönüşümün birden fazla kez bildirilmesi durumunda yalnızca bir kez sayılmasını sağlayan kuraldır; idempotency (tekrar güvenliği) ise aynı isteği kaç kez gönderirseniz gönderin sonucun değişmemesidir. İkisi birlikte, sağlam bir postback entegrasyonunun temel taşıdır.

Gerçek hayatta tekrar kaçınılmazdır. Sunucunuz isteği gönderir, ağ yanıtı döner ama araya giren bir zaman aşımı yüzünden siz yanıtı göremezsiniz. Kodunuz isteği yeniden dener. Ya da hem piksel hem postback aynı siparişi bildirir. Tekilleştirme olmasa her senaryoda çift komisyon ödenirdi.

Adfacten'de anahtar (order_id, goal) ikilisidir. Aynı ikili ikinci kez geldiğinde yeni dönüşüm oluşmaz. Bunun pratik sonuçları şunlardır:

• Ağ hatası veya 503 yanıtı aldığınızda isteği tekrar göndermekten çekinmeyin; çift sayım riski yoktur.
• order_id göndermemek tekilleştirmeyi zayıflatır. Bu alan teknik olarak zorunlu değildir ama her entegrasyonda gönderilmelidir.
• Bir siparişte birden çok hedef varsa (ör. registration ve ardından purchase), farklı goal değerleri ayrı dönüşümler olarak sayılır; bu istenen davranıştır.
• Piksel ve postback'i birlikte çalıştırıyorsanız ikisinde de aynı order_id değerini kullanın.

Ayrıca fraud tarafında tekrar dönüşüm engeli devrededir: aynı tıklamadan anormal sayıda dönüşüm gelmesi gibi şüpheli örüntüler ayrıca işaretlenir. Konunun bu boyutunu Affiliate Fraud Önleme rehberinde ayrıntılı ele alıyoruz.

Durum güncelleme: bekliyor, onay, red ve iade

Durum güncelleme, bir dönüşümün yaşam döngüsünü (bekliyor → onaylandı / reddedildi → iade) aynı postback'in status parametresiyle yönetmektir. Ayrı bir entegrasyon kurmanız gerekmez; sipariş sisteminizdeki her durum değişikliğinde aynı isteği farklı bir durumla göndermeniz yeterlidir.

Tipik bir e-ticaret akışı şöyle işler:

1. Sipariş verildiğinde status göndermeden (veya status=pending) postback atılır. Dönüşüm bekliyor olarak düşer.
2. İade süresi dolup sipariş kesinleştiğinde aynı order_id ve goal ile status=approved gönderilir.
3. Sipariş iptal edilirse status=rejected gönderilir; yayıncıya hakediş yazılmaz.
4. Onaylanmış bir sipariş sonradan iade edilirse status=reversed gönderilir; yayıncı hakedişi otomatik geri alınır.

Burada bilinmesi gereken iki ince kural vardır. Birincisi, henüz onaylanmamış (bekleyen) bir dönüşüm için reversed gönderirseniz dönüşüm reddedilir, çünkü ortada geri alınacak bir para hareketi yoktur. İkincisi, yaşam döngüsünde tanımlı olmayan geçişler uygulanmaz; örneğin onaylı bir dönüşüme rejected göndermek Son istekler ekranında invalid_status_transition olarak görünür. Onaydan sonraki geri alma her zaman reversed ile yapılır.

Postback dışında iki yol daha vardır: toplu işlemler için POST /v1/conversions/bulk-status API ucu ve panelden CSV yükleme. Ay sonunda yüzlerce siparişi topluca onaylayan reklamverenler genellikle API'yi tercih eder.

Adfacten'de: Reddederken sebep kodu kullanılır (order_cancelled, order_returned, duplicate, invalid_lead, fraud gibi). Yayıncı neden reddedildiğini görür; bu şeffaflık itirazları ve destek yükünü belirgin biçimde azaltır. Kısmi iadelerde tutarı düzeltmek de mümkündür.

Yayıncı postback'leri ve makrolar

Yayıncı postback'i, affiliate ağının bir dönüşüm oluştuğunda veya durumu değiştiğinde yayıncının kendi takip sistemine gönderdiği bildirimdir. Yani S2S akışın ikinci yönüdür: reklamveren ağa bildirir, ağ da yayıncıya.

Kendi tracker'ını kullanan, birden fazla trafik kaynağını optimize eden veya reklam platformlarına dönüşüm geri besleyen yayıncılar için bu bildirim kritiktir. Adfacten'de yayıncı panelde Postback'ler → Yeni postback adımıyla adres tanımlar. Kapsam tüm kampanyalar ya da tek bir kampanya olabilir; hedef ve durum bazında filtrelenebilir (örneğin yalnızca approved). Yöntem olarak GET (makrolu URL) veya POST (gövde şablonu) seçilebilir.

Yayıncı kendi tıklama kimliğini de taşıyabilir: takip linkine aff_click_id=<kendi ID'niz> eklendiğinde bu değer postback'te {aff_click_id} makrosuyla geri döner. Örnek bir yayıncı postback adresi:

GET https://tracker.sizin.com/postback?clickid={aff_click_id}&payout={payout}&currency={currency}&status={status}&goal={goal}

En çok kullanılan makrolar:

Teslimat güvenilirliği de tasarımın parçasıdır. 2xx dışındaki yanıtlarda istek, üstel geri çekilmeyle 72 saate kadar yeniden denenir; her deneme teslimat günlüğünde istek, yanıt kodu ve süresiyle görünür. Teslimat "en az bir kez" garantisiyle yapıldığından aynı olay için birden çok çağrı gelebilir. Yayıncı tarafında tekilleştirme anahtarı olarak {conversion_id} + {status} ikilisini kullanmak gerekir. Test dönüşümleri (test=1) yayıncı postback'ini tetiklemez.

Mobil uygulamalarda MMP ile postback

Mobil uygulama kampanyalarında postback'i reklamverenin sunucusu yerine MMP (mobile measurement partner, yani mobil ölçüm ortağı) gönderir. Kurulum ve uygulama içi olayları ölçen taraf MMP olduğu için, ağ ile MMP arasında doğrudan bir sunucudan sunucuya bağlantı kurulur.

Akış web'e çok benzer ama click ID'nin taşıyıcısı farklıdır:

1. Yayıncının takip linki tıklanır, ağ click ID üretir.
2. Kullanıcı MMP'nin tracking linkine yönlendirilir; bu linkte MMP'nin "click id" parametresine {click_id} makrosu yerleştirilmiştir.
3. Kullanıcı uygulama mağazasından uygulamayı indirir ve açar. MMP kurulumu bu tıklamaya atfeder.
4. MMP, ağın sağlayıcıya özel postback ucunu çağırır.

Adfacten'de uç formatı şöyledir:

GET https://trk.adfacten.com/mmp/<saglayici>?token=<POSTBACK_TOKEN>&click_id={clickid}&goal={event_name}&amount={revenue}&currency={currency}

<saglayici> yerine appsflyer, adjust, branch, singular veya kochava yazılır ve raporlarda kaynak olarak görünür. Parametreler ve yanıtlar web postback'iyle aynıdır. goal gönderilmezse olay install (kurulum) kabul edilir; bu da CPI kampanyaları için ek ayar gerektirmez.

CPE (cost per engagement, yani uygulama içi etkileşim başına ödeme) kampanyalarında ise kampanyada registration, purchase gibi hedefler tanımlanır ve MMP'deki olay adları bu anahtarlarla eşlenir. Mobil modellerin ekonomisini Performans Pazarlama Modelleri yazısında karşılaştırmalı olarak inceliyoruz.

Tıklamasız atıf: attribution token

Attribution token (atıf token'ı), link tıklaması olmadan gerçekleşen satışları doğru yayıncıya bağlamak için üretilen, click ID ile aynı güvenlikte, imzalı ve süreli bir atıf anahtarıdır. Yapay zekâ asistanlarının önerileri, podcast'ler, sosyal içerikler ve API üzerinden yapılan satışlar bu kapsama girer.

Klasik postback, bir tıklamanın var olduğunu varsayar. Oysa bir kullanıcı bir yapay zekâ asistanından ürün önerisi alıp satın alma akışına doğrudan geçebilir ya da bir podcast'te duyduğu referans kodunu sepette girebilir. Bu kanallarda click ID yoktur; atıf token'ı bu boşluğu doldurur.

Token, API üzerinden üretilir:

POST /v1/attribution-tokens
Authorization: Bearer af_live_…

{ "offer_id": "off_…", "channel": "agent", "sub": { "sub1": "assistant-x" } }

channel değeri api, agent, podcast, social veya offline olabilir ve raporlarda kanal kırılımı olarak görünür. Token kullanıcının satın alma akışına iletilir; örneğin sepetteki referans alanına ya da bir deep link parametresine. Reklamveren dönüşümü bildirirken click_id yerine attribution_token=<token> gönderir; doğrulama, tekilleştirme ve fiyatlandırma aynen uygulanır.

Token'ın süresi kampanyanın atıf penceresi kadardır. Süresi dolmuş, başka reklamverene ait veya değiştirilmiş token'lar reddedilir; ayrıca kampanyada "token ile atıf" kaynağının açık olması gerekir. Yapay zekâ ajanları bu akışı Adfacten'in MCP sunucusu üzerinden de kullanabilir. Konunun geleceğe dönük tarafını Yapay Zekâ Ajanları ve Affiliate Marketing yazısında ve yapay zekâ ajanları sayfamızda bulabilirsiniz.

Postback güvenliği: gizli token, HMAC imzası ve IP kısıtı

Postback güvenliği, ağa yalnızca gerçek reklamverenin gerçek dönüşümleri bildirebilmesini sağlayan katmanlardan oluşur: gizli token, isteğe bağlı HMAC imzası, IP izin listesi ve imzalı click ID. Bu katmanlar olmadan kötü niyetli biri sahte postback'lerle komisyon üretmeye çalışabilir.

Gizli postback token. Her istekte zorunludur ve yalnızca sunucu tarafında tutulmalıdır. Kaynak koda gömülmemeli, ön yüz (frontend) koduna veya piksele asla yazılmamalıdır. Erişimi olan kişi sayısını asgaride tutun.

İmzalı click ID. Click ID'ler ağ tarafından imzalanır ve süreli üretilir. Uydurma veya bozulmuş bir click ID ile gelen istek invalid_click_id ile reddedilir. Başka bir reklamverene ait click ID ise offer_not_owned_by_advertiser hatası verir.

HMAC-SHA256 imzası (önerilir). Token'a ek olarak her isteği panelde gösterilen imza anahtarıyla imzalayabilirsiniz. Yöntem şöyledir:

1. ts parametresine şu anki Unix zamanını (saniye) ekleyin. ±5 dakikadan eski istekler reddedilir; bu, ele geçirilmiş bir isteğin sonradan tekrar oynatılmasını engeller.
2. sig hariç tüm parametreleri, anahtarları küçük harfle, anahtara göre alfabetik sıralayın ve anahtar=değer çiftlerini & ile birleştirin. Değerler URL-çözülmüş (ham) hâliyle kullanılır.
3. sig = hex(HMAC-SHA256(imza_anahtarı, birleştirilmiş_metin)) hesaplayıp isteğe ekleyin.

Komut satırından örnek:

secret='IMZA_ANAHTARI'
ts=$(date +%s)
q="amount=250.00&click_id=$CLICK_ID&currency=TRY&goal=sale&order_id=ORD-1001&token=$TOKEN&ts=$ts"
sig=$(printf '%s' "$q" | openssl dgst -sha256 -hmac "$secret" -hex | sed 's/^.* //')
curl "https://trk.adfacten.com/pb?$q&sig=$sig"

İmzaya geçtikten sonra paneldeki İmza zorunlu seçeneğini açarak imzasız istekleri tamamen reddedebilirsiniz. Böylece token sızsa bile imza anahtarı olmadan geçerli istek üretilemez.

IP izin listesi. Postback'lerin yalnızca kendi sunucularınızdan gelmesini istiyorsanız izinli IP'leri tanımlayabilirsiniz. Listede olmayan bir adresten gelen istek ip_not_allowed ile reddedilir. Sunucu altyapınızı değiştirdiğinizde bu listeyi güncellemeyi unutmayın.

Geliştirici ekibiniz PHP, Node.js ve Python örneklerinin tamamını geliştirici portalında bulabilir.

Postback sorun giderme kontrol listesi

Postback sorunlarının büyük çoğunluğu dört nedenden kaynaklanır: click ID'nin kaybolması, yanlış token, imza hesaplama hataları ve test ile canlı ortamın karıştırılması. Aşağıdaki liste, en olası nedenden en az olasıya doğru sıralanmıştır.

1. Landing URL'inde click ID var mı? Kampanyanın landing adresinde {click_id} makrosunun bulunduğunu veya afclk parametresinin sayfaya ulaştığını tarayıcı adres çubuğundan doğrulayın. Ara yönlendirmeler sorgu parametrelerini silebilir.
2. Click ID siparişe kaydediliyor mu? Test siparişi verip veritabanında ilgili alanın dolu olduğunu kontrol edin. Boşsa sorun oturum yönetimindedir.
3. Postback gerçekten gönderiliyor mu? Sunucu günlüklerinizde giden isteği ve dönen HTTP kodunu arayın. Sipariş durumu tetikleyicisi (ör. "ödeme alındı" olayı) bazen hiç çalışmaz.
4. HTTP kodu ne diyor?
   • 400 missing_click_id / invalid_click_id: click ID boş, kesilmiş veya değiştirilmiş.
   • 401 invalid_token: token yanlış veya eski. bad_signature: imza metni hatalı sıralanmış ya da URL-kodlu değerlerle hesaplanmış. signature_expired: ts 5 dakikadan eski ya da sunucu saatiniz kaymış. signature_required: İmza zorunlu açık ama istek imzasız.
   • 403 ip_not_allowed: sunucu IP'niz izin listesinde değil. offer_not_owned_by_advertiser: click ID başka bir reklamverenin kampanyasına ait. advertiser_inactive: hesap pasif.
   • 503 not_ready: geçici durum; aynı isteği tekrar gönderin.
5. İstek accepted ama panelde dönüşüm yok mu? Son istekler ekranına bakın; dönüşüm tekrar (duplicate) olarak işaretlenmiş, fraud kuralına takılmış veya geçersiz durum geçişi (invalid_status_transition) olabilir.
6. Tutar veya para birimi yanlış mı? Ondalık ayırıcı olarak nokta kullanın (250.00), binlik ayırıcı eklemeyin. currency gönderilmezse kampanyanın para birimi varsayılır.
7. Test dönüşümleri raporda görünmüyor mu? test=1 ile gönderilenler raporlarda ayrı filtrelenir ve bakiyeyi etkilemez. Canlıya geçerken bu parametreyi kaldırmayı unutmayın.
8. Sunucu saatiniz doğru mu? İmzalı isteklerde saat kayması signature_expired hatasının sessiz nedenidir. NTP senkronizasyonunu kontrol edin.

İpucu: Postback'i sipariş oluşturma isteğinin içinde senkron göndermek yerine bir iş kuyruğuna atın. Böylece takip sunucusuna ulaşılamadığında kullanıcının ödeme deneyimi etkilenmez ve başarısız istekler otomatik yeniden denenir.

Adfacten postback test aracıyla uçtan uca doğrulama

Adfacten'in postback test aracı, sahte bir tıklama üreterek size örnek postback URL'ini veren ve gönderdiğiniz isteğin uçtan uca işlendiğini gösteren bir doğrulama ekranıdır. Canlı trafiğe çıkmadan entegrasyonun doğru çalıştığından emin olmanın en hızlı yoludur.

Önerilen test sırası şöyledir:

1. Panelde Test aracı ekranını açın ve test tıklaması üretin. Araç size gerçek formatta bir click ID ve hazır postback URL'i verir.
2. Bu click ID ile landing sayfanızı ziyaret edin ve sitenizde test siparişi tamamlayın. Böylece click ID'nin landing'den siparişe kadar taşındığını da sınamış olursunuz.
3. Sunucunuzun gönderdiği postback'i test=1 ile işaretleyin.
4. Test aracında ve Son istekler ekranında isteğin accepted olduğunu, dönüşümün doğru hedef, tutar ve para birimiyle oluştuğunu kontrol edin.
5. Aynı order_id ile isteği bir kez daha gönderin ve yeni dönüşüm oluşmadığını doğrulayın.
6. status=approved ve ardından status=reversed göndererek durum geçişlerini test edin.
7. İmza kullanıyorsanız bilerek yanlış bir sig gönderip bad_signature hatası aldığınızı görün; ardından İmza zorunlu seçeneğini açın.

Bu yedi adımı geçen bir entegrasyon, canlı trafikte büyük olasılıkla sorunsuz çalışır. Reklamveren tarafında programın geri kalanını kurmak için Affiliate Programı Nasıl Kurulur? rehberine göz atabilirsiniz.

Adfacten ile S2S takibe nasıl başlanır?

Adfacten'de S2S postback'e başlamak için reklamveren hesabı açıp kampanyanızın landing URL'ine {click_id} makrosunu eklemeniz ve Postback & piksel ekranındaki token'la ilk test isteğinizi göndermeniz yeterlidir. 2014'ten beri performans pazarlamada çalışan Adfacten, S2S postback'i öncelikli takip yöntemi olarak sunar; piksel ve MMP entegrasyonları da aynı tekilleştirme ve fraud kurallarından geçer.

Reklamverenseniz reklamveren sayfamızda takip ve fraud koruma özelliklerinin tamamını inceleyebilir, doğrudan reklamveren hesabı oluşturabilirsiniz. Yayıncıysanız kendi tracker'ınızı yayıncı postback'leriyle bağlamak için yayıncılar sayfasına göz atın ya da yayıncı olarak kaydolun. Teknik ekibiniz ise tüm uç noktaları, webhook'ları ve kod örneklerini developers.adfacten.com adresinde bulabilir.