Postback, Pixel ve Image Tag: Sadece Biri Ödemeye Esas Alınabilir

Bir dönüşüm üç şekilde bildirilebilir: image tag, JavaScript pixel ya da sunucudan sunucuya postback. Bunlardan sadece postback komisyon ödemesine esas alınacak kadar sağlam durur, çünkü oyuncunun tarayıcısının işbirliği yapmasına ihtiyacı yoktur. "Takip etmiyor" denen entegrasyonların çoğu aslında bozuk postback değildir; oyuncu kaydında eksik olan tıklama kimlikleridir.

Telefon hep kötü bir saatte gelir. Bir affiliate yöneticisinin trafiği çekmekle tehdit eden bir partneri vardır, operatör entegrasyonun canlı olduğuna yemin eder ve panel sıfır gösterir. Biri, yatırım başarılı sayfasının alt bilgisindeki bir tag'in ekran görüntüsünü gönderip neden çalışmadığını sorar.

Çalışmıyor çünkü bir sayfanın alt bilgisindeki bir tag.

Bir dönüşümü bildirmek, yanlış yapmanın pek çok yolu olan küçük bir problem ve o yollar on yılda pek değişmedi. Değişen şey, üç mekanizmadan ikisinin sessizce güvenilir olmaktan çıkması ve herkesin yine de onları göndermeye devam etmesi. Bu yazı, entegrasyondan sonra değil önce mühendisinize vereceğiniz yazı.

Bir oyuncunun yatırım yaptığını söylemenin üç yolu

Image tag. En eskisi. Sayfanız, kaynağı takip platformuna ait bir URL olan bir piksellik bir görsel içerir. Tarayıcı görseli yüklemeye çalışır, o istek platforma ulaşır ve isteğin kendisi mesajdır. Aslında görsele ihtiyaç yoktur, mesele isteğin atılmasıdır. HTML'den başka hiçbir şey gerektirmez; kimsenin JavaScript'e dokunmak istemediği şablon sistemlerinde bu kadar uzun yaşamasının sebebi de budur.

JavaScript pixel. Aynı fikir, görsel yerine bir betikle. Sayfada bir kod parçası çalışır, biraz bağlam toplar ve çağrıyı gönderir. Daha esnektir: sayfanın bir değişkene koyduğu bir değeri okuyabilir, bir onayın çizilmesini bekleyebilir, ancak çalışma anında bilinen bir yatırım tutarını geçirebilir. Aynı zamanda daha kırılgandır, çünkü betiğin yüklenmesine, değişkenin var olmasına ve sayfanın yukarısında bir hata fırlatılmamış olmasına bağlıdır.

Sunucudan sunucuya postback. Ortada tarayıcı yok. Arka ucunuz önemli olan olayı kaydettiğinde, oyuncu ilk geldiğinde kendisine verilen kimliği taşıyarak bir URL'ye HTTP isteği atar. Ödeme servisiniz bir yatırımı onaylar, sisteminiz işlemi yazar ve aynı yolun bir yerinde bir istek çıkar: bu oyuncu, bu olay, bu tutar, bu para birimi.

Fikrin tamamı bu. Diğer ikisinden daha az zekice geliyor ve sağlam durmasının sebebi tam olarak bu.

Üçünden ikisi neden güvenilir olmaktan çıktı

Tek bir sebep yok. Üst üste yığılmış sebepler var ve her biri tek başına atlatılabilir olurdu.

Safari ve Firefox üçüncü taraf çerezleri varsayılan olarak engelliyor, Firefox ayrıca izleyici listesindeki alan adlarına giden istekleri de engelliyor. Chrome üçüncü taraf çerezlerine hâlâ izin veriyor, yani Chrome'da engelleme tarayıcıdan değil reklam engelleyiciden geliyor. Safari ayrıca betikle yazılan depolamanın ne kadar yaşayacağını sınırlıyor, bazı durumlarda günlere kadar; yani tıklama anında yazılan ve yatırım anında okunan duruma dayanan her şeyin son kullanma tarihi normal bir karar süresinin çok küçük bir parçası oluyor. Bunların hepsinin üstünde reklam engelleyiciler duruyor ve tam da kayıt olmadan önce karşılaştırma içeriği okuyan kitlelerde yaygınlar. Hiçbiri kendini duyurmuyor. Operatörünüz sayfanın düzgün çizildiğini görüyor ve entegrasyonun çalıştığı sonucuna varıyor.

Bir de hiçbir tarayıcı ayarının düzeltemeyeceği kısım var. Oyuncu iş yerinde masaüstünden tıklar, düşünür ve o akşam telefondan yatırım yapar. Ya da web'den kayıt olup yatırımı yerel uygulama içinde yapar; orada tarayıcı yoktur, sayfa yoktur ve tetiklenecek tag yoktur. Özellikle spor bahsinde yatırım tıklamayı değil fikstür listesini takip eder ve onu uygulamanın içine kadar takip eder. Bu iki yolculuğun ne kadar farklı davrandığını görmek isterseniz, casino ve spor bahsi trafiği tam da bu noktada ayrışıyor.

Bir pixel, tarayıcının hiç uğramadığı bir yerden tetiklenemez. Bunun hiçbir yanı daha iyi tag yerleşimiyle düzeltilebilir değil.

Bilinmeye değer arıza biçimleri

Kimse bir entegrasyonu ilginç bir şekilde bozmuyor. Neredeyse hepsini aynı altı hata açıklıyor.

Olay yerine sayfa yüklenmesinde tetiklemek. Tag, yatırım onay sayfasında durur ve o sayfa her açıldığında tetiklenir. Oyuncu sayfayı yeniler, geçmişten geri döner ya da başarısız bir denemeden sonra oraya düşer; her biri raporunuzda bir dönüşümdür. Bu, rakamları iyi görünen yönde şişirir; birinin sorgulamasından önce bu kadar uzun yaşamasının sebebi de budur.

Gerçekten sunucu tarafında mı? Şablon çizen bir arka uç çatısı, yine de tarayıcının çalıştırması gereken bir tag üretiyordur. İstek oyuncunun cihazından çıkıyorsa, hangi dosyada yazılmış olursa olsun tarayıcı tarafıdır. Test bir dakika sürer: kendi tarayıcınızda betikleri engelleyin ve olayın yine de ulaşıp ulaşmadığına bakın.

Sonra oyuncu kaydında eksik olan tıklama kimliği var. Bu, açık ara en yaygın arıza ve aşağıda kendi bölümünü alıyor.

Yatırımın sonuçlanmadan bildirilmesi. Ödeme yetkilendirilir, postback çıkar, ödeme sonra başarısız olur ya da geri alınır. Artık hiç ulaşmamış bir paraya bağlı bir komisyon vardır. Ödeme sayfanızın gösterdiği duruma göre değil, finans ekibinizin tanıyacağı duruma göre tetikleyin.

Idempotency, ya da yokluğu. Ağlar zaman aşımına uğrar. İyi yazılmış bir gönderici yeniden dener, bu doğrudur. Alıcı taraf ikinci denemenin birinciyle aynı olay olduğunu anlayamıyorsa, yeniden deneme ikinci bir dönüşüme dönüşür. Her olayın sizin tarafınızdan gelen sabit ve benzersiz bir referansa ihtiyacı vardır; her yeniden denemede aynı değer, ki kopya iki kez ödenmek yerine tanınıp atılabilsin.

Olaylar ayrıca sırasız gelir. Bir yatırım, ait olduğu kayıttan önce düşer, çünkü iki servis bağımsız tetiklenmiştir ve biri daha hızlıdır. Birbirine bağlı olayları sıraya sokun ya da her birinin tek başına ayakta duracak kadar bağlam taşımasını sağlayın.

Her şeyi belirleyen tek şey

Yukarıdaki her arıza bir öğleden sonrada onarılabilir. Bu onarılamaz.

Bir oyuncu takip linkiyle geldiğinde, o linkteki kimliğin kayıt anında oyuncu kaydına yazılması gerekir. Oturuma değil. Çereze değil. Veritabanınızda o hesabı temsil eden satıra, e-posta adresinin yanına, onu oluşturan aynı işlemin içinde.

Bu olmazsa sonrasındaki hiçbir şey ilişkilendirilemez. Oyuncu üç hafta sonra yatırım yapar, arka ucunuz teknik olarak kusursuz bir postback tetikler ve bu postback hiçbir kimlik taşımaz, çünkü taşınacak bir şey yoktur. Hiçbir postback ince ayarı bunu düzeltmez. Bir raporlama sorununu değil bir kayıt sorununu ayıklıyorsunuz ve çözüm kayıt akışının içinde.

İlgili iki alışkanlık çok tartışma kazandırır. Değer tuhaf görünse bile kimliği saklayın, çünkü bir token'ı doğrulamıyor, saklıyorsunuz. Ve otuz gün için değil hesabın ömrü boyunca saklayın, çünkü geçerli bir yatırım üzerinden ödeyen bir CPA, yatırımın geçerli hâle geldiği anda bağın hâlâ var olmasına ihtiyaç duyar ve bu an tıklamadan aylar sonra olabilir. Geçerli yatırımlar ve ilk yatırımlar etrafındaki sözlük sizin tarafınızda bulanıksa, şemayı yazmadan önce FTD, NGR, CPA, CPL, CPR sözlüğü on dakikaya değer.

Trafik akmadan önce test etmek

Doğru bir entegrasyon testi sıkıcıdır ve yaklaşık bir saat sürer.

1. Gerçek bir takip linkine tıklayın ve normal bir oyuncunun yapacağı gibi kaydı tamamlayın. Sonra kendi veritabanınızdaki oyuncu kaydına bakın ve kimliğin orada olduğunu doğrulayın. Orada değilse durun, çünkü bundan sonrası tiyatrodur.
2. Gerçek para yatırın. Küçük bir tutar yeter, 20 EUR iş görür. Test modundaki ödemeler çoğu zaman olayı tetikleyen tam kod yolunu atlar; entegrasyonların staging'de geçip birinci günde çakmasının sebebi budur.
3. Yatırım olayının bir kez, doğru tutarla ve doğru para birimiyle, ödeme gönderildiğinde değil sonuçlandıktan sonra ulaştığını kontrol edin.
4. Aynı olayı bilerek tekrar gönderin. Kopya olarak tanınmalı ve iki kez sayılmamalı.
5. Tamamını bir telefonda tekrarlayın ve varsa yatırımı tarayıcıda değil uygulamada yaparak bir kez daha.

Bir mühendisin bir saati ve tek bir yatırım; sizin trafiğini kırptığınıza çoktan ikna olmuş bir affiliate ile bir ay sürecek mutabakata karşı. Takip linki QA rehberi aynı testin affiliate tarafını kapsıyor ve iki ucu birlikte çalıştırmak, uyuşmazlığı bir çeyrekte değil bir öğleden sonrada bulmanın yolu.

AFFILIFY bir operatörden ne bekliyor

Entegrasyon referansı affilify.partners/docs adresinde duruyor; uç nokta, parametre adları ve kabul edilen olay tipleriyle birlikte. Bir blog yazısından değil oradan okuyun, çünkü güncel tuttuğumuz sayfa orası.

Biçim küçük. Bir olay adı, tıklama anında size verilen kimlik, bir tutar ve bir para birimi, artı anahtarınız. Kayıt, ilk yatırım, sonraki yatırımlar ve gelir olayları ayrı mesajlardır, çünkü bir anlaşmaya bağlı komisyon modeli bunlardan hangilerinin önemli olduğunu belirler ve bir program hiç almadığı veri üzerinden RevShare ödeyemez. Hâlâ modeller arasında seçim yapıyorsanız, CPA, RevShare ve hibrit her birinin sizden ne istediğini ortaya koyuyor.

Açıkça söylenmeye değer iki şey var. Bizim tarafımızdaki ilişkilendirmenin katmanlı yedekleri var. Onlar sigortadır, plan değil. Kayıt anında saklanan kimlik sizin kontrol ettiğiniz kısımdır, o yüzden gönderin. Ve trafik kalitesi sürekli değerlendirilir, yani bazı dönüşümler geldiği anda alacak yazılmak yerine kontrol edilirken bekletilir. Bu bir ret değildir ve affiliate sessiz bir boşluk değil durumu görür.

Kimliği geri döndüren, sonuçlanmış olayları bir kez bildiren ve bir saat içinde gerçek bir yatırımla test edilebilen bir operatör, gece on birdeki o konuşmayı hiç yaşamaz. Buradaki bütün hedef bu.