Śledzenie konwersji w świecie first-party: CAPI, konwersje rozszerzone i zgody

Piksel, który skonfigurowałeś w 2020 roku, po cichu Cię okłamuje. Ograniczenia przeglądarek, bramki zgód i blokery reklam połykają dziś istotną część konwersji, zanim dotrą one do platform reklamowych. Odbudowa pomiaru na danych first-party po stronie serwera to sposób na odzyskanie sygnału — i na to, by automatyczne ustalanie stawek nie optymalizowało na podstawie rozmazanego obrazu.

Gdzie naprawdę znikają Twoje konwersje

Zacznijmy od mitu wartego uśmiercenia: apokalipsa ciasteczek third-party, która miała nadejść w Chrome, nigdy nie nastąpiła. Google przez lata obiecywał ich wycofanie, w 2024 roku przestawił się na monit „wyboru użytkownika”, a w kwietniu 2025 potwierdził, że nie wycofa ich ani nie wprowadzi tego monitu w ogóle, zostawiając dotychczasowe ustawienia ciasteczek w Chrome. Jeśli Twój plan pomiarowy był zbudowany wokół deadline’u Chrome’a, tego deadline’u już nie ma.

Utrata sygnału natomiast została. Nigdy tak naprawdę nie chodziło o Chrome. Intelligent Tracking Prevention w Safari już teraz całkowicie blokuje ciasteczka third-party i ogranicza czas życia dowolnego ciasteczka zapisanego przez JavaScript do siedmiu dni — a do 24 godzin dla domen klasyfikowanych jako trackery. Firefox blokuje ciasteczka third-party domyślnie. Blokery reklam usuwają piksel Meta i tag Google ze strony, zanim się odpalą. A w EOG użytkownik odmawiający zgody nie generuje w ogóle żadnego zdarzenia po stronie klienta. Nic z tego nie zależy od roadmapy Google.

Efektem jest piksel, który raportuje mniej konwersji, niż faktycznie zaszło, robi to nierównomiernie i w sposób skorelowany z przeglądarką i decyzją o zgodzie, a nie z wynikami kampanii. To najgorszy rodzaj błędu pomiarowego: nie losowy szum, który da się uśrednić, ale systematyczne obciążenie, na którym Twoje algorytmy licytacyjne z chęcią się nauczą.

Strona klienta i strona serwera, obok siebie

Każde zdarzenie konwersji może pojechać dwiema drogami. Droga po stronie klienta biegnie w przeglądarce odwiedzającego: piksel Meta i tag Google wykonują JavaScript, czytają ciasteczka i wysyłają zdarzenie do platformy. Łatwo ją wdrożyć i jest bogata w kontekst, ale żyje w całości w środowisku, które przeglądarki, blokery reklam i narzędzia zgód są zaprojektowane ograniczać.

Droga po stronie serwerawysyła zdarzenie z Twojej własnej infrastruktury — z serwera aplikacji albo z kontenera tagów w chmurze, który kontrolujesz — bezpośrednio do API platformy. Nie dotyka document.cookie, jest niewidoczna dla rozszerzeń przeglądarki, a Ty decydujesz dokładnie, które pola opuszczają Twój system. Cena jest realna: odpowiadasz za endpoint, higienę danych i utrzymanie.

Meta: Conversions API i deduplikacja zdarzeń

Conversions API (CAPI) Meta tworzy bezpośrednie połączenie serwer–serwer między Twoimi systemami a Meta, wysyłając te same zdarzenia webowe co piksel — Purchase, Lead, AddToCart— ale z Twojego serwera, gdzie blokery reklam i ograniczenia iOS ich nie sięgną. Wytyczne Meta są jednoznaczne: prowadź CAPI obok piksela, a nie zamiast niego.

Prowadzenie obu rodzi oczywisty problem. Jeśli przeglądarka odpali Purchase, a Twój serwer odpali ten sam Purchase, Meta mogłaby policzyć dwa. Deduplikacja jest tym, co temu zapobiega, a mechanizm jest precyzyjny. Zgodnie z oficjalną dokumentacją Meta zalecana metoda porównuje dwa pola: eventID piksela musi być równe event_id z serwera, a event piksela musi być równy event_name z serwera. Gdy oba pasują w ciągu 48 godzin od pierwszego zdarzenia, Meta zachowuje jedno i odrzuca duplikat.

Dwa identyfikatory łatwo pomylić z event_id, choć pełnią inną rolę. fbp to wartość z ciasteczka first-party _fbp, które Meta ustawia w Twojej domenie; fbc pochodzi z parametru kliknięcia fbclid i jest przechowywany w ciasteczku _fbc. To parametry dopasowania— pomagają Meta połączyć zdarzenie z osobą — a nie klucze deduplikacji, i w odróżnieniu od e-maila czy telefonu muszą być wysyłane bez haszowania. Meta oferuje też alternatywną metodę deduplikacji opartą na event_name plus fbp lub external_id, ale działa ona tylko wtedy, gdy zdarzenie z przeglądarki dotrze pierwsze, a serwerowe drugie — dlatego podejście ze wspólnym event_id jest niezawodnym ustawieniem domyślnym.

Google: konwersje rozszerzone i zahaszowane dane first-party

Odpowiedzią Google na ten sam problem są konwersje rozszerzone. Gdy konwersja się odpala, system przechwytuje dane first-party, które użytkownik już Ci przekazał — e-mail, telefon, imię i nazwisko, adres — normalizuje je (małe litery, przycięte spacje) i stosuje SHA-256, funkcję skrótu jednokierunkową, zanim cokolwiek opuści stronę lub Twój serwer. Google otrzymuje skrót, porównuje go ze skrótami zalogowanych kont Google, które miały kontakt z Twoimi reklamami, i przypisuje konwersję nawet wtedy, gdy ciasteczka kliknięcia dawno już nie ma.

Ponieważ SHA-256 jest nieodwracalny, Google nigdy nie widzi surowego e-maila ani numeru telefonu — tylko odcisk o stałej długości, który może porównać. Konwersje rozszerzone możesz wysyłać przez tag Google, przez Google Tag Manager albo przez Google Ads API do 24 godzin po zarejestrowaniu konwersji, co czyni ścieżkę serwerową prostą. Haczyk tkwi w higienie danych: zahaszowanie nieznormalizowanego ciągu daje inny odcisk, więc spójne formatowanie przed haszowaniem jest różnicą między dopasowaniem a pudłem.

Consent Mode v2: warstwa, która decyduje, co się odpala

Nic z tego nie działa w Europie bezwarunkowo. Od marca 2024 Google wymaga Consent Mode v2 od reklamodawców kierujących reklamy na EOG i Wielką Brytanię, by mogli dalej korzystać z funkcji odbiorców i pomiaru. Przekazuje on wybory odwiedzającego do tagów Google przez cztery sygnały:

• ad_storage— czy można ustawiać ciasteczka reklamowe.
• analytics_storage— czy można ustawiać ciasteczka analityczne.
• ad_user_data— czy dane użytkownika mogą trafiać do Google w celach reklamowych, w tym w ramach konwersji rozszerzonych.
• ad_personalization— czy dane mogą zasilać remarketing i reklamy spersonalizowane.

Wybór wdrożenia ma znaczenie. W trybie podstawowym tagi pozostają zablokowane, dopóki użytkownik nie wejdzie w interakcję z bannerem, więc przed zgodą nie wychodzi żaden sygnał. W trybie zaawansowanym tagi ładują się z domyślnie odmówioną zgodą i wysyłają bezciasteczkowe pingi, które nie niosą identyfikatorów, ale pozwalają Google modelować wynik. To modelowanie jest nagrodą: tryb zaawansowany włącza zarówno modelowanie konwersji, jak i modelowanie zachowań, odzyskując statystyczny szacunek konwersji od użytkowników, którzy odmówili — konwersji, których ścisła konfiguracja podstawowa po prostu nigdy nie zobaczy.

Zgoda to nie tylko podatek od zgodności z prawem. Skonfigurowana w trybie zaawansowanym jest kanałem odzysku dokładnie tych konwersji, które zabierają ograniczenia prywatności.

Tagowanie serwerowe: jeden kontener do rozsyłania wszystkiego

Doklejenie CAPI do koszyka i konwersji rozszerzonych do strony podziękowania działa, ale rozsypuje logikę po całej bazie kodu. Serwerowy kontener Google Tag Managera ją centralizuje. Przeglądarka wysyła jedno lekkie żądanie do kontenera działającego na Twojej własnej subdomenie; kontener rozsyła następnie zdarzenie do Conversions API Meta, Google Ads, GA4 i gdziekolwiek indziej — stosując haszowanie, wzbogacanie i reguły zgód po stronie serwera, poza zasięgiem przeglądarki.

Korzyści są konkretne. Ciasteczka ustawiane jako odpowiedź HTTP z Twojego własnego serwera są zwolnione z siedmiodniowego limitu Safari dla JavaScriptu, więc okna atrybucji żyją dłużej. Dane wrażliwe są haszowane, zanim opuszczą Twoją infrastrukturę. I masz jedno miejsce egzekwowania zgód zamiast polityki wdrażanej od nowa w każdym tagu. Kosztem jest to, że utrzymujesz teraz kontener — wraz z hostingiem, monitoringiem i wersjonowaniem.

Dlaczego jakość sygnału to jakość licytacji

Oto część, którą operatorzy niedoważają. Automatyczne ustalanie stawek — Smart Bidding w Google, Advantage+ w Meta — to model trenowany na konwersjach, którymi go karmisz. Raportuj za mało, a algorytm będzie licytował tak, jakby te kampanie, grupy odbiorców i godziny konwertowały gorzej, niż w rzeczywistości, a potem odetnie im budżet. Luka pomiarowa nie tylko zniekształca raporty; kieruje wydatki w złą stronę. Mechanikę tej pętli sprzężenia rozbieramy w naszym przewodniku po automatycznych strategiach ustalania stawek.

Odzyskanie utraconych zdarzeń odwraca tę pętlę. Dokładniejsze, zdeduplikowane konwersje oznaczają więcej pozytywnego sygnału treningowego, co wyostrza targetowanie i obniża koszt działania — dokładnie tę korzyść Meta wskazuje przy Conversions API. Raportowane liczby to potwierdzają, z zastrzeżeniem, że pochodzą z badań platform i dostawców, a nie z jednej kanonicznej wartości.

Traktuj te procenty jako kierunek, a nie obietnicę — realna liczba zależy od miksu Twojego ruchu, od tego, jaka jego część to Safari i użytkownicy za bramką zgód, oraz od czystości Twoich danych first-party. Zasada obowiązuje niezależnie: platformy optymalizują w stronę tego, co mierzysz, więc mierzenie większej części prawdy jest najsilniejszą rzeczą, jaką możesz zrobić, zanim dotkniesz choćby jednego ustawienia stawek.

Odbudowa pomiaru first-party, po kolei

Elementy wzmacniają się nawzajem, więc kolejność ma znaczenie. Zgrubna ścieżka wdrożenia:

1. Zbieraj dane first-party przy konwersji.Przechwyć e-mail, telefon i wartość zamówienia przy zakupie lub wysłaniu formularza — to surowiec, od którego zależy każde późniejsze dopasowanie.
2. Postaw endpoint serwerowy lub kontener sGTM. Zapewnij sobie jedno miejsce po stronie serwera, które odbiera zdarzenia i je rozsyła, na subdomenie first-party.
3. Spinaj Meta CAPI ze wspólnymi identyfikatorami zdarzeń. Wysyłaj zdarzenia serwerowe obok piksela, generując jeden event_id na akcję i przekazując go do obu. Zweryfikuj deduplikację w Menedżerze zdarzeń.
4. Włącz konwersje rozszerzone Google. Znormalizuj, a potem zahaszuj pola first-party algorytmem SHA-256 i przekaż je tagiem albo przez Google Ads API. Obserwuj raport diagnostyczny pod kątem wskaźnika dopasowań.
5. Skonfiguruj Consent Mode v2 (zaawansowany tam, gdzie jest to dozwolone). Przekazuj wszystkie cztery sygnały z certyfikowanej platformy zgód, żeby modelowanie mogło działać, a funkcje odbiorców w EOG nadal działały.
6. Uzgodnij dane, a potem podaj czysty sygnał licytacji. Sprawdź, czy zdeduplikowane sumy mają sens, a potem pozwól Smart Biddingowi i Advantage+ trenować na odzyskanych danych.

Gdzie w tym wszystkim jest Adriva

To dokładnie ta hydraulika, którą ma przejąć Adriva. Scala GA4, piksel Meta i tag Google Ads w jedną zdeduplikowaną warstwę sygnału, a potem oddaje te czyste dane z powrotem do każdej decyzji budżetowej i licytacyjnej — to połączenie opisujemy w tekście o tym, jak Adriva łączy Google Analytics i piksele. Dokładny pomiar między platformami jest też tym, co pozwala Adrivie prowadzić Google Ads i Meta Ads z jednego procesu i porównywać wyniki kreacji na realnym ROAS-ie zamiast na częściowym obrazie, jaki dałby przeciekający piksel.

Wniosek jest bezlitosny: deadline dla ciasteczek third-party wyparował, ale utrata sygnału nie. Odbuduj pomiar na danych first-party, wysyłaj je po stronie serwera, deduplikuj uczciwie i szanuj zgody — a automatyczne systemy wydające Twój budżet wreszcie będą optymalizować względem tego, co naprawdę się wydarzyło.