Atrybucja bez ciasteczek: co nadal działa w 2026 roku

Stos atrybucji marketingowej, który większość zespołów zbudowała między 2012 a 2019 rokiem, opierał się na dwóch rzeczach: ciasteczku third-party ustawianym przez platformę reklamową na stronie docelowej oraz pikselu przeglądarki, który uruchamiał się na stronie konwersji i dopasowywał z powrotem do tego ciasteczka. Oba elementy tej pary są teraz zdegradowane. Żaden z nich nie wróci do dawnej formy.

Ten artykuł nie jest lamentem nad ciasteczkiem. Jest mapą tego, co naprawdę działa w 2026 roku - które ścieżki atrybucji przetrwały, które były sprzedawane jako rozwiązania, nie będąc nimi w rzeczywistości, oraz jak wygląda działający stos w praktyce dla zespołów prowadzących płatne kampanie na ruch z UE.

TL;DR#

• Apple's ITP 2.3, Firefox Enhanced Tracking Protection i trwające wycofywanie trzecich ciasteczek przez Chrome sprawiają razem, że 60–70% europejskiego ruchu internetowego domyślnie blokuje lub poważnie ogranicza ciasteczka third-party.
• Dwie ścieżki atrybucji nadal działają: identyfikatory po stronie serwera przekazywane przez click ID oraz ustawianie ciasteczek first-party przez łańcuch przekierowań kontrolowany przez Twoją domenę.
• Atrybucja bez ciasteczek nie oznacza atrybucji bez zgody. Dyrektywa ePrivacy 2002/58/WE oraz RODO nadal wymagają zgody na niebędące koniecznością analytics, niezależnie od mechanizmu przechowywania danych.
• Probabilistyczne łączenie odcisków cyfrowych (fingerprinting) nie jest zgodnym z przepisami rozwiązaniem zastępczym w UE; deterministyczne dopasowanie hashu e-mail w połączeniu z serwerowym click ID to jedyne podejście, które wytrzymuje zarówno wymogi dokładności, jak i kontrolę regulacyjną.

Co się zmieniło: krótka oś czasu#

Safari zaczęło ograniczać ciasteczka third-party w 2017 roku wraz z ITP 1.0. Ograniczenia szybko się zaostrzały. ITP 2.3, wydany we wrześniu 2019 roku, ograniczył żywotność ciasteczek first-party ustawianych przez skrypty do siedmiu dni, a do dwudziestu czterech godzin, gdy łańcuch odesłań zawierał znany tracker cross-site. Sama ta zmiana zniszczyła standardowy mechanizm przekazywania click ID do ciasteczka, na którym polegała większość dostawców atrybucji.

Enhanced Tracking Protection Firefoksa wprowadził Total Cookie Protection dla wszystkich użytkowników w 2022 roku, partycjonując każde ciasteczko third-party według witryny najwyższego poziomu. Ciasteczko ustawione przez pixel.example.com na Twojej stronie kasy i na stronie kasy konkurenta to teraz dwa zupełnie osobne ciasteczka - korelacja cross-site jest z założenia niemożliwa.

Harmonogram Chrome przesuwał się wielokrotnie od czasu ogłoszenia przez Google w 2019 roku. Aktualne stanowisko, udokumentowane na stronie Privacy Sandbox (dostęp 2026-05-12), zakłada kontynuację wycofywania dla podzbioru użytkowników, przy czym pełne wdrożenie jest nadal w toku. Niezależnie od ostatecznej daty Chrome, sytuacja w UE jest już rozstrzygnięta: Safari i Firefox razem obsługują większość mobilnego i świadomego na prywatność ruchu desktopowego na rynkach europejskich. Strategie atrybucji wymagające ciasteczek third-party są już zepsute dla znacznej części Twoich europejskich odbiorców.

Łączny efekt zmierzony na typowych kontach performance marketingowych w UE: atrybucja piksela po stronie przeglądarki niedoliczy konwersji o 25–45%, w zależności od miksu ruchu, przy czym branże z dużym udziałem iOS (moda, beauty, aplikacje, subskrypcje) plasują się w górnej części tego przedziału.

Dwie ocalałe ścieżki atrybucji#

Ścieżka 1: identyfikatory po stronie serwera#

Podstawowy mechanizm jest prosty. Gdy użytkownik kliknie Twoją reklamę, platforma reklamowa dołącza identyfikator kliknięcia do URL strony docelowej - fbclid dla Meta, gclid dla Google itd. Ten identyfikator istnieje w URL, nie w ciasteczku, więc ITP i partycjonowanie ciasteczek go nie dotykają.

Twoja strona docelowa odczytuje click ID z URL i zapisuje go w ciasteczku first-party na Twojej własnej domenie albo przekazuje go dalej do koszyka, a ostatecznie do rekordu zamówienia. Gdy użytkownik dokonuje konwersji, Twój backend odczytuje click ID z zamówienia i wysyła zdarzenie konwersji serwer-do-serwera do API konwersji platformy reklamowej - Meta Conversions API, GA4 Measurement Protocol, serwerowy endpoint zdarzeń Mixpanel.

Ta ścieżka działa, ponieważ nigdy nie korzysta z ciasteczek third-party. Click ID jest w ciągu zapytań URL w momencie lądowania. Twoje ciasteczko first-party na Twojej domenie nie jest ograniczane przez ITP w taki sam sposób jak ciasteczka third-party (choć podlega 7-dniowemu ograniczeniu dla ciasteczek ustawianych skryptami, jeśli łańcuch odesłań jest podejrzany - więcej o tym poniżej). Zdarzenie konwersji przepływa serwer-do-serwera, całkowicie poza przeglądarką.

Słabe punkty są realne. Jeśli użytkownik wyczyści ciasteczka między lądowaniem a konwersją, click ID zniknie. Jeśli konwersja nastąpi na innym urządzeniu, nie ma połączenia cross-device, chyba że masz zalogowanego użytkownika z wypełnionym adresem e-mail. A iOS 17 wprowadził Link Tracking Protection w Przeglądaniu Prywatnym i Mail, który usuwa znane parametry click ID z URL - fbclid, gclid, msclkid są na liście usuwanych. Użytkownik trafiający przez aplikację Mail z włączoną ochroną przed śledzeniem linków w ogóle nie przeniesie click ID na Twoją stronę.

Ścieżka 2: łańcuch przekierowań first-party#

Druga ocalała ścieżka wykorzystuje przekierowanie, które kontrolujesz, jako powierzchnię atrybucji. Zamiast click ID platformy reklamowej generujesz własny trwały identyfikator w momencie przekierowania na Twojej domenie.

Gdy użytkownik kliknie link na Twojej domenie - niezależnie od tego, czy to krótki link, przekierowanie strony docelowej kampanii, czy markowy deep link - handler przekierowania na Twoim edge uruchamia się zanim zaczną obowiązywać ograniczenia prywatności przeglądarki. Może on:

1. Ustawić ciasteczko first-party z serwerowo wygenerowanym click ID na Twojej domenie.
2. Dołączyć click ID jako parametr URL do docelowego URL.
3. Zalogować zdarzenie kliknięcia po stronie serwera z pełnym kontekstem technicznym (IP, user-agent, referrer, timestamp) w momencie kliknięcia, a nie w momencie załadowania strony.

Ponieważ to Twoja domena i Twoje serwerowe ciasteczko, leży ono poza ograniczeniami ciasteczek third-party, które ITP atakuje. Ciasteczko jest ustawiane przez Twój serwer za pomocą nagłówka odpowiedzi Set-Cookie w odpowiedzi na przekierowanie - ciasteczka ustawiane przez serwer nie podlegają 7-dniowemu ograniczeniu ITP, które dotyczy zapisów document.cookie z JavaScriptu.

To jest ta powierzchnia atrybucji, którą zapewnia skracacz URL, a której piksel przeglądarki nie może zapewnić. Przekierowanie rozwiązuje się na domenie skracacza. Jeśli ta domena to Twoja własna domena z brandingiem, Twój click ID jest first-party, ustawiony serwerowo i architektonicznie umieszczony przed jakimkolwiek ograniczeniem prywatności po stronie przeglądarki.

Jak krótki link staje się powierzchnią atrybucji#

Przepływ przekierowania wygląda następująco. Docelowy URL Twojej reklamy to markowy krótki link - na przykład go.acme.example/letnia-wyprzedaz. Użytkownik klika. Żądanie przekierowania trafia do edge handlera Elido, który:

• Wyszukuje docelowy URL.
• Generuje identyfikator elido_click i loguje zdarzenie kliknięcia po stronie serwera.
• Ustawia first-party Set-Cookie: elido_click=<id>; Domain=go.acme.example; SameSite=Lax; Secure; Max-Age=604800 w odpowiedzi na przekierowanie.
• Dołącza ?elido_click=<id> do docelowego URL przed przekazaniem.

Strona docelowa otrzymuje click ID w ciągu zapytań. Twój tag manager lub kod motywu odczytuje go i przechowuje na rekordzie koszyka lub zamówienia. Gdy nastąpi konwersja, wysyłasz POST do POST /v1/conversions z click ID i szczegółami zamówienia - Elido obsługuje haszowanie SHA-256 identyfikatorów klientów oraz serwerowy fan-out do Meta CAPI, GA4 Measurement Protocol i Mixpanel.

Click ID nigdy nie żył w ciasteczku third-party. Był ustawiany serwerowo, first-party, zalogowany zanim warstwa prywatności przeglądarki miała szansę interweniować. Pełną mechanikę serwerowego kroku przekazywania omawia artykuł śledzenie konwersji po stronie serwera przez krótkie linki, który szczegółowo opisuje deduplikację, wymagania dotyczące haszowania i semantykę ponownych prób.

Szersze zagadnienie tego, jak ITP konkretnie degraduje atrybucję kliknięć i co robi z tym łańcuch przekierowań przez krótki link, omawia artykuł atrybucja kliknięć po Safari ITP, który jest operacyjnym uzupełnieniem tego tekstu.

Łączenie tożsamości: co działa, a co nie#

Serwerowe click ID rozwiązują problem atrybucji dla użytkowników, którzy klikają link i dokonują konwersji w tej samej sesji przeglądarki na tym samym urządzeniu, bez czyszczenia ciasteczek, bez usuwania parametru przez link tracking protection. To nadal pokrywa większość konwersji e-commerce. Ale nie pokrywa wszystkiego, a metody stosowane przez zespoły do wypełnienia pozostałej luki różnią się znacznie zarówno pod względem dokładności, jak i ekspozycji prawnej.

Dopasowanie deterministyczne działa. Jeśli użytkownik jest zalogowany lub podaje swój adres e-mail w dowolnym momencie lejka (przechwytywanie e-maila, zapis do newslettera, kasa), możesz zahaszować ten adres e-mail z SHA-256 i dołączyć go do zdarzenia konwersji. Meta CAPI, GA4 i Mixpanel akceptują zahaszowany e-mail jako sygnał dopasowania obok lub zamiast click ID. Wskaźnik dopasowania dla ruchu ze znanych e-maili jest wysoki - Meta wewnętrznie raportuje wskaźniki dopasowania powyżej 90%, gdy obecny jest znormalizowany, zahaszowany e-mail. To jest podstawowy mechanizm łączenia tożsamości, który przetrwa wycofanie ciasteczek w nienaruszonym stanie.

Istotne jest tutaj parowanie deduplikacji. Każde zdarzenie konwersji potrzebuje event_id (dla Meta) lub transaction_id (dla GA4), który jest identyczny między pikselem po stronie przeglądarki a wysyłką po stronie serwera. Bez tego oba zdarzenia są wczytywane i konwersja jest liczona podwójnie. Identyfikator zamówienia jest standardowym kluczem deduplikacji dla zdarzeń zakupu.

Probabilistyczny fingerprinting nie działa - i nie jest legalny w UE. Fingerprinting przeglądarki tworzy unikalny identyfikator z kombinacji rozdzielczości ekranu, zainstalowanych czcionek, strefy czasowej, user-agenta, canvas rendering fingerprint i podobnych sygnałów. Identyfikator jest probabilistyczny - przypisuje dopasowanie z wysoką pewnością między dwoma zdarzeniami bez wspólnego ciasteczka lub loginu. Niektórzy dostawcy atrybucji oferują to jako rozwiązanie "cookieless measurement".

W UE podejście to ma konkretny problem prawny. Dyrektywa ePrivacy 2002/58/WE, Artykuł 5(3), wymaga zgody na dostęp do informacji przechowywanych na urządzeniu końcowym użytkownika lub na ich przechowywanie. Stanowisko EROD, powtarzane w kilku decyzjach organów nadzorczych od 2022 roku, jest takie, że fingerprinting mieści się w zakresie Artykułu 5(3) niezależnie od tego, czy identyfikator jest technicznie "ciasteczkiem". Austriacki DSB, francuskie CNIL i włoski Garante wydały każde z nich decyzje egzekucyjne w sprawie fingerprintingu bez zgody. Argument "nie używamy ciasteczek, używamy fingerprintingu" nie jest argumentem za zgodnością z przepisami; to argument, który przyciąga bliższe badanie.

Nawet poza ekspozycją prawną, probabilistyczny fingerprinting degraduje się pod względem dokładności, gdy entropia przeglądarki maleje. Nowoczesne przeglądarki skupione na prywatności aktywnie obniżają entropię poprzez normalizację wyjścia canvas i ograniczanie rozdzielczości API czasu. Jakość sygnału spada dokładnie w tej populacji - świadomych prywatności, z dużym udziałem iOS - gdzie najbardziej potrzebne są dokładne pomiary.

Łączenie cross-device przez CRM to pozostała luka. Dla użytkowników, którzy dokonują konwersji na innym urządzeniu niż to, na którym kliknęli, deterministyczne dopasowanie e-mail to jedyne podejście, które działa. Jeśli użytkownik jest zalogowany na obu urządzeniach, user ID jest łącznikiem. Jeśli nie jest zalogowany, click ID na urządzeniu A i konwersja na urządzeniu B nie mogą być połączone bez dobrowolnego podania przez użytkownika identyfikatora (e-mail, telefon), który można zahaszować i dopasować. Tej luki nie można zamknąć po stronie serwera. To realne ograniczenie atrybucji w świecie bez ciasteczek.

Nakładka compliance#

Ujęcie "atrybucji bez ciasteczek" może wprowadzać w błąd, sugerując, że ponieważ nie jest ustawiane żadne ciasteczko, zgoda nie jest wymagana. Nie to mówi prawo.

Dyrektywa ePrivacy 2002/58/WE, Artykuł 5(3), ma zastosowanie do każdego przechowywania lub dostępu do informacji na urządzeniu końcowym użytkownika - nie tylko do ciasteczek. Ciasteczko first-party ustawiane w celach analitycznych wymaga tej samej zgody co ciasteczko third-party ustawiane w celach śledzenia, jeśli to ciasteczko nie jest niezbędne. Serwerowe ciasteczko click ID opisane powyżej jest zbliżone do analytics; może, ale nie musi wymagać zgody w zależności od oceny celu przez Twojego administratora danych i obowiązującej krajowej implementacji Dyrektywy.

Co podejście serwerowe robi - i to jest jego prawdziwa przewaga compliance - to przeniesienie przetwarzania z urządzenia użytkownika na serwer. Dziennik zdarzeń kliknięcia, przekazywanie zdarzenia konwersji, łączenie tożsamości: wszystko to dzieje się w Twoim backendzie i backendzie Elido, nie w skrypcie przeglądarki. Oznacza to, że blokery reklam nie przechwytują ich, funkcje prywatności przeglądarki ich nie partycjonują, a postawa minimalizacji danych jest kontrolowana przez Ciebie, a nie zależna od tego, co zdecyduje się wysłać tag third-party.

Kwestia podstawy prawnej RODO jest oddzielna od kwestii ePrivacy. Nawet przy atrybucji po stronie serwera potrzebujesz podstawy prawnej wynikającej z Artykułu 6 RODO do przetwarzania danych o kliknięciach dotyczących zidentyfikowanych podmiotów z UE. W przypadku analytics na poziomie kampanii większość administratorów opiera to na uzasadnionym interesie zgodnie z Artykułem 6(1)(f) po przeprowadzeniu Oceny Uzasadnionego Interesu. Dla profilowania na poziomie indywidualnym lub retargetingu podstawa jest trudniejsza. Cornerstone RODO dla skracaczy URL szczegółowo omawia analizę Artykułów 6, 28 i 30; podsumowanie tutaj jest takie, że cookieless ≠ consentless, a nakładka compliance nie znika dlatego, że zmienił się mechanizm przechowywania.

Domyślne ustawienia zdarzeń kliknięć Elido odzwierciedlają postawę minimalizacji danych: adresy IP są skracane do /24 (IPv4) przed utrwaleniem, pełne ciągi user-agent są parsowane i usuwane. Pełna rozdzielczość danych jest dostępna per workspace, jeśli Twój przypadek użycia tego wymaga, ale domyślne jest ustawienie konserwatywne. Ma to znaczenie w rozmowie na temat aneksu DPA z Twoimi nabywcami. Więcej na temat tej rozmowy znajdziesz w solutions/marketers, który omawia punkty kontaktowe w procesie zakupowym dla zespołów marketingowych.

Co tracisz#

Uczciwe rozliczenie ma znaczenie. Serwerowa atrybucja bez ciasteczek odzyskuje większość sygnału utraconego z powodu degradacji po stronie przeglądarki, ale nie odzyskuje go w całości.

Tożsamość cross-device w czasie rzeczywistym. Jak wspomniano powyżej: jeśli użytkownik kliknie na urządzeniu mobilnym i dokona konwersji na desktopie bez zdarzenia logowania łączącego oba, atrybucja jest utracona. Nie ma zgodnego z przepisami serwerowego rozwiązania tego problemu. Luka jest strukturalna.

Precyzyjna atrybucja view-through. Atrybucja view-through - zaliczanie kampanii konwersji, która nastąpiła po wyświetleniu reklamy, nie po kliknięciu - wymaga od platformy reklamowej dopasowania użytkownika w obu zdarzeniach. Serwerowe API konwersji dobrze obsługują atrybucję opartą na kliknięciach; atrybucja view-through zależy od własnego grafu cross-device platformy, który sam degraduje się proporcjonalnie do utraty sygnału. Spodziewaj się, że raportowanie view-through będzie bardziej zaszumione i mniej wiarygodne niż liczby oparte na kliknięciach.

Długie okna lookback. Większość serwerowych endpointów API konwersji narzuca ograniczenia lookback na to, jak daleko wstecz kliknięcie może być przypisane do konwersji. Standardowy lookback Meta CAPI wynosi 7 dni dla click-through. GA4's Measurement Protocol ma okno atrybucji, które różni się w zależności od kanału. Te ograniczenia są krótsze niż 28-dniowe lub 90-dniowe okna, z których korzystały niektóre zespoły w świecie opartym na ciasteczkach. Produkty subskrypcyjne i rozważne zakupy z długimi cyklami badawczymi zobaczą więcej konwersji poza oknem atrybucji.

Dominacja last-click. Bez wielodotykowego grafu tożsamości, serwerowa atrybucja domyślnie stosuje last-click - najbardziej aktualny click ID w łańcuchu otrzymuje uznanie. Dla kampanii budowania świadomości marki, które generują asystowane konwersje przez długi okres, serwerowa atrybucja last-click będzie systematycznie niedowartościowywać wydatki na górze lejka. Mitygacją jest łączenie CRM przez zahaszowany e-mail: jeśli e-mail każdego zalogowanego użytkownika jest w każdym zdarzeniu konwersji, możesz zrekonstruować wielodotykową sekwencję dla zalogowanej części Twojej publiczności. Dla anonimowych użytkowników last-click to sufit.

Praktyczny stos#

Biorąc pod uwagę powyższe ograniczenia, oto stos atrybucji, który działa dla zespołu performance marketingowego obsługującego ruch z UE w 2026 roku.

Click ID z krótkich linków jako punkt wejścia. Wszystkie docelowe adresy reklam to markowe krótkie linki na Twojej domenie. Przekierowanie ustawia serwerowe ciasteczko first-party i dołącza click ID do docelowego URL. Daje to trwały, serwerowo ustawiony identyfikator, który przeżywa ITP i partycjonowanie ciasteczek przez czas trwania sesji.

Podłączenie koszyka i zamówienia. Click ID jest zapisywany do atrybutu koszyka przy załadowaniu strony (z parametru URL lub ciasteczka first-party). Przy tworzeniu zamówienia click ID jest w niestandardowych atrybutach zamówienia. To jest trwałe przekazanie - po umieszczeniu click ID w zamówieniu nie wygasa.

Serwerowe CAPI do Meta. Po opłaceniu zamówienia Twój backend (lub funkcja przekazywania konwersji) wysyła POST do Meta CAPI z click ID, zahaszowanym SHA-256 e-mailem i identyfikatorami fbc/fbp z ciasteczek first-party. event_id to identyfikator zamówienia, pasujący do piksela po stronie przeglądarki. Meta deduplikuje w 48-godzinnym oknie dopasowania.

Serwerowy Measurement Protocol do GA4. Jednocześnie wysyłane jest serwerowe zdarzenie GA4 z transaction_id równym identyfikatorowi zamówienia. client_id to wartość ciasteczka GA4 _ga, jeśli jest dostępna, lub click ID jako fallback. GA4 deduplikuje na podstawie transaction_id w oknie sesji.

Łączenie hashy e-maili z CRM. Dla każdej konwersji, w której brakuje click ID (organiczne, bezpośrednie, wyszukiwanie marki), zahaszowany adres e-mail jest sygnałem atrybucji. To wypełnia segment "znanych użytkowników" Twojej atrybucji i wspiera podstawową rekonstrukcję wielodotykową dla zalogowanych klientów.

Import konwersji offline dla długich lookbacków. Dla produktów subskrypcyjnych lub pipeline'ów B2B, gdzie konwersja następuje tygodnie po kliknięciu, import konwersji offline przez wsadowe API platformy (Meta Conversions API offline events, Google Ads offline conversions) pozwala wysyłać zdarzenia atrybucji poza oknem lookback w czasie rzeczywistym. Kluczem dopasowania jest nadal zahaszowany e-mail lub telefon; okno czasowe jest rozszerzone. To nie rozwiązuje anonimowej atrybucji długiego cyklu, ale zamyka pętlę dla tej części Twojej publiczności, która podała adres e-mail.

Opisany powyżej stos nie wymaga CDP. Wymaga skracacza URL, który generuje i utrwala serwerowe click ID, backendu, który przeprowadza click ID przez do zamówienia, oraz warstwy przekazywania konwersji, która obsługuje haszowanie i fan-out API. Aby zapoznać się z techniczną implementacją warstwy fan-out, artykuł śledzenie konwersji po stronie serwera przez krótkie linki zawiera kształty payloadów, mechanikę deduplikacji i semantykę ponownych prób. Informacje o tym, jak to wpisuje się w pełny workflow UTM kampanii, znajdziesz w solutions/marketers.

Wersja tego stosu, która nie działa: taka, która polega na własnym grafie cross-device platformy reklamowej do rozwiązywania tożsamości, ma nadzieję, że użytkownicy iOS mają włączone App Tracking Transparency w sposób korzystny dla Twoich pomiarów, lub używa probabilistycznego fingerprintingu do wypełniania luk. Pierwsza jest poza Twoją kontrolą. Druga to pobożne życzenie. Trzecia to odpowiedzialność compliance w UE.

Pracuj z tym, co działa.