Postbacki, piksele i tagi obrazkowe: tylko za jedno da się zapłacić

Konwersję można zgłosić na trzy sposoby: tagiem obrazkowym, pikselem JavaScript albo postbackiem server-to-server. Tylko postback trzyma się na tyle dobrze, żeby płacić za niego prowizję, bo nie potrzebuje współpracy przeglądarki gracza. Większość integracji, które „nie trackują”, to wcale nie zepsute postbacki, tylko brakujące identyfikatory kliknięcia na rekordzie gracza.

Telefon zawsze dzwoni o złej porze. Affiliate manager ma partnera, który grozi odcięciem ruchu, operator przysięga, że integracja działa, a dashboard pokazuje zero. Ktoś wysyła zrzut ekranu z tagiem w stopce strony potwierdzenia depozytu i pyta, dlaczego to nie działa.

Nie działa, bo to tag w stopce strony.

Zgłoszenie konwersji to mały problem z dużą liczbą sposobów na jego zepsucie, a te sposoby nie zmieniły się przez dziesięć lat. Zmieniło się to, że dwa z trzech mechanizmów po cichu przestały być pewne, a wszyscy dalej je wdrażali. Ten tekst wręcza się swojemu programiście przed integracją, a nie po niej.

Trzy sposoby powiedzenia, że gracz wpłacił

Tag obrazkowy. Najstarszy. Twoja strona zawiera jednopikselowy obrazek, którego źródłem jest adres należący do platformy trackingowej. Przeglądarka próbuje wczytać obrazek, to żądanie trafia do platformy, a samo żądanie jest wiadomością. Żaden obrazek nie jest naprawdę potrzebny, chodzi o pobranie. Wymaga wyłącznie HTML, dlatego przetrwał tak długo w systemach szablonowych, w których nikt nie chciał dotykać JavaScriptu.

Piksel JavaScript. Ten sam pomysł, tylko ze skryptem zamiast obrazka. Snippet działa na stronie, zbiera trochę kontekstu i wysyła wywołanie. Jest bardziej elastyczny: potrafi odczytać wartość, którą strona zapisała w zmiennej, potrafi poczekać na wyrenderowanie potwierdzenia, potrafi przekazać kwotę depozytu znaną dopiero w czasie działania. Jest też bardziej kruchy, bo zależy od wczytania skryptu, istnienia zmiennej i tego, czy strona nie rzuciła wyjątku wyżej.

Postback server-to-server. Żadnej przeglądarki. Kiedy Twój backend zapisuje zdarzenie, które ma znaczenie, wysyła żądanie HTTP pod pewien adres, niosąc identyfikator, który dostał w momencie pierwszego wejścia gracza. Twoja usługa płatnicza potwierdza depozyt, Twój system zapisuje transakcję, a gdzieś na tej samej ścieżce wychodzi żądanie mówiące: ten gracz, to zdarzenie, ta kwota, ta waluta.

To cała idea. Brzmi mniej sprytnie niż dwie poprzednie i właśnie dlatego się trzyma.

Dlaczego dwa z trzech przestały być pewne

Nie ma jednej przyczyny. Jest ich stos, a każda z osobna byłaby do przeżycia.

Safari i Firefox domyślnie blokują ciasteczka firm trzecich, a Firefox blokuje dodatkowo żądania do domen ze swojej listy trackerów. Chrome nadal dopuszcza ciasteczka firm trzecich, więc w Chrome blokowanie przychodzi od adblocka, a nie od przeglądarki. Safari dodatkowo ogranicza czas, przez jaki przeżywa storage zapisany skryptem, w niektórych przypadkach do kilku dni, co oznacza, że wszystko, co opiera się na stanie zapisanym przy kliknięciu i odczytanym przy depozycie, ma ważność liczoną w ułamku normalnego okna decyzyjnego. Na wierzchu tego wszystkiego siedzą adblocki, powszechne dokładnie w tej publiczności, która przed rejestracją czyta treści porównawcze. Nic z tego się nie ogłasza. Twój operator widzi, że strona renderuje się poprawnie, i wnioskuje, że integracja działa.

Jest jeszcze część, której nie naprawi żadne ustawienie przeglądarki. Gracz klika na desktopie w pracy, przemyśla to i wpłaca wieczorem z telefonu. Albo rejestruje się w webie, a wpłaca w natywnej aplikacji, gdzie nie ma przeglądarki, nie ma strony i nie ma tagu do odpalenia. Zwłaszcza w bukmacherce depozyt idzie za terminarzem, a nie za kliknięciem, i idzie za nim do aplikacji. Jeśli chcesz zobaczyć, jak różnie zachowują się te dwie ścieżki, ruch kasynowy i bukmacherski rozjeżdżają się dokładnie w tym punkcie.

Piksel nie odpali się z miejsca, którego przeglądarka nigdy nie odwiedziła. Nic z tego nie naprawi lepsze umieszczenie tagu.

Tryby awarii, które warto znać

Nikt nie psuje integracji w ciekawy sposób. Za prawie wszystko odpowiada sześć tych samych błędów.

Odpalanie przy wczytaniu strony zamiast przy zdarzeniu. Tag siedzi na stronie potwierdzenia depozytu, więc odpala się przy każdym jej otwarciu. Gracz odświeża, wraca przez historię albo trafia tam po nieudanej próbie, a każde z tych wejść jest w Twoim raportowaniu konwersją. To zawyża liczby w kierunku, który wygląda dobrze, i dlatego trwa tak długo, zanim ktokolwiek zada pytanie.

Czy to naprawdę jest server-side? Backendowy framework renderujący szablon nadal emituje tag, który musi wykonać przeglądarka. Jeśli żądanie wychodzi z urządzenia gracza, jest po stronie przeglądarki, niezależnie od tego, w jakim pliku je zapisano. Test zajmuje minutę: zablokuj skrypty we własnej przeglądarce i sprawdź, czy zdarzenie nadal dochodzi.

Jest jeszcze identyfikator kliknięcia, którego brakuje na rekordzie gracza. To zdecydowanie najczęstsza awaria i ma poniżej własną sekcję.

Depozyt jest zgłaszany, zanim się rozliczy. Płatność zostaje autoryzowana, postback wychodzi, płatność następnie nie przechodzi albo zostaje cofnięta. I mamy prowizję doczepioną do pieniędzy, które nigdy nie dotarły. Odpalaj na stanie, który rozpoznałby Twój dział finansowy, a nie na stanie, który pokazuje strona koszyka.

Idempotencja, a raczej jej brak. Sieci mają timeouty. Dobrze zbudowany nadawca ponawia, i słusznie. Jeśli strona odbierająca nie potrafi rozpoznać, że druga próba jest tym samym zdarzeniem co pierwsza, ponowienie staje się drugą konwersją. Każde zdarzenie potrzebuje stabilnego, unikalnego identyfikatora po Twojej stronie, tej samej wartości przy każdej próbie, żeby duplikat dało się rozpoznać i odrzucić zamiast zapłacić dwa razy.

Zdarzenia przychodzą też w złej kolejności. Depozyt ląduje przed rejestracją, do której należy, bo dwie usługi odpaliły niezależnie i jedna była szybsza. Uporządkuj zdarzenia, które od siebie zależą, albo spraw, żeby każde niosło dość kontekstu, by stać samodzielnie.

Ta jedna rzecz, która decyduje o wszystkim

Każdą awarię powyżej da się naprawić w jedno popołudnie. Tej nie.

Gdy gracz przychodzi przez link trackingowy, identyfikator z tego linku musi zostać zapisany na rekordzie gracza przy rejestracji. Nie w sesji. Nie w ciasteczku. W wierszu Twojej bazy danych reprezentującym to konto, obok adresu e-mail, w tej samej transakcji, która to konto tworzy.

Jeśli to się nie wydarzy, nic dalej nie da się zaatrybuować. Gracz wpłaca trzy tygodnie później, Twój backend odpala technicznie idealny postback, a ten nie niesie żadnego identyfikatora, bo nie ma czego nieść. Żadne strojenie postbacków tego nie naprawi. Nie debugujesz problemu raportowego, tylko problem rejestracyjny, a poprawka jest w formularzu rejestracji.

Dwa powiązane nawyki oszczędzają mnóstwo sporów. Zachowuj identyfikator nawet wtedy, gdy wartość wygląda dziwnie, bo przechowujesz token, a nie go walidujesz. I trzymaj go przez całe życie konta, a nie przez trzydzieści dni, bo CPA płacone za kwalifikujący depozyt potrzebuje, żeby powiązanie nadal istniało w momencie, w którym depozyt się kwalifikuje, a to może być wiele miesięcy po kliknięciu. Jeśli słownictwo wokół kwalifikujących depozytów i pierwszych depozytów jest po Twojej stronie mgliste, słownik FTD, NGR, CPA, CPL i CPR jest wart dziesięciu minut przed pisaniem schematu.

Testowanie, zanim poleci ruch

Poprawny test integracji jest nudny i zajmuje mniej więcej godzinę.

1. Kliknij prawdziwy link trackingowy i przejdź rejestrację tak, jak zrobiłby to normalny gracz. Potem zajrzyj do rekordu gracza we własnej bazie i potwierdź, że identyfikator na nim jest. Jeśli go tam nie ma, przerwij, bo wszystko dalej jest teatrem.
2. Wpłać prawdziwe pieniądze. Mała kwota wystarczy, 20 EUR załatwi sprawę. Płatności w trybie testowym często omijają dokładnie tę ścieżkę kodu, która odpala zdarzenie, i tak właśnie integracje przechodzą na staging i padają pierwszego dnia.
3. Sprawdź, że zdarzenie depozytu przyszło raz, z właściwą kwotą i właściwą walutą, po rozliczeniu płatności, a nie w momencie jej zlecenia.
4. Wyślij to samo zdarzenie jeszcze raz, celowo. Powinno zostać rozpoznane jako duplikat i nie policzone dwa razy.
5. Powtórz całość na telefonie, a jeśli masz aplikację, jeszcze raz z depozytem zrobionym w aplikacji, a nie w przeglądarce.

Godzina czasu programisty i jeden depozyt, przeciwko miesiącowi uzgodnień z afiliantem, który już jest przekonany, że skubiesz mu ruch. Przewodnik po QA linku trackingowego pokrywa afiliancką stronę tego samego testu, a przejście obu końców razem to sposób na znalezienie rozjazdu w jedno popołudnie zamiast w kwartał.

Czego AFFILIFY oczekuje od operatora

Dokumentacja integracji żyje pod affilify.partners/docs, razem z endpointem, nazwami parametrów i akceptowanymi typami zdarzeń. Czytaj ją tam, a nie z wpisu na blogu, bo to tamta strona jest utrzymywana na bieżąco.

Kształt jest niewielki. Nazwa zdarzenia, identyfikator otrzymany w momencie kliknięcia, kwota i waluta oraz Twój klucz. Rejestracja, pierwszy depozyt, kolejne depozyty i zdarzenia przychodowe to osobne wiadomości, bo model prowizyjny przypisany do deala decyduje, które z nich mają znaczenie, a program nie zapłaci RevShare z danych, których nigdy nie dostał. Jeśli wciąż wybierasz między modelami, CPA, RevShare i hybryda opisuje, czego każdy z nich potrzebuje od Twojej strony.

Dwie rzeczy warto powiedzieć wprost. Atrybucja po naszej stronie ma warstwowe zabezpieczenia. Są ubezpieczeniem, a nie planem. Identyfikator zapisany przy rejestracji to część, którą kontrolujesz, więc go wysyłaj. I jakość ruchu jest oceniana na bieżąco, co oznacza, że część konwersji jest wstrzymywana na czas sprawdzenia, zamiast być zaliczana od razu. To nie jest odrzucenie, a afiliant widzi ten status, a nie cichą lukę.

Operator, który zwraca identyfikator, zgłasza rozliczone zdarzenia raz i daje się przetestować prawdziwym depozytem w godzinę, nigdy nie odbędzie tej rozmowy o jedenastej wieczorem. To cała ambicja tego tekstu.