Techniczne ograniczenia cookies: blokady, ITP/ETP i krótkie TTL
Klasyczny tracking afiliacyjny od lat opierał się na ciasteczkach third-party. Wydawca kierował ruch na link partnerski, sieć afiliacyjna sadziła ciasteczko, a reklamodawca przy konwersji odczytywał je i przypisywał prowizję. Ten model rozpada się głównie przez politykę przeglądarek i regulacje prawne.
Najważniejszy cios to blokowanie cookies zewnętrznych przez przeglądarki. Safari (ITP – Intelligent Tracking Prevention), Firefox (ETP – Enhanced Tracking Protection), a w ślad za nimi kolejne przeglądarki coraz agresywniej skracają czas życia ciasteczek lub blokują je całkowicie. Third-party cookies potrafią znikać po 24 godzinach, a w skrajnych przypadkach nie zapisują się wcale. Dla kampanii afiliacyjnych oznacza to obcięcie ogona konwersji – użytkownik kliknął wczoraj, kupuje dziś, a system widzi „ruch bez źródła”.
Drugi problem to skracanie TTL (time-to-live) również dla first-party cookies, jeśli przeglądarka rozpozna je jako element śledzenia między stronami. ITP potrafi zgasić takie ciasteczko po kilku dniach lub przy braku interakcji użytkownika. Dla programów z długim oknem konwersji (SaaS, B2B, drogie produkty) to dramat – duża część zasłużonych prowizji po prostu wypada z raportów.
Trzecia warstwa to zgody i banery. Użytkownik rozpoczyna wizytę bez zgody na marketingowe cookies, wykonuje kluczową akcję, a dopiero po fakcie akceptuje politykę. Dla ścisłego RODO oznacza to, że cookies marketingowe nie mogły zostać legalnie zapisane w momencie kliknięcia, więc tracking oparty wyłącznie na nich staje się dziurawy jak sito.
Nowa ścieżka użytkownika: mobile, aplikacje, cross-device
Równolegle zmienił się sposób korzystania z internetu. Użytkownik coraz częściej zaczyna ścieżkę na smartfonie, kończy na desktopie albo w aplikacji mobilnej. Ciasteczka z natury są przywiązane do przeglądarki i urządzenia, więc klasyczny model traci ciągłość.
Przykładowa ścieżka: użytkownik klika w reklamę afiliacyjną na blogu w mobilnym Chrome, przegląda ofertę, po czym ściąga aplikację sklepu z App Store, gdzie ostatecznie dokonuje zakupu. Ciasteczko zapisane w przeglądarce nie ma żadnego wpływu na to, co dzieje się w aplikacji. Bez alternatywnych mechanizmów (deep linki, przekazywanie ID, tracking serwer-to-serwer) wszystko wygląda jak „organiczna sprzedaż”, choć tak naprawdę przyszła z afiliacji.
Do tego dochodzą scenariusze cross-device: kliknięcie z telefonu, a konwersja na laptopie po zalogowaniu na to samo konto. Ciasteczka nie przeskoczą z jednego urządzenia na drugie. Bez identyfikatorów opartych o backend (user ID, click ID w CRM) czy fingerprinting, atrybucja afiliacyjna staje się w tych przypadkach loterią.
Skutki dla afiliacji: utrata atrybucji i napięcia z wydawcami
Dla reklamodawcy efekt jest pozornie „pozytywny”: część konwersji przestaje być przypisywana do źródeł płatnych, rośnie udział „direct” i „organic”. Na papierze to pięknie wygląda, bo CAC z afiliacji wydaje się niższy. Jednak w rzeczywistości oznacza to jedynie, że partnerzy nie dostają prowizji, którą realnie wygenerowali.
Dla wydawców (publisherów) zaniżona atrybucja to nie tylko niższy przychód, ale przede wszystkim utrata zaufania do programu. Jeśli widzą, że ruch się zgadza, a liczba konwersji jest nienaturalnie niska, zaczynają wycofywać ekspozycję, przerzucać ruch do konkurencyjnych reklamodawców lub sieci. Długoterminowo reklamodawca traci najlepsze źródła ruchu, a na placu boju zostają tylko ci, którzy nie liczą dokładnie pieniędzy.
Pojawia się też problem konfliktów: wydawca twierdzi, że „złapał” sprzedaż w swoim systemie (np. we własnym trackerze z fingerprintingiem), reklamaodawca jej nie widzi. Bez spójnej, zaawansowanej architektury trackingu bez ciasteczek trudno udowodnić, kto ma rację. Narastające spory o deduplikację i uznawanie konwersji potrafią położyć świetnie zapowiadające się partnerstwa.
Mit „wystarczą first-party cookies” – gdzie kończy się magia
Często powtarza się teza, że wystarczy „przesiąść się na ciasteczka first-party” i problem znika. Rzeczywistość jest mniej różowa. First-party cookies faktycznie działają lepiej niż third-party – są mniej agresywnie blokowane i mieszczą się w narracji o „własnych danych”. Jednak nie rozwiązują kluczowych wyzwań afiliacji.
Po pierwsze, ITP/ETP również potrafi skracać życie ciasteczek first-party, jeśli są wykorzystywane do śledzenia cross-site. Po drugie, ciasteczka nadal są przywiązane do konkretnej przeglądarki i urządzenia, więc nie ogarniają scenariuszy cross-device, aplikacji mobilnych, ani części ruchu z przeglądarek z mocnymi blokadami. Po trzecie, jeśli użytkownik nie wyraził zgody marketingowej na start, to zapis takiego ciasteczka bywa problematyczny prawnie.
Mit polega na uproszczeniu: „przeróbmy ciasteczko na first-party i po kłopocie”. W praktyce first-party cookies są jednym z elementów układanki, wsparciem dla click ID i tracking serwer-to-serwer, a nie cudownym remedium. Bez identyfikatorów w URL, zapisów po stronie serwera czy fingerprintingu, utrata atrybucji nadal będzie bolesna.
„Nie trackuje = nie płacę” – krótka droga do utraty wartościowego ruchu
Część reklamodawców przyjmuje twarde podejście: „Skoro sprzedaż nie weszła do systemu afiliacyjnego, nie ma prowizji”. Z perspektywy księgowości to proste i kuszące. Z perspektywy budowania długoterminowego kanału sprzedaży – autodestrukcyjne.
Dobrzy wydawcy potrafią weryfikować swoje kampanie alternatywnymi narzędziami: własnymi trackerami, analityką serwerową, fingerprintingiem. Jeśli widzą powtarzającą się rozbieżność – na przykład regularnie x konwersji więcej niż raportuje system reklamodawcy – nie mają powodu, by „przymykać oko”. Prędzej czy później ruch zostaje przeniesiony do programów, które mają lepiej ustawiony tracking bez ciasteczek i realnie wypłacają za wykonaną pracę.
Paradoksalnie więc, im bardziej złożone środowisko techniczne (blokady cookies, mobilność, RODO), tym ważniejsze staje się inwestowanie w solidną architekturę atrybucji zamiast „oszczędzania” na prowizjach z powodu dziurawego trackingu. Długofalowo lepiej zapłacić za realne konwersje niż tracić partnerów i palić reputację programu.
Źródło: Pexels | Autor: panumas nikhomkhai
Fundamenty trackingu bez ciasteczek – o co tu naprawdę chodzi
Identyfikator kliknięcia, użytkownika i konwersji – trzy różne światy
Tracking afiliacyjny bez ciasteczek opiera się na zarządzaniu identyfikatorami, zamiast polegania na magicznym „ciasteczku partnerskim”. Kluczowe są trzy rodzaje ID:
Identyfikator kliknięcia (click ID, transaction ID) – unikalny token generowany w momencie kliknięcia w link afiliacyjny. Jego zadaniem jest podróż przez kolejne systemy: od wydawcy, przez sieć, po reklamodawcę.
Identyfikator użytkownika (user ID) – po stronie reklamodawcy może to być ID konta, ID w CRM, identyfikator zalogowanego użytkownika. Służy do łączenia zdarzeń pochodzących z różnych urządzeń i sesji.
Identyfikator konwersji (order ID, lead ID) – przypisany konkretnej akcji: zakupowi, wypełnieniu formularza, rejestracji. To jego używa się do deduplikacji i raportowania statusów (approved, rejected, canceled).
Kluczem jest spójne powiązanie tych trzech poziomów: klik ID musi być zapisany gdzieś po stronie serwera, powiązany z user ID (gdy to możliwe), a przy konwersji skojarzony z konkretną transakcją. Cookies mogą być pomocne, ale nie są jedyną drogą. Bez tej logiki cała reszta (fingerprinting, serwer-to-serwer) nie będzie miała na czym się oprzeć.
Parametr kliknięcia i jego „podróż” przez systemy
Parametr kliknięcia to serce nowoczesnego trackingu afiliacyjnego. Najczęściej ma postać ciągu znaków w URL, np. click_id, t_id, transaction_id. Generuje go sieć afiliacyjna lub własny tracker reklamodawcy w momencie, gdy użytkownik przechodzi z witryny wydawcy do witryny docelowej.
Typowa podróż wygląda tak:
Wydawca wyświetla link zawierający swoje ID (aff_id) i miejsce na click ID.
Po kliknięciu sieć afiliacyjna generuje unikalny click ID i zapisuje go w swojej bazie razem z informacjami o wydawcy, kampanii, strefie reklamowej.
Sieć przekierowuje użytkownika do reklamodawcy, doklejając click ID w parametrze URL.
Strona reklamodawcy odczytuje click ID z URL i zapisuje go po swojej stronie (w bazie, sesji serwerowej, localStorage).
Gdy następuje konwersja, backend reklamodawcy wysyła postback do sieci afiliacyjnej, przekazując click ID i dane o konwersji.
Mit „magicznego ciasteczka afiliacyjnego” polega na tym, że wiele osób ignoruje świadome zarządzanie click ID. Tymczasem to właśnie click ID jest deterministycznym łącznikiem między kliknięciem a zamówieniem. Nawet jeśli cookies przestaną działać, click ID może być przechowywany w bazie danych lub w localStorage, a potem powiązany z konwersją niezależnie od ograniczeń przeglądarki.
Co może zastąpić cookies: URL, localStorage, sesje serwerowe, logi
Ciasteczka to tylko jedna z opcji przechowywania informacji o źródle. Tracking bez ciasteczek wykorzystuje alternatywne nośniki:
ID w URL – click ID i inne parametry (aff_id, sub_id) są przekazywane w adresie podczas przekierowań. To pierwsze ogniwo łańcucha, niezależne od przeglądarkowych blokad cookies.
LocalStorage – dane po stronie przeglądarki zapisane w mechanizmie localStorage są mniej agresywnie czyszczone niż cookies i nie są wysyłane przy każdym żądaniu HTTP. Można tam przetrzymywać click ID czy timestamp kliknięcia, o ile zgody użytkownika na to pozwalają.
Sesja serwerowa – po odczytaniu click ID z URL backend może powiązać go z sesją użytkownika po stronie serwera (np. ID sesji zapisane w ciasteczku funkcjonalnym lub tokenie). Dzięki temu dalsze działania użytkownika będą „przypięte” do danego kliknięcia nawet bez dodatkowych cookies marketingowych.
Logi aplikacyjne i DWH – przechowywanie eventów kliknięć i zdarzeń konwersji w hurtowni danych (BigQuery, Snowflake, PostgreSQL) pozwala na późniejsze matchowanie zdarzeń, modelowanie konwersji offline czy rekalkulację prowizji.
Mit, że „tracking bez cookies = fingerprinting”, wynika z skupienia się na jednym spektakularnym narzędziu zamiast na całym ekosystemie. W rzeczywistości fingerprinting jest tylko jednym z pomocniczych mechanizmów, a kręgosłup stanowią identyfikatory zdarzeń i spójne przechowywanie danych po stronie serwera.
Od „śledzenia osoby” do „matchowania zdarzeń”
W erze RODO i blokad śledzenia zmienia się też filozofia trackingu. Zamiast myśleć w kategoriach „śledzenia osoby wszędzie”, sensowniej jest projektować systemy wokół matchowania zdarzeń. Chodzi o to, by umieć połączyć konkretne kliknięcie w link partnerski z konkretną konwersją, a nie budować profil użytkownika na lata.
Tracking bez ciasteczek faworyzuje podejście event-based: każde kliknięcie, wyświetlenie, rejestracja czy zakup to osobny rekord z identyfikatorami (click ID, user ID, campaign ID, timestamp). W momencie konwersji system próbuje znaleźć pasujące kliknięcie wg ustalonych reguł (okno czasowe, atrybucja last click / multi-touch). Dane o użytkowniku są w tym modelu zanonimizowane lub ograniczone do minimum, co upraszcza kwestie prawne.
Takie myślenie prowadzi naturalnie do rozwiązań serwer-to-serwer, hybrydowych modeli trackingu i bardziej transparentnych zasad atrybucji. Zamiast „magicznych cookies”, które „coś tam trackują”, mamy jawny mechanizm: kliknięcie ma ID, konwersja ma ID, zasady matchowania są zdefiniowane w kodzie lub konfiguracji.
Fingerprinting – jak działa, do czego się nadaje, a do czego nie
Techniczne podstawy fingerprintingu: z czego „składany” jest odcisk
Fingerprinting użytkownika polega na zebraniu zestawu cech środowiska (przeglądarka, urządzenie, sieć) i wygenerowaniu z nich względnie unikalnego identyfikatora. Typowe składowe to:
nagłówek User-Agent (typ przeglądarki, wersja, system operacyjny),
zainstalowane czcionki i pluginy (jeśli dostępne),
strefa czasowa, język przeglądarki, preferencje regionalne,
wyniki testów canvas / WebGL (specyficzne cechy renderowania),
adres IP (czasem z geolokalizacją na poziomie miasta / regionu).
Z tych danych generowany jest hash (np. MD5, SHA-256), który staje się fingerprintem. Gdy użytkownik wróci, system ponownie zbiera cechy, wylicza hash i próbuje dopasować go do wcześniej znanych fingerprintów. Jeśli znajdzie zgodny lub podobny, można z dużym prawdopodobieństwem założyć, że to ta sama osoba lub przynajmniej to samo urządzenie.
Stabilność fingerprintu i problem „szumu” w danych
Fingerprint brzmi jak stabilny identyfikator, ale w praktyce jest zaskakująco kruchy. Zmiana przeglądarki, aktualizacja systemu, podpięcie drugiego monitora czy korzystanie z VPN potrafią całkowicie zmienić odcisk. Z drugiej strony, dwa różne urządzenia w korporacyjnej sieci z tym samym OS i przeglądarką mogą wyglądać bliźniaczo podobnie.
Dla trackingu afiliacyjnego oznacza to konieczność pracy na prawdopodobieństwie, a nie na pewności. Zazwyczaj stosuje się więc:
porównywanie zestawów cech, a nie tylko jednego hasha (np. podobieństwo na poziomie 80–90%),
ograniczone okno czasowe – ten sam fingerprint z kliknięcia i z konwersji musi pojawić się w zakresie kilku godzin czy dni, a nie miesięcy,
łączenie fingerprintu z innymi sygnałami: IP, kraj, ścieżka wejścia, typ kampanii.
Mit „fingerprinting jest superdokładny” rodzi się z prezentacji sprzedażowych, nie z realnych logów. W danych produkcyjnych fingerprint daje masę szumu – duplikatów, fałszywych dopasowań, „znikających” użytkowników po aktualizacji przeglądarki. Trzeba go traktować jako pomocniczy sygnał, a nie główny filar modelu rozliczeń.
Fingerprinting a prywatność i zgodność z prawem
Regulatorzy w Europie i USA wprost wskazują fingerprinting jako technikę śledzenia wymagającą zgody. To nie jest „sprytne obejście RODO”, lecz przetwarzanie danych o urządzeniu, które może być uznane za dane osobowe, jeśli da się połączyć z innymi informacjami.
W praktyce oznacza to konieczność:
jasnego opisania fingerprintingu w polityce prywatności i banerze zgód,
przestrzegania wyborów użytkownika – jeśli odrzuci tracking marketingowy, fingerprint nie może być wykorzystywany do atrybucji reklamowej,
wdrożenia retencji – fingerprinty nie powinny być przechowywane latami bez powodu.
Rzeczywistość jest taka, że fingerprinting bez zgody to bomba z opóźnionym zapłonem: może „działać” technicznie, ale ryzyko regulacyjne i reputacyjne rośnie z każdym miesiącem. Dla poważnych programów afiliacyjnych lepszą drogą jest ograniczenie fingerprintingu do scenariuszy, gdzie użytkownik świadomie zgodził się na zaawansowane śledzenie.
Przykładowe scenariusze użycia fingerprintingu w afiliacji
Jest kilka obszarów, w których fingerprinting realnie pomaga, o ile jest używany z głową:
Ratowanie „sierot” konwersji – jeśli nie udało się powiązać zamówienia z żadnym click ID (brak parametrów w URL, wyczyszczone localStorage), system może spróbować dopasować fingerprint konwersji do fingerprintów ostatnich kliknięć.
Anti-fraud – powtarzające się wzorce fingerprintów na wielu „różnych” użytkownikach (leady z tej samej maszyny, masowe rejestracje) to silny sygnał potencjalnego fraudu.
Wsparcie atrybucji cross-device – gdy użytkownik kliknie w link na desktopie, a kupi z telefonu, fingerprint sam z siebie nie wystarczy, ale może być jednym z elementów układanki obok logowania, e-maila czy numeru telefonu.
Mit, że fingerprinting zastąpi brak ciasteczek jeden do jednego, zwykle kończy się albo rozczarowaniem wydawców (spada liczba rozpoznanych konwersji), albo konfliktami prawno‑compliance’owymi. Bez jasnej strategii użycia i kontroli jakości danych staje się bardziej przeszkodą niż pomocą.
Na czym faktycznie polega S2S i czym różni się od pixel trackingu
Tracking serwer‑to‑serwer polega na tym, że to backend reklamodawcy komunikuje się bezpośrednio z backendem sieci afiliacyjnej, przekazując dane o konwersji: click ID, wartość zamówienia, walutę, status. Przeglądarka użytkownika przestaje być głównym nośnikiem informacji – jej rola ogranicza się do przeniesienia click ID w URL podczas kliknięcia.
W klasycznym modelu pixelowym backend reklamodawcy wyświetla na stronie podziękowania niewidoczny obrazek lub tag JS, który strzela do sieci afiliacyjnej z przeglądarki użytkownika. S2S eliminuje ten element: po zapisaniu zamówienia w bazie serwer reklamodawcy sam wysyła żądanie HTTP (postback) do sieci.
Różnice są kluczowe:
w S2S konwersja może być raportowana bez udziału przeglądarki (np. przy zamówieniach telefonicznych, płatnościach offline),
nie ma problemu z AdBlockiem blokującym skrypty czy piksele,
tracking nie opiera się na cookies third‑party – bazuje na click ID i logice serwerowej,
łatwiej kontrolować logikę deduplikacji i korekt (refundacje, chargebacki).
Cykl życia click ID w modelu S2S
Żeby S2S działał, click ID musi być poprawnie „przeniesiony” z kliknięcia do konwersji. Minimalny przepływ wygląda tak:
Użytkownik klika w link afiliacyjny – sieć generuje click ID i dokleja je do URL reklamodawcy.
Strona reklamodawcy odczytuje click ID i zapisuje je: w bazie sesji, w polu w koszyku, w tabeli „atrybucje”.
Użytkownik składa zamówienie – backend tworzy rekord zamówienia wraz z powiązanym click ID.
Procesor płatności potwierdza transakcję – backend aktualizuje status zamówienia na „paid/confirmed”.
W tym momencie serwer reklamodawcy wysyła postback do sieci, przekazując click ID, wartość i inne parametry.
Mit „S2S to po prostu inny rodzaj piksela” bierze się z mylenia końcowego efektu (sieć dostaje informację o konwersji) z drogą, jaką dane tam trafiają. W S2S odpowiedzialność przesuwa się z frontendu na backend i wymaga zaprojektowania pełnej ścieżki danych po stronie reklamodawcy.
Typy postbacków: on‑sale, on‑paid, on‑event
W praktyce nie ma jednego „postbacku od konwersji”. Reklamodawca często wysyła kilka różnych rodzajów zdarzeń, które sieć może mapować na etapy lejka:
Postback on‑sale – wysyłany po złożeniu zamówienia (status „new/order_created”). Szybki, ale jeszcze niepewny z punktu widzenia płatności i zwrotów.
Postback on‑paid – wysyłany, gdy płatność jest potwierdzona (status „paid/captured”). Zwykle to ten etap decyduje o prowizji, szczególnie w modelach CPS.
Postback on‑event – dowolne zdarzenia pośrednie: rejestracja, aktywacja konta, ukończenie tutoriala w aplikacji, przedłużenie subskrypcji. Przydatne w programach SaaS i mobile.
Dobrze zaprojektowany S2S pozwala sieci afiliacyjnej odzwierciedlić realny cykl życia klienta, a nie tylko jednorazową „sprzedaż”. W klasycznym modelu pixelowym śledzenie kolejnych etapów bywa karkołomne, bo wymaga dokładania kolejnych tagów na front‑endzie i modzenia się z AdBlockami.
Walidacja postbacków i bezpieczeństwo
Postback jest zwykłym żądaniem HTTP, więc musi być zabezpieczony tak, by nikt z zewnątrz nie mógł „dobić” sztucznych konwersji. Typowe mechanizmy obejmują:
tajny klucz (secret) – parametr w URL lub nagłówku, znany tylko reklamodawcy i sieci; bez niego postback jest odrzucany,
podpis HMAC – hash zbudowany z parametrów postbacku i sekretu; sieć po swojej stronie przelicza hash i porównuje, czy żądanie nie było modyfikowane,
whitelistę IP – przydatne, gdy reklamodawca wysyła postbacki z ograniczonej puli adresów,
limity i sanity checki – np. odrzucanie konwersji z wartością ujemną lub absurdalnie wysoką, blokowanie powtarzających się order ID.
Bez tych elementów S2S staje się kuszącym celem dla nadużyć: „życzliwy” partner może próbować naśladować postbacki i generować prowizje z powietrza. Zabezpieczenia nie są opcjonalnym dodatkiem, lecz elementarną częścią implementacji.
Architektura hybrydowa: łączenie S2S, fingerprintingu i minimum cookies
Dlaczego pojedyncze rozwiązanie już nie wystarcza
Cookies same nie wystarczają. Sam fingerprinting nie jest ani stabilny, ani prosty prawnie. Sam S2S nie załatwi wszystkiego, jeśli po drodze gubimy click ID lub użytkownik przeskakuje między urządzeniami. W praktyce najlepiej działa układ hybrydowy, w którym kilka metod uzupełnia się wzajemnie.
Przykładowy model:
S2S odpowiada za „twarde” powiązania kliknięcie → zamówienie tam, gdzie mamy click ID.
Cookies i/lub localStorage pomagają utrzymać powiązanie w obrębie jednej przeglądarki i krótkiego okna czasowego.
Fingerprinting i logika heurystyczna ratują część konwersji, dla których click ID zaginął, ale wzorzec zachowania wskazuje na konkretną kampanię.
Mit, że „prawdziwy tracking bez cookies nie używa cookies w ogóle”, jest po prostu fałszywy. Chodzi o wyjście poza ciasteczka jako jedyne źródło prawdy, nie o ich religijne odrzucenie. Ciasteczka pierwszostronne, używane rozsądnie i zgodnie z prawem, nadal są bardzo użytecznym elementem układanki.
Priorytety atrybucji w modelu hybrydowym
Skoro mamy wiele źródeł sygnałów, trzeba ustalić hierarchię. Inaczej każdy vendor będzie „łapał” konwersję po swojemu i wszyscy będą mieli rację, tylko budżet się nie zepnie. Typowa piramida priorytetów wygląda tak:
Deterministyczne matchowanie po click ID – jeśli jest, wygrywa z każdym innym sygnałem.
ID użytkownika (user ID) + historia wizyt – dla zalogowanych użytkowników można łączyć ich aktywności w czasie.
Cookies/ localStorage first‑party – w obrębie jednego urządzenia i przeglądarki.
Fingerprinting i inne heurystyki – używane tylko wtedy, gdy brak powyższych.
Dobrym kompromisem jest również ograniczanie wag heurystyk: jeśli konwersja została złapana wyłącznie na fingerprintingu, można stosować krótsze okna czasowe, niższe domyślne prowizje lub dodatkową walidację (np. manualny review w kampaniach wysokiego ryzyka).
Obsługa sytuacji „konwersja bez znanego źródła”
W każdym systemie będą konwersje, których nie da się uczciwie przypisać żadnemu kliknięciu partnerskiemu. Użytkownik mógł wejść z direct, z organicznego SEO, z newslettera. Próba „na siłę” dopasowania ich do afiliantów na podstawie przypadkowego podobieństwa fingerprintu kończy się emocjonalnymi dyskusjami o „kradzionych” konwersjach.
Zdrowe podejście wygląda tak:
System próbuje matchowania po click ID, ID użytkownika, cookies, fingerprintingu – w takiej kolejności, z jasno opisanymi oknami czasowymi.
Jeśli nie znajdzie wiarygodnego dopasowania, konwersja dostaje status „non‑affiliate” i trafia do innych kanałów w atrybucji.
Sieć i reklamodawca mają wspólnie zdefiniowane progi jakości dopasowań, poniżej których lepiej nie przypisywać prowizji, niż ją wymuszać.
Konwersje „bez źródła” nie są porażką systemu, tylko naturalnym skutkiem złożonej rzeczywistości. Walka z nimi za wszelką cenę prowadzi prosto do nadużywania fingerprintingu i naruszeń prywatności.
Źródło: Pexels | Autor: cottonbro studio
Przekazywanie identyfikatorów: parametry URL, ID partnera, deep linki
Standardowy zestaw parametrów w linkach afiliacyjnych
Podstawą całej zabawy jest sensowny schemat parametrów w URL. Typowy link afiliacyjny niesie co najmniej:
id partnera (aff_id / publisher_id) – kto wygenerował ruch,
id kampanii / oferty (offer_id / campaign_id) – na którą ofertę prowadzi link,
sub_id / sub_id1–4 – pola dla wydawcy na własne oznaczenia (np. ID kreacji, placementu, testu A/B),
click_id / transaction_id – unikalny identyfikator kliknięcia, generowany przez sieć lub tracker.
Po stronie reklamodawcy nie trzeba przechowywać wszystkiego. Wystarczy click ID, bo resztę informacji ma sieć afiliacyjna. Częstym błędem jest przepisywanie aff_id czy sub_id do własnej bazy, a później próba samodzielnego liczenia prowizji na tych polach. Łatwiej i pewniej jest uznać click ID za jedyny klucz „zewnętrzny”, resztę zostawiając systemowi partnerskiemu.
Deep linki i przekazywanie identyfikatorów w głąb ścieżki
Użytkownik rzadko trafia od razu na stronę koszyka. Częściej ląduje na landing page’u, kategorii produktowej, blogu. Każde przekierowanie po drodze jest okazją do zgubienia parametrów afiliacyjnych, jeśli linki wewnętrzne nie są przygotowane na ich przenoszenie.
W dobrze zaprojektowanym systemie:
Po pierwszym wejściu click ID jest odczytywany z URL i zapisywany (np. w sesji, localStorage, ID użytkownika).
Przenoszenie click ID między stronami i domenami
Sam zapis click ID w przeglądarce to połowa sukcesu. Druga połowa to zadbanie, żeby ten identyfikator „przeżył” przejścia między różnymi częściami ekosystemu reklamodawcy – zwłaszcza jeśli w grę wchodzi więcej niż jedna domena lub subdomena.
Praktyczny schemat wygląda następująco:
Na pierwszym wejściu front zapisuje click ID (np. w localStorage i/lub ciasteczku first‑party).
Przy wejściu na każdą krytyczną podstronę (rejestracja, checkout, płatność) front sprawdza, czy ma click ID i jeśli trzeba – dociąga go do backendu (np. jako hidden field w formularzu lub parametr w wywołaniu API).
Jeżeli proces zakupu odbywa się na innej domenie (np. checkout.brand‑pay.com), click ID trzeba przenieść jawnie w URL lub przez mechanizm typu signed redirect.
Mit: „click ID wystarczy mieć na pierwszej stronie wejścia”. Rzeczywistość: jeśli click ID nie dotrwa do momentu utworzenia zamówienia w bazie, S2S nie będzie miał czego zmatchować. Pośrednie ekrany, mikrousługi i zewnętrzne bramki płatności są najczęstszym miejscem, w którym identyfikator ginie.
Integracja z aplikacjami mobilnymi – schematy URL i deferred deep linking
W mobile afiliacja szybko zderza się z faktem, że użytkownik przełącza się między przeglądarką a aplikacją. Jeśli kampania kieruje do App Store/Google Play, klasyczne parametry w URL znikają w procesie instalacji. Żeby tracking miał sens, trzeba dołożyć warstwę pośrednią.
Najczęściej stosuje się kombinację:
schematów URL / universal links – link, który otwiera aplikację, jeśli ta jest zainstalowana, a jeśli nie – kieruje do sklepu,
„deferred deep linking” – po instalacji aplikacja pobiera z serwera kontekst kampanii (np. click ID, źródło ruchu) na podstawie fingerprintu urządzenia lub ID reklamowego.
Po stronie afiliacji ważne są dwie rzeczy. Po pierwsze, click ID z kliknięcia w mobilną reklamę musi trafić do systemu atrybucji mobilnej (MMP lub własnego trackera), który potem zwróci go w postbacku instalacji/aktywacji. Po drugie, aplikacja musi umieć ten identyfikator przechować lokalnie i powiązać z kolejnymi zdarzeniami (np. zakup w aplikacji), tak aby S2S mógł przypisać prowizję temu samemu wydawcy.
Częsty błąd: aplikacja wysyła do backendu tylko swoje wewnętrzne user ID, bez powiązanego click ID z etapu instalacji. W efekcie pierwsza konwersja jest policzona afiliacyjnie, kolejne już nie – mimo że użytkownik ciągle klika w te same powiadomienia i banery.
Przekazywanie identyfikatorów przez API i event bus
W bardziej złożonych systemach nie ma jednego monolitu, tylko kilkanaście usług: od frontu, przez koszyk, po system fakturujący. Tam parametry URL przestają wystarczać; potrzebny jest wewnętrzny „krwiobieg” identyfikatorów.
Sprawdza się kilka prostych zasad:
Model danych zawierający klucze afiliacyjne – obiekt zamówienia ma pola typu affiliate_click_id, affiliate_source, które są przenoszone między usługami razem z innymi danymi.
Event bus / message queue – zdarzenia „OrderCreated”, „OrderPaid” niosą ze sobą click ID, dzięki czemu usługa odpowiedzialna za integrację z sieciami może reagować na eventy, a nie doklejać się bezpośrednio do logiki koszyka.
Jawne kontrakty między usługami – jeżeli serwis „Checkout” przekazuje dane do „Billingu”, w kontrakcie API musi być zdefiniowane, czy i jak przekazywany jest identyfikator afiliacyjny.
Mit mówi, że tracking afiliacyjny to „sprawa marketera i frontendu”. W rozproszonych systemach bez wsparcia architektów i deweloperów backendu śledzenie rozjedzie się przy pierwszej poważniejszej refaktoryzacji.
Implementacja po stronie reklamodawcy: logika w backendzie i integracja postbacków
Projekt modelu danych dla afiliacji
Zanim pojawi się choć jedna linijka kodu S2S, trzeba ustalić, gdzie i pod jaką postacią będą przechowywane dane afiliacyjne. Minimum to:
pole na click ID w tabeli zamówień (lub w powiązanej tabeli „order_tracking”),
status atrybucji – np. affiliate_status = {none, pending, attributed, rejected},
informacja o sieci / źródle – potrzebna, jeśli współistnieje kilka partnerów lub działa równolegle wewnętrzny program resellerski.
W modelach subskrypcyjnych dobrze jest dodać osobny byt „AffiliateAttribution”, powiązany z klientem lub subskrypcją, a nie tylko pojedynczym zamówieniem. Dzięki temu system wie, kto „przyprowadził” klienta, nawet jeśli ten składa kolejne zamówienia poza oryginalnym oknem cookie.
Mapping statusów zamówień na typy konwersji
Backend zamówień zwykle zna kilkanaście statusów: od „initiated” przez „awaiting_payment” po „refunded”. Świat afiliacji zwykle operuje 2–3 typami konwersji. Trzeba więc zdefiniować mapowanie: który status (lub sekwencja statusów) odpala jaki postback.
Do tego dochodzą scenariusze negatywne: anulacje, chargebacki, zwroty. Tu przydaje się albo osobny kanał korekt (postback „rejected”), albo mechanizm wewnętrzny, który odpowiednio oznacza zamówienie i sygnalizuje sieci korektę prowizji. Ignorowanie zwrotów i reklamacji kończy się napięciami: reklamodawca widzi mniejszy realny przychód niż to, co policzyła sieć.
Obsługa wielu sieci i vendorów równolegle
Większość większych sklepów jednocześnie współpracuje z kilkoma sieciami, narzędziami analitycznymi i własnym CRM‑em. Jeśli każdy vendor dostaje „swoje” piksele i postbacki bez spójnego modelu, powstaje klasyczny „circus of attributions”.
Rozsądniejsze podejście to warstwa pośrednia w backendzie:
System wewnętrzny jest jedynym miejscem, gdzie podejmowana jest decyzja: która sieć (i który click ID) otrzyma informację o danej konwersji.
Sieci dostają wyłącznie „swoje” konwersje, zgodnie z ustaloną logiką priorytetów (last click, first click, model mieszany z CRM itd.).
Dla każdego vendora konfiguruje się osobny endpoint postbacku, szablon parametrów i sposób podpisu (secret, HMAC, token w nagłówku).
Mit, że „każdy vendor policzy sobie to sam, a potem się porówna raporty”, w praktyce rozbija się o niezgodność definicji konwersji i okien czasowych. Jeśli logika atrybucji nie jest zatrzymana pod kontrolą reklamodawcy, negocjacje z partnerami zamieniają się w dyskusję „czyja liczba jest bardziej prawdziwa”.
Mechanizm kolejek i retry dla postbacków
Postbacki nie mogą być zależne od chwilowego humoru sieci lub problemów z łącznością. Jeśli wysyłasz je synchronicznie w trakcie obsługi zamówienia, każde timeoutowane żądanie będzie blokować lub spowalniać kluczowy proces biznesowy.
Bezpieczniejszy wzorzec to:
przy zmianie statusu zamówienia lub wygenerowaniu eventu afiliacyjnego backend zapisuje zdarzenie do kolejki (np. Kafka, RabbitMQ, SQS) lub tabeli „pending_postbacks”,
oddzielny worker / cron regularnie odczytuje to, co czeka w kolejce, i wysyła postbacki do sieci,
w przypadku błędu stosowany jest mechanizm ponowień (retry) z rosnącym opóźnieniem oraz limit prób,
jeśli po kilku próbach sieć nadal zwraca błąd, zdarzenie jest oznaczane jako wymagające manualnego sprawdzenia.
Taki model nie tylko stabilizuje system przy awariach zewnętrznych, ale też ułatwia audyt: w logach lub tabelach retry dokładnie widać, które konwersje kiedy były wysyłane i z jaką odpowiedzią.
Idempotencja wywołań – jak nie zliczać prowizji dwa razy
Po stronie sieci oczywistym wymogiem jest, żeby wielokrotny postback tego samego zamówienia nie skutkował naliczeniem wielu prowizji. Ale identyczna zasada przydaje się w backendzie reklamodawcy: proces wysyłki postbacków musi być odporny na powtórzone eventy i ponowne uruchomienie workerów.
Proste techniki:
Każda atrybucja ma swój unikalny klucz idempotencyjny, np. kombinację network_id + click_id + order_id + event_type.
Przed wysłaniem postbacku worker sprawdza w tabeli logów, czy dla danego klucza nie było już udanego wywołania.
Sieć afiliacyjna po swojej stronie również wykorzystuje transaction_id lub order_id do deduplikacji.
Bez idempotencji każde drobne potknięcie – od błędu w kolejce po nieostrożne ponowne uruchomienie skryptu – może wygenerować serię nadpłat i późniejszych korekt. Technicznie to kilka dodatkowych pól i indeksów w bazie, biznesowo – różnica między spokojnym month‑end a kolejną „aferą raportową”.
Logowanie i debugowanie ścieżki afiliacyjnej
Przy wdrażaniu zaawansowanego trackingu nie ma ucieczki przed porządnym logowaniem. Problemy wychodzą nie wtedy, gdy wszystko działa, tylko gdy raz na jakiś czas coś zachowa się inaczej niż zwykle.
Przydaje się kilka poziomów wglądu:
log wejścia – zapis każdego kliknięcia z click ID, IP, user‑agentem, parametrami kampanii,
log powiązania – moment, w którym zamówienie / rejestracja zostaje przypisane do click ID, wraz z decyzją, jaki model atrybucji to uzasadnia,
log decyzji negatywnych – przypadki, w których system nie przypisał afiliacji (np. zbyt stare kliknięcie, konflikt kilku click ID, brak wiarygodnego fingerprintu).
W znacznej części sporów „nie macie dla nas wszystkich konwersji” czy „kradniecie nam sprzedaż” rozstrzygające okazuje się kilka dobrze opisanych logów, a nie kolejne prezentacje w PowerPoincie.
Testowanie end‑to‑end: od kliknięcia do raportu
Najbardziej niedoszacowany etap wdrożenia to testy przechodzące całą ścieżkę. Zbyt często ogranicza się je do sprawdzenia, czy postback „odpala się” z panelu developera, bez realnego kliknięcia i bez udziału przeglądarki użytkownika.
Solidny scenariusz testowy obejmuje m.in.:
wygenerowanie kliknięcia z realnego linku afiliacyjnego (np. w środowisku stagingowym sieci),
przejście pełnej ścieżki zakupowej/aktywacyjnej, z uwzględnieniem przekierowań i ewentualnego logowania,
sprawdzenie w bazie, czy click ID i powiązane dane zostały poprawnie zapisane przy zamówieniu,
weryfikację, że odpowiedni postback został wysłany do sieci, a ta zaksięgowała konwersję zgodnie z oczekiwanym statusem i atrybutami,
symulację negatywnych scenariuszy: anulacja zamówienia, płatność odrzucona, ponowne kliknięcie innego partnera przed finalizacją.
Po kilku takich pełnych przejściach większość „magicznych” rozbieżności między statystykami sieci a danymi reklamodawcy przestaje być magią, a zaczyna być konkretną listą edge‑casów do zaadresowania.
Najczęściej zadawane pytania (FAQ)
Co to jest tracking afiliacyjny bez ciasteczek?
Tracking afiliacyjny bez ciasteczek to sposób śledzenia kliknięć i konwersji, który nie opiera się wyłącznie na cookies przeglądarki. Zamiast „magicznego ciasteczka partnerskiego” wykorzystuje identyfikatory w URL (np. click ID), zapisy po stronie serwera, integracje serwer‑to‑serwer, a czasem fingerprinting urządzenia.
Różnica jest prosta: w klasycznym modelu wszystko żyło w przeglądarce użytkownika, teraz ciężar przenosi się na backend reklamodawcy i sieci afiliacyjnej. Dzięki temu tracking lepiej znosi blokady cookies, krótkie TTL oraz scenariusze typu mobile, aplikacje i cross‑device.
Czy first-party cookies wystarczą do skutecznego trackingu afiliacyjnego?
To popularny mit. First-party cookies rzeczywiście są trwalsze i mniej blokowane niż third-party, ale nie rozwiązują problemów afiliacji. Nadal są przywiązane do konkretnej przeglądarki i urządzenia, więc gubią konwersje z aplikacji mobilnych i ścieżki cross‑device.
Dodatkowo Safari (ITP) i Firefox (ETP) potrafią skracać życie nawet first-party cookies, jeśli wyglądają na element śledzenia między stronami. Bez click ID w URL, zapisów po stronie serwera i integracji serwer‑to‑serwer, same first‑party cookies jedynie „łatają dziury”, a nie budują solidnej atrybucji.
Jak działa tracking serwer-to-serwer (S2S) w programach afiliacyjnych?
Tracking serwer‑to‑serwer polega na tym, że informacja o konwersji jest wysyłana bezpośrednio z serwera reklamodawcy do serwera sieci afiliacyjnej lub trackera, zamiast polegać na pikselu w przeglądarce. Kluczem jest tu identyfikator kliknięcia (click ID), który został wcześniej zapisany po stronie backendu.
Typowy schemat wygląda tak: użytkownik klika w link z click ID → system reklamodawcy zapisuje ten ID w swojej bazie, najlepiej powiązany z user ID → przy zakupie serwer reklamodawcy wysyła do sieci zdarzenie z click ID i danymi transakcji. W efekcie przeglądarka i cookies są jedynie „nośnikiem” pierwszej informacji, a nie krytycznym elementem całego procesu.
Na czym polega fingerprinting w afiliacji i czy jest legalny?
Fingerprinting to technika identyfikowania użytkownika na podstawie zestawu sygnałów technicznych, takich jak przeglądarka, system operacyjny, rozdzielczość ekranu, strefa czasowa czy adres IP. Z tych danych buduje się względnie unikalny „odcisk palca” urządzenia, który może wspierać atrybucję, kiedy cookies zawodzą.
Od strony prawa sytuacja jest bardziej złożona. Jeśli fingerprinting pozwala zidentyfikować użytkownika lub jego urządzenie, w praktyce jest traktowany podobnie jak cookies marketingowe – wymaga odpowiedniej podstawy prawnej (najczęściej zgody) i transparentnej informacji w polityce prywatności. Mit, że „fingerprinting obchodzi RODO”, jest po prostu fałszywy – to tylko inna technika przetwarzania danych, nie „wolnoamerykanka”.
Jak mierzyć afiliację przy ścieżkach mobile, aplikacje i cross-device?
Przy złożonych ścieżkach nie ma jednego magicznego narzędzia, potrzebny jest zestaw elementów. Podstawą są identyfikatory backendowe: click ID zapisany po stronie serwera oraz user ID (np. ID konta lub klienta w CRM), który łączy zdarzenia z różnych urządzeń i sesji.
W praktyce wykorzystuje się m.in.:
deep linki i przekazywanie click ID do aplikacji mobilnej,
mapowanie user ID po zalogowaniu (telefon → laptop),
tracking serwer‑to‑serwer, który „widzi” zakupy w aplikacji i na wielu urządzeniach.
Mit, że cookies ogarną mobile i cross‑device, dawno nie ma pokrycia w rzeczywistości – tutaj wygrywa integracja po stronie backendu.
Co się dzieje, gdy system afiliacyjny nie „złapie” części konwersji?
Z punktu widzenia reklamodawcy statystyki wyglądają lepiej niż rzeczywistość: rośnie udział sprzedaży „direct” i „organic”, a koszt pozyskania z afiliacji sztucznie spada. Problem w tym, że wydawcy widzą ruch i wiedzą, ile powinni zarobić, bo często mają własne trackery i analitykę serwerową.
Gdy rozjazd między ich danymi a raportami reklamodawcy jest stały, zaufanie do programu spada. Efekt jest prosty: najlepsi partnerzy przerzucają ruch tam, gdzie tracking bez ciasteczek działa lepiej i prowizje są wypłacane za faktyczne konwersje. Strategia „nie trackuje = nie płacę” krótkoterminowo obniża koszty, ale długoterminowo wypala kanał afiliacyjny.
Jakie identyfikatory są kluczowe w nowoczesnym trackingu afiliacyjnym?
Nowoczesny tracking afiliacyjny opiera się na trzech typach ID:
click ID – generowany przy kliknięciu w link; podróżuje przez systemy i musi być zapisany po stronie serwera,
user ID – identyfikator użytkownika po stronie reklamodawcy (konto, CRM), który spina różne sesje i urządzenia,
order/lead ID – identyfikator konkretnej konwersji, używany do deduplikacji i statusów (approved, rejected, canceled).
Bez spójnego powiązania tych warstw nawet najlepsze sztuczki typu fingerprinting czy S2S niewiele dadzą. Mit, że „wystarczy wrzucić piksel konwersji”, był prawdziwy dekadę temu; dziś fundamentem jest porządek w ID i architekturze backendu.
