Śledzenie konwersji na danych first-party: CAPI, konwersje rozszerzone i Consent Mode v2

Piksel skonfigurowany w 2020 roku i od tamtej pory nieruszany pokazuje dziś mniej konwersji, niż faktycznie było. Ograniczenia przeglądarek, blokery reklam i brak zgody na pliki cookie sprawiają, że spora część konwersji w ogóle nie trafia do Google i Meta. Pomiar oparty na danych first-party i wysyłany z serwera pozwala odzyskać część tych danych. Ma to bezpośredni wpływ na stawki, bo automatyczne strategie optymalizują pod konwersje, które widzą.

Gdzie giną Twoje konwersje

Zacznijmy od Chrome’a. Google przez lata zapowiadał wyłączenie plików cookie stron trzecich w tej przeglądarce. W 2024 roku zmienił plan na komunikat, w którym użytkownik miał sam wybrać („user choice”), a w kwietniu 2025 potwierdził, że nie wyłączy tych plików cookie i nie wprowadzi też komunikatu. W Chrome zostają dotychczasowe ustawienia plików cookie. Jeśli Twój plan pomiaru zakładał konkretny termin w Chrome, ten termin już nie obowiązuje.

Problem z utratą danych jednak został, bo nigdy nie zależał od Chrome’a. Intelligent Tracking Prevention (ITP) w Safari całkowicie blokuje pliki cookie stron trzecich i skraca czas życia każdego pliku cookie zapisanego przez JavaScript do siedmiu dni, a w przypadku domen uznanych za trackery do 24 godzin. Firefox domyślnie blokuje pliki cookie stron trzecich. Blokery reklam usuwają piksel Meta i tag Google ze strony, zanim zdążą się uruchomić. W EOG użytkownik, który odmówi zgody, nie generuje w przeglądarce żadnego zdarzenia. Nic z tego nie zależy od planów Google wobec Chrome’a.

W efekcie piksel pokazuje mniej konwersji, niż było naprawdę, i ta różnica nie rozkłada się równo. Jej wielkość zależy od przeglądarki użytkownika i jego decyzji o zgodzie. Z wynikami kampanii nie ma nic wspólnego. To błąd systematyczny. Losowe wahania z czasem się uśredniają, a błąd systematyczny nie, więc algorytmy ustalania stawek uczą się na nim.

Śledzenie w przeglądarce i na serwerze

Zdarzenie konwersji można wysłać na dwa sposoby. Przy śledzeniu po stronie klienta wszystko dzieje się w przeglądarce użytkownika. Piksel Meta i tag Google uruchamiają JavaScript, odczytują pliki cookie i wysyłają zdarzenie do platformy. Wdrożenie jest proste, a dane o wizycie bogate. Kłopot w tym, że przeglądarki, blokery reklam i narzędzia do zarządzania zgodami nakładają swoje ograniczenia właśnie w przeglądarce.

Przy śledzeniu po stronie serwera zdarzenie trafia z Twojej infrastruktury (serwera aplikacji albo kontenera tagów w chmurze, którym zarządzasz) bezpośrednio do API platformy. Nie korzysta z document.cookie, rozszerzenia przeglądarki go nie widzą, a Ty decydujesz, które pola wychodzą z Twojego systemu. Wymaga to jednak pracy programistów: odpowiadasz za endpoint, porządek w danych i utrzymanie całości.

Meta: Conversions API i deduplikacja zdarzeń

Conversions API (CAPI) to bezpośrednie połączenie serwer–serwer między Twoimi systemami a Meta. Wysyła te same zdarzenia co piksel (Purchase, Lead, AddToCart), tylko z serwera, gdzie nie działają blokery reklam ani ograniczenia iOS. Meta zaleca używanie CAPI razem z pikselem.

Przy dwóch źródłach pojawia się problem. Jeśli przeglądarka wyśle Purchase i serwer wyśle ten sam Purchase, Meta może policzyć zakup dwa razy. Zapobiega temu deduplikacja. Według oficjalnej dokumentacji Meta zalecana metoda porównuje dwa pola. eventID z piksela musi być równy event_id z serwera, a event z piksela musi być równy event_name z serwera. Jeśli oba się zgadzają w ciągu 48 godzin od pierwszego zdarzenia, Meta zostawia jedno zdarzenie i odrzuca duplikat.

Z event_id łatwo pomylić dwa inne identyfikatory. fbp to wartość pliku cookie first-party _fbp, który Meta zapisuje w Twojej domenie. fbc powstaje z parametru kliknięcia fbclid i jest zapisywany w pliku cookie _fbc. Oba to parametry dopasowania: pomagają Meta połączyć zdarzenie z konkretną osobą, ale kluczem deduplikacji nie są. W przeciwieństwie do e-maila i telefonu wysyła się je bez haszowania. Meta ma też drugą metodę deduplikacji, opartą na event_name i fbp lub external_id. Działa ona jednak tylko wtedy, gdy zdarzenie z przeglądarki dotrze przed zdarzeniem z serwera. Dlatego domyślnie lepiej używać wspólnego event_id.

Google: konwersje rozszerzone i zahaszowane dane first-party

W Google ten sam problem rozwiązują konwersje rozszerzone. W chwili konwersji pobierają dane, które użytkownik sam Ci podał: e-mail, telefon, imię i nazwisko oraz adres. Normalizują je (małe litery, bez zbędnych spacji) i haszują algorytmem SHA-256, czyli funkcją jednokierunkową, zanim cokolwiek opuści stronę lub Twój serwer. Google porównuje ten hash z hashami zalogowanych kont Google, które miały kontakt z Twoimi reklamami. Dzięki temu przypisuje konwersję nawet wtedy, gdy plik cookie z kliknięcia dawno wygasł.

SHA-256 jest nieodwracalny, więc Google nie widzi adresu e-mail ani numeru telefonu, tylko hash o stałej długości, który może porównać. Konwersje rozszerzone wysyłasz przez tag Google, przez Google Tag Managera albo przez Google Ads API do 24 godzin po zarejestrowaniu konwersji. Przez API łatwo wysyłać je z serwera. Trzeba tylko pilnować normalizacji. Wielka litera albo spacja na końcu adresu daje inny hash i dopasowanie się nie udaje, więc przed haszowaniem zawsze formatuj dane w ten sam sposób.

Consent Mode v2: kiedy tagi mogą się uruchomić

W Europie wszystko to zależy od zgody użytkownika. Od marca 2024 Google wymaga Consent Mode v2 od reklamodawców kierujących reklamy na EOG i Wielką Brytanię, jeśli chcą dalej korzystać z funkcji list odbiorców i pomiaru. Consent Mode przekazuje tagom Google decyzje użytkownika w czterech sygnałach:

• ad_storage: czy można zapisywać reklamowe pliki cookie.
• analytics_storage: czy można zapisywać analityczne pliki cookie.
• ad_user_data: czy dane użytkownika można wysyłać do Google w celach reklamowych, także w ramach konwersji rozszerzonych.
• ad_personalization: czy dane można wykorzystać w remarketingu i reklamach spersonalizowanych.

Consent Mode można wdrożyć na dwa sposoby. W trybie podstawowym tagi są zablokowane, dopóki użytkownik nie wybierze opcji na banerze, więc przed zgodą nic nie jest wysyłane. W trybie zaawansowanym tagi ładują się z domyślnie odrzuconą zgodą i wysyłają pingi bez plików cookie. Pingi nie zawierają identyfikatorów, ale Google wykorzystuje je do modelowania konwersji i modelowania zachowań. W ten sposób szacuje statystycznie konwersje od użytkowników, którzy odmówili zgody. Przy ścisłej konfiguracji w trybie podstawowym tych konwersji w ogóle nie widać.

W trybie zaawansowanym Consent Mode pozwala Google oszacować konwersje od użytkowników, którzy nie wyrazili zgody.

Tagowanie po stronie serwera: jeden kontener dla wszystkich platform

Można osobno dodać CAPI do koszyka, a konwersje rozszerzone do strony z podziękowaniem. To działa, ale kod śledzenia jest wtedy rozrzucony po całej aplikacji. Serwerowy kontener Google Tag Managera zbiera go w jednym miejscu. Przeglądarka wysyła jedno małe żądanie do kontenera na Twojej subdomenie. Kontener przekazuje zdarzenie dalej: do Conversions API Meta, Google Ads, GA4 i innych narzędzi. Haszowanie, wzbogacanie danych i reguły zgód działają na serwerze, gdzie przeglądarka ich nie zablokuje.

Pliki cookie ustawiane w odpowiedzi HTTP z Twojego serwera nie podlegają siedmiodniowemu limitowi, który Safari nakłada na pliki cookie z JavaScriptu, więc okna atrybucji są dłuższe. Dane wrażliwe są haszowane, zanim opuszczą Twoją infrastrukturę. Zgody egzekwujesz w jednym miejscu zamiast osobno w każdym tagu. Minus jest taki, że musisz utrzymywać kontener, czyli zadbać o hosting, monitoring i wersjonowanie.

Jak jakość pomiaru wpływa na stawki

Automatyczne strategie ustalania stawek, czyli Smart Bidding w Google i Advantage+ w Meta, to modele uczone na konwersjach, które do nich wysyłasz. Jeśli raportujesz za mało, algorytm ustala stawki tak, jakby część kampanii, grup odbiorców czy godzin konwertowała gorzej niż w rzeczywistości, i przesuwa z nich budżet. Braki w pomiarze wpływają więc na to, gdzie trafia budżet. Szczegółowo opisujemy to w naszym przewodniku po automatycznych strategiach ustalania stawek.

Kiedy odzyskasz utracone zdarzenia, działa to w drugą stronę. Dokładniejsze, zdeduplikowane konwersje dają algorytmowi więcej danych do nauki, co poprawia targetowanie i obniża koszt działania (CPA). Meta wskazuje tę korzyść przy Conversions API. Opublikowane liczby to potwierdzają, ale pochodzą z badań platform i dostawców, a jednej uznanej wartości nie ma.

Traktuj te wartości orientacyjnie. Wynik zależy od struktury Twojego ruchu: ile wejść pochodzi z Safari, ilu użytkowników nie wyraża zgody i jak dobre są Twoje dane first-party. Platformy optymalizują pod to, co mierzysz. Dlatego najpierw popraw pomiar, a dopiero potem zmieniaj ustawienia stawek.

Wdrożenie pomiaru first-party krok po kroku

Kolejne kroki zależą od poprzednich, więc warto trzymać się tej kolejności:

1. Zbieraj dane first-party w momencie konwersji. Przy zakupie lub wysłaniu formularza zapisuj e-mail, telefon i wartość zamówienia. Na tych danych opiera się każde późniejsze dopasowanie.
2. Uruchom endpoint na serwerze albo kontener sGTM. Zdarzenia powinny trafiać do jednego miejsca po stronie serwera, na subdomenie first-party, i stamtąd być rozsyłane dalej.
3. Wdróż Meta CAPI ze wspólnymi identyfikatorami zdarzeń. Wysyłaj zdarzenia z serwera równolegle z pikselem. Dla każdej akcji twórz jeden event_id i przekazuj go do obu źródeł. Sprawdź deduplikację w Menedżerze zdarzeń.
4. Włącz konwersje rozszerzone w Google Ads. Znormalizuj pola first-party, zahaszuj je algorytmem SHA-256 i wysyłaj przez tag albo przez Google Ads API. Sprawdzaj współczynnik dopasowania w raporcie diagnostycznym.
5. Skonfiguruj Consent Mode v2 (tryb zaawansowany tam, gdzie pozwala na to prawo). Przekazuj wszystkie cztery sygnały z certyfikowanej platformy do zarządzania zgodami (CMP). Wtedy działa modelowanie, a funkcje list odbiorców w EOG są nadal dostępne.
6. Sprawdź dane, potem przekaż je strategiom stawek. Upewnij się, że sumy po deduplikacji wyglądają rozsądnie, i dopiero wtedy pozwól Smart Bidding i Advantage+ uczyć się na odzyskanych danych.

Co robi tu Adriva

Adriva powstała po to, żeby przejąć tę część pracy. Łączy GA4, piksel Meta i tag Google Ads w jedną warstwę danych bez duplikatów i wykorzystuje te dane przy każdej decyzji o budżecie i stawkach. Opisujemy to w tekście o tym, jak Adriva łączy Google Analytics i piksele. Dokładny pomiar na wszystkich platformach pozwala też Adrivie prowadzić Google Ads i Meta Ads w jednym procesie i porównywać wyniki kreacji na podstawie realnego ROAS zamiast niepełnych danych z samego piksela.

Google odwołał termin wyłączenia plików cookie stron trzecich w Chrome, ale przeglądarki nadal gubią konwersje. Zbieraj dane first-party, wysyłaj je z serwera, usuwaj duplikaty i przestrzegaj zgód użytkowników. Wtedy systemy, które wydają Twój budżet, optymalizują pod konwersje, które naprawdę się wydarzyły.