Od kiedy Safari skraca życie ciasteczek pierwszej strony do 7 dni, a iOS pyta użytkownika o zgodę na śledzenie, sam piksel Meta widzi tylko część konwersji. Conversions API Meta (CAPI) domyka tę lukę: zdarzenia trafiają z serwera sklepu prosto do Meta, z pominięciem przeglądarki i jej blokad. Poniżej opisujemy, jak podzielić role między piksel i CAPI, które parametry dopasowania realnie podnoszą jakość sygnału i jak sprawdzić w Menedżerze zdarzeń, czy algorytm dostaje dane, na których może się uczyć.
W skrócie
- Piksel traci zdarzenia przez blokery, ITP w Safari, ATT na iOS i zamknięcie karty przed załadowaniem skryptu; CAPI wysyła te same zdarzenia z serwera.
- Oba źródła mają działać równolegle, a nie zamiennie: piksel dostarcza
fbp,fbci kontekst przeglądarki, serwer dostarcza kompletność. - Deduplikacja opiera się na parze
event_name+event_id; bez identycznego identyfikatora po obu stronach zakup policzy się dwa razy. - O jakości decyduje liczba i poprawność parametrów
user_data: zahaszowany e-mail, telefon,external_id, adres IP i user agent. - Wynik dopasowania (EMQ) w skali 0–10 poniżej 6 oznacza, że optymalizacja pracuje na okrojonej próbce.
Skąd bierze się luka w danych o konwersjach
Piksel Meta to skrypt JavaScript, który uruchamia się w przeglądarce użytkownika. Każdy mechanizm, który ogranicza JavaScript lub ciasteczka, obcina sygnał zanim dotrze do Meta. W 2026 roku działają jednocześnie cztery takie mechanizmy.
Pierwszy to Intelligent Tracking Prevention w Safari, które ogranicza żywotność ciasteczek zapisywanych przez skrypt do 7 dni, a przy wejściu z linku z parametrem śledzącym do 24 godzin. Ciasteczko _fbp, na którym piksel opiera rozpoznanie użytkownika, znika więc szybciej niż trwa typowy cykl decyzyjny. Drugi to App Tracking Transparency na iOS: użytkownik, który odmówi zgody w aplikacji Facebooka lub Instagrama, nie zostanie powiązany z kliknięciem w reklamę.
Trzeci mechanizm to blokery treści i tryby prywatne w Firefoksie oraz Brave, które w ogóle nie ładują skryptu fbevents.js. Czwarty jest prozaiczny: użytkownik zamyka stronę podziękowania, zanim skrypt wyśle żądanie. Efekt: Meta widzi mniej zakupów niż sklep, a algorytm optymalizuje pod niepełny obraz. Po stronie Google działa ta sama mechanika, którą opisujemy w tekście o tym, dlaczego GA4 pokazuje mniej konwersji niż Google Ads.
Piksel i Conversions API: podział ról
Conversions API nie zastępuje piksela, tylko go uzupełnia. Oba kanały wysyłają zdarzenia do tego samego zestawu danych (dawniej: piksela), ale każdy niesie inny rodzaj informacji.
| Cecha | Piksel (przeglądarka) | Conversions API (serwer) |
|---|---|---|
| Źródło zdarzenia | Skrypt na stronie | Backend sklepu, GTM server-side lub CAPI Gateway |
| Podatność na blokery i ITP | Wysoka | Brak (żądanie HTTPS z serwera) |
Identyfikatory przeglądarki (fbp, fbc) | Ustawia je i wysyła automatycznie | Trzeba je odczytać z ciasteczek i przekazać ręcznie |
| Dane klienta (e-mail, telefon) | Tylko przez zaawansowane dopasowanie | Pełne, z bazy sklepu, zahaszowane SHA-256 |
| Zdarzenia poza stroną (zwrot, płatność offline, lead z CRM) | Niemożliwe | Możliwe, action_source inny niż website |
| Opóźnienie | Natychmiast | Do 7 dni od event_time |
Praktyczny podział wygląda tak: piksel obsługuje zdarzenia wczesne w lejku (PageView, ViewContent, AddToCart), a CAPI dubluje te same zdarzenia i dodatkowo wysyła Purchase z serwera, gdzie zamówienie jest potwierdzone, a nie tylko wyświetlone. W kampaniach Advantage+ shopping ta różnica waży najbardziej, bo algorytm dostaje pełną kontrolę i jakość sygnału jest jedynym, co można mu dać.
Parametry dopasowania i jakość zdarzeń
Meta łączy zdarzenie z kontem użytkownika na podstawie pól w obiekcie user_data. Im więcej poprawnie sformatowanych pól, tym większa szansa na dopasowanie, a więc na przypisanie konwersji do reklamy. Dokumentacja Meta wymienia komplet parametrów wraz z regułami normalizacji (opis w dokumentacji Conversions API).
| Parametr | Klucz | Haszowanie | Uwagi |
|---|---|---|---|
em | SHA-256 | Małe litery, bez spacji; najsilniejszy pojedynczy sygnał | |
| Telefon | ph | SHA-256 | Tylko cyfry z kodem kraju, np. 48600100200 |
| Imię, nazwisko | fn, ln | SHA-256 | Małe litery, bez znaków diakrytycznych i interpunkcji |
| Miasto, kod, kraj | ct, zp, country | SHA-256 | Kraj jako dwuliterowy kod ISO, małe litery |
| ID klienta | external_id | Zalecane | ID użytkownika w sklepie; ten sam po stronie piksela |
| Adres IP, user agent | client_ip_address, client_user_agent | Nie | Wymagane przy action_source: website |
| Identyfikatory Meta | fbp, fbc | Nie | Odczyt z ciasteczek _fbp i _fbc |
Najczęstszy błąd wdrożeniowy to wysyłanie zdarzeń serwerowych bez fbp i fbc. Serwer ich nie zna, dopóki front nie przekaże wartości ciasteczek razem z formularzem lub zamówieniem. Bez tych pól zdarzenie z CAPI dopasowuje się wyłącznie po danych osobowych, a więc wcale, gdy gość podał e-mail, którego nie używa na Facebooku.
Drugi błąd to niepoprawna normalizacja przed haszowaniem. Hasz z „Jan.Kowalski@Example.com” nie zgadza się z haszem z „jan.kowalski@example.com”, więc Meta traktuje je jak dwie różne osoby. Normalizację trzeba wykonać przed SHA-256, po stronie serwera, według reguł z dokumentacji, a nie własnych.
Deduplikacja zdarzeń krok po kroku
Skoro piksel i serwer wysyłają to samo zdarzenie, Meta musi wiedzieć, że to jeden zakup. Mechanizm jest prosty, ale wymaga dyscypliny po obu stronach.
- Generujcie unikalny identyfikator zdarzenia w momencie jego powstania, na przykład numer zamówienia dla
Purchasealbo UUID dlaAddToCart. - Przekażcie ten sam identyfikator do piksela jako
eventIDw wywołaniufbq('track', 'Purchase', {...}, {eventID: '12345'}). - Wyślijcie go z serwera jako
event_idw ładunku Conversions API razem z identyczną nazwą zdarzeniaevent_name. - Upewnijcie się, że oba zdarzenia dotrą w ciągu 48 godzin; po tym czasie Meta nie łączy duplikatów.
- Sprawdźcie w Menedżerze zdarzeń, w zakładce zdarzenia i szczegóły, czy przy zdarzeniach serwerowych pojawia się informacja o zdeduplikowanych zdarzeniach z przeglądarki.
Wdrożenie na WordPressie i w sklepie
Do wyboru są trzy ścieżki, różniące się kontrolą i nakładem pracy.
Wtyczka Meta dla WordPressa lub WooCommerce
Oficjalna wtyczka Meta (dawniej Facebook for WordPress) po połączeniu konta włącza piksel i CAPI jednocześnie, z gotową deduplikacją i podstawowym zaawansowanym dopasowaniem. Zaletą jest zerowy kod; wadą, że zdarzenia niestandardowe i pola user_data spoza formularza zamówienia trzeba dokładać samodzielnie.
Conversions API Gateway
Gateway to hostowana przez Meta instancja pośrednicząca, konfigurowana w Menedżerze zdarzeń bez ingerencji w kod. Piksel wysyła zdarzenia do gatewaya, a ten przekazuje je serwerowo. Omija to blokery skryptów, ale nie wzbogaca zdarzeń o dane z bazy sklepu.
Google Tag Manager server-side
Kontener serwerowy GTM z tagiem Conversions API daje pełną kontrolę nad transformacją danych: można dołączyć zahaszowany e-mail z warstwy danych, odczytać fbp i fbc z żądania i wysłać zdarzenia zwrotu z panelu sklepu. Wymaga to własnej subdomeny i hostingu kontenera; szczegóły architektury opisujemy w tekście o server-side taggingu GA4, bo ta sama instalacja obsługuje oba systemy reklamowe.
Niezależnie od ścieżki, zdarzenia można wysyłać tylko po zgodzie użytkownika. Baner zgód powinien blokować zarówno piksel, jak i wywołanie serwerowe; CAPI nie jest sposobem na obejście RODO, a jedynie na obejście awarii technicznych przeglądarki.
Ocena jakości dopasowania w Menedżerze zdarzeń
Menedżer zdarzeń pokazuje przy każdym zdarzeniu serwerowym wynik dopasowania zdarzeń (Event Match Quality) w skali od 0 do 10. Meta uznaje wynik 6 lub wyższy za dobry; poniżej 4 zdarzenie wnosi niewiele do optymalizacji. Wynik rośnie wraz z liczbą poprawnych parametrów user_data, a spada, gdy pola są puste, niezahaszowane lub zahaszowane po złej normalizacji.
Przed uruchomieniem kampanii przetestujcie ładunek w zakładce testowania zdarzeń. Zdarzenie z parametrem test_event_code pokazuje w czasie rzeczywistym, które pola dotarły, czy deduplikacja zadziałała i co zgłasza walidator. Po wdrożeniu kontrolujcie dwa wskaźniki: udział zdarzeń z serwera oraz procent zdeduplikowanych. Jeśli serwer wysyła 100 zakupów, a piksel 70, to 30 odzyskaliście dzięki CAPI; jeśli deduplikacja pokazuje zero, a liczba zakupów w raportach skoczyła, dublujecie zdarzenia.
Co zrobić, gdy wyniki nadal się nie zgadzają
Poprawne CAPI zmniejsza rozbieżność między sklepem a Meta, ale jej nie likwiduje. Pozostała różnica ma zwykle jedno z trzech źródeł i każde wymaga innej reakcji.
- Okno atrybucji. Domyślne 7 dni po kliknięciu i 1 dzień po wyświetleniu przypisuje Meta zakupy, które sklep widzi jako ruch bezpośredni lub organiczny. Porównujcie liczby w tym samym oknie albo zawęźcie je do 7 dni po kliknięciu bez wyświetleń.
- Zdarzenia z serwera bez identyfikatorów przeglądarki. Gdy EMQ dla
Purchasewynosi 3–4, sprawdźcie, czy formularz zamówienia przenosi_fbpi_fbcdo backendu. Brak tych pól to najczęstsza przyczyna niskiego wyniku. - Modelowane konwersje. Dla użytkowników iOS bez zgody Meta szacuje konwersje statystycznie i oznacza je w raportach. Te liczby nie mają odpowiednika w sklepie i nigdy nie będą się zgadzać jeden do jednego.
Jeśli po sprawdzeniu tych trzech punktów raporty nadal rozjeżdżają się o więcej niż 15–20%, przyczyna leży zwykle poza CAPI: w kanibalizacji ruchu brandowego przez kampanie automatyczne (po stronie Google pokazujemy to na przykładzie tego, jak Performance Max zjada budżet na ruch brandowy) albo w sposobie liczenia zamówień anulowanych.
FAQ: najczęstsze pytania o Conversions API
Czy Conversions API może całkowicie zastąpić piksel Meta?
Technicznie tak, praktycznie nie warto. Piksel dostarcza identyfikatory fbp i fbc oraz zdarzenia wczesne w lejku, których serwer nie widzi. Bez piksela wynik dopasowania zdarzeń serwerowych spada, bo Meta musi polegać wyłącznie na zahaszowanych danych osobowych. Zalecany model to oba kanały równolegle z deduplikacją po event_id.
Jaki wynik dopasowania zdarzeń jest wystarczający?
Meta wskazuje 6 z 10 jako próg dobrego dopasowania. Dla zdarzenia Purchase w sklepie, który zbiera e-mail, telefon i adres, realne jest 7–8. Poniżej 4 większość zdarzeń nie łączy się z żadnym użytkownikiem.
Czy dane klientów muszą być haszowane przed wysłaniem?
Tak, wszystkie dane osobowe (e-mail, telefon, imię, nazwisko, adres) wysyła się jako SHA-256 po normalizacji. Wyjątkiem są adres IP, user agent oraz identyfikatory fbp i fbc, które przekazuje się w postaci jawnej.
Ile czasu ma serwer na wysłanie zdarzenia?
Parametr event_time może wskazywać moment do 7 dni wstecz, więc zdarzenia można wysyłać z opóźnieniem lub w partiach. Deduplikacja z pikselem działa jednak tylko w oknie 48 godzin, więc zdarzenia dublowane warto wysyłać blisko czasu rzeczywistego.
Czy CAPI działa bez zgody użytkownika na ciasteczka?
Nie powinno. Wysyłanie zdarzeń z serwera bez zgody jest tak samo przetwarzaniem danych osobowych jak uruchomienie piksela. Baner zgód musi warunkować oba kanały. CAPI rozwiązuje techniczną utratę sygnału (blokery, ITP, zamknięta karta), nie brak zgody.
Co dalej
Po wdrożeniu CAPI porównajcie liczby z Meta z raportem sprzedaży w tym samym oknie atrybucji i zapiszcie wynik dopasowania dla każdego zdarzenia jako punkt odniesienia. Kolejny krok to spięcie tej samej infrastruktury serwerowej z Google, żeby oba systemy reklamowe uczyły się na tym samym, kompletnym sygnale.