Facebook Pixel nie śledzi konwersji – CAPI debug i naprawa 2026

Zanim zaczniesz szukać błędu, potrzebujesz czterech narzędzi: Pixel Helper (rozszerzenie Chrome), Events Manager w panelu Meta, tryb Test Events oraz Diagnostics tab. Każde pokazuje co innego, więc debug robisz w takiej kolejności.

Pixel Helper sprawdzisz w 10 sekund. Otwierasz stronę sklepu, klikasz ikonę w przeglądarce i widzisz listę eventów: PageView, ViewContent, AddToCart, Purchase. Zielona ikona i brak ostrzeżeń oznaczają, że skrypt się załadował i wysłał sygnał. Żółte trójkąty z opisem błędu (np. 'Pixel did not load') sugerują problem po stronie frontendu.

Events Manager w Meta pokazuje eventy, które rzeczywiście dotarły do serwerów Meta – nie tylko te wysłane z przeglądarki. To różnica kluczowa dla CAPI, bo Pixel Helper server-side eventów nie pokaże. W sekcji Overview zobaczysz wykres ostatnich 24 godzin z podziałem na źródło: Browser, Server, Both. Jeśli w kolumnie Server masz zero, CAPI nie działa, nawet jeżeli front strzela poprawnie.

Test Events to tryb debug w czasie rzeczywistym. Podajesz URL lub kod testowy i widzisz eventy, które strona wysyła właśnie w tej chwili, z rozbiciem na parametry (event_id, fbp, fbc, user_data). To najszybszy sposób, żeby sprawdzić konkretny scenariusz, np. symulację zakupu na stage'u przed wypuszczeniem zmiany na produkcję.

Match Quality rating w Diagnostics pokazuje, jak dobrze Meta łączy Twoje eventy z kontami użytkowników. Skala 0–10, cel to 8 lub więcej. Niski wynik oznacza, że wysyłasz za mało parametrów identyfikacyjnych (email, telefon, external_id, fbp, fbc, client_user_agent) – i nawet jeśli konwersje są rejestrowane, Meta słabo atrybuuje je do reklam.

To brzmi banalnie, ale w 20% przypadków problem jest właśnie tu. Skrypt Facebook Pixel nie trafia do DOM z powodu wtyczki cache, asynchronicznego ładowania JS albo błędu w kontenerze GTM. Objaw: Pixel Helper nie widzi żadnych eventów, w konsoli przeglądarki leci błąd 'fbq is not defined'.

Najczęstsi winowajcy w WordPress to: WP Rocket z agresywnym Delay JS, LiteSpeed Cache z Combine JS, Autoptimize defer'ujący wszystkie skrypty bez wykluczeń. Każde z tych ustawień opóźnia lub łączy skrypt Pixela na tyle, że odpala się po zdarzeniu, które chcesz zmierzyć (np. Purchase na stronie 'Dziękujemy za zamówienie').

Naprawa zajmie Ci 5 minut. W WP Rocket przejdź do File Optimization i dodaj do Excluded JavaScript Files wpis `connect.facebook.net` oraz `fbevents.js`. W LiteSpeed Cache masz analogiczną listę w Page Optimization, JS Settings. Jeśli używasz GTM, upewnij się, że Tag Facebook Pixel ma trigger All Pages i priorytet ustawiony wyżej niż inne tagi marketingowe.

Druga przyczyna to błędy Content Security Policy. Jeśli nagłówek CSP serwera nie zawiera `connect.facebook.net` i `*.facebook.com` w dyrektywach `script-src` i `connect-src`, przeglądarka po prostu zablokuje skrypt. Sprawdzisz to w zakładce Console DevTools – szukasz komunikatów 'Refused to load the script'.

Trzecia opcja: wtyczka consent modal blokuje Pixel do momentu akceptacji cookies, ale akceptacja nie odpala faktycznego załadowania skryptu. Klasyczny błąd przy wdrożeniu CookieYes, Cookiebot albo Complianz bez poprawnego triggera 'Update Consent' w dataLayer.

Od 6 marca 2024 Meta wymaga Consent Mode v2 dla ruchu z Europejskiego Obszaru Gospodarczego. Jeśli Twój sklep nie przekazuje sygnału zgody, Pixel dla użytkowników z UE nie będzie rejestrował eventów – a w 2026 ta egzekucja jest już wdrożona bez taryfy ulgowej.

Sprawdź to w Events Manager, Diagnostics. Jeśli widzisz ostrzeżenie 'Consent Mode v2 not detected' albo 'Missing signals', to jest Twój problem. W praktyce dla polskich e-commerców oznacza to utratę od 30% do nawet 60% zdarzeń, bo większość ruchu pochodzi z kraju objętego RODO.

Najłatwiejsza implementacja idzie przez Google Tag Manager. Instalujesz tag typu 'Consent Initialization – All Pages' z domyślnymi wartościami (denied dla ad_storage, ad_user_data, ad_personalization, analytics_storage), a potem w banerze cookies dopisujesz update: `gtag('consent', 'update', {ad_storage: 'granted', ad_user_data: 'granted', ad_personalization: 'granted'})`. Meta automatycznie zaczyta te sygnały z dataLayer, jeśli Pixel odpalasz przez GTM.

Dla wdrożeń bez GTM masz dwie opcje. Pierwsza: wtyczka Consent Management Platform zgodna z IAB TCF v2.2 (w Polsce popularne CookieYes Pro, Cookie Information albo Complianz Premium). Druga: ręczne wywołanie `fbq('consent', 'grant')` lub `fbq('consent', 'revoke')` w callbacku zgody. Pamiętaj, że bez CMP dostosowanej do Meta eventy z EOG będą modelowane, a nie mierzone realnie – co oznacza ~50% dokładności.

Po wdrożeniu odczekaj 24 godziny i sprawdź w Events Manager, czy ostrzeżenie zniknęło. Jeśli nie, audyt tagowania i tracking setup pomoże namierzyć problem po stronie CMP.

Access token dla Conversions API generujesz w Business Manager, zakładka Events Manager, Settings. Tokeny long-lived działają domyślnie 60 dni albo do momentu zmiany hasła administratora konta Meta. Kiedy wygasa, eventy wysyłane server-side przestają docierać i w kolumnie Server widzisz pełne zero.

Pierwszy objaw: w logach integracji (WooCommerce + wtyczka PixelYourSite Pro, Plausible, lub własne PHP) zaczynasz dostawać odpowiedzi HTTP 400 z treścią `{'error':{'message':'Invalid OAuth access token'}}`. Druga oznaka: Test Events nie pokazuje żadnego wpisu typu Server przy symulacji zakupu.

Diagnostyka trwa minutę. Kopiujesz token z panelu Meta, uruchamiasz w terminalu `curl -X POST 'https://graph.facebook.com/v19.0/YOUR_PIXEL_ID/events?access_token=YOUR_TOKEN'` z minimalnym payloadem PageView. Jeśli dostajesz błąd OAuth, token faktycznie wygasł. Jeśli dostajesz 200 OK, problem jest w integracji (np. mu-plugin w WordPress ma zapisany stary token w bazie).

Naprawa: w Events Manager generujesz nowy token (Settings, Conversions API, Generate Access Token). Kopiujesz go do pliku .env lub ustawień wtyczki i restartujesz cache. Dla wtyczek takich jak PixelYourSite Pro dodatkowo wyczyść cache opcji w bazie: `wp cache flush` oraz `wp transient delete --all`. Dla GTM Server-Side Tracking zmieniasz zmienną typu Constant i publikujesz nową wersję kontenera.

Best practice: ustaw przypomnienie w kalendarzu co 45 dni na rotację tokenu. Albo jeszcze lepiej – użyj System User z business manager (token nie wygasa) zamiast personalnego konta. Instrukcja: Business Settings, System Users, Add System User, przypisujesz do Pixela z uprawnieniami Manage Pixel, generujesz token z opcją 'Never' expiration.

Najbardziej podstępny błąd, bo Events Manager pokazuje eventy w obu kolumnach (Browser i Server) i wszystko wygląda dobrze – aż sprawdzisz, że Meta liczy każdy zakup 2 razy. Skutek: ROAS wydaje się 2x wyższy niż rzeczywisty, algorytm optymalizuje na zawyżone dane, CAC rośnie w realu mimo 'dobrych' liczb w raporcie.

Deduplikacja działa w oparciu o dwa parametry wysyłane zarówno z Pixela, jak i z serwera: `event_id` (unikalny identyfikator zdarzenia, np. order ID dla Purchase) oraz `event_name` (nazwa zdarzenia – Purchase, AddToCart, Lead). Jeśli oba trafiają do Meta z tym samym event_id, system traktuje je jako to samo zdarzenie i liczy raz. Bez event_id Meta liczy 2x.

Test zajmie 2 minuty. W Events Manager, Test Events wygenerujesz testowy Purchase na stage'u. W panelu zobaczysz kolumnę Deduplication Status. Wartości możliwe: Deduplicated, Not Deduplicated, Processing. Jeśli widzisz 'Not Deduplicated', masz problem.

Naprawa dla WooCommerce z PixelYourSite Pro: w ustawieniach wtyczki włącz opcję 'Enable deduplication' oraz 'Use order ID as event ID'. Sprawdź checkbox przy każdym evencie, który wysyłasz przez CAPI. Dla GTM4WP w konfiguracji CAPI tagu dodaj zmienną `{{Order ID}}` w polu Event ID – musi być ta sama wartość co Pixel Event ID wysyłany z przeglądarki.

Dla własnych integracji w PHP przekazuj do funkcji `fbq('track', 'Purchase', {...}, {eventID: 'order_'+orderID})` po stronie JS oraz `event_id => 'order_'.$order_id` w payloadzie REST API Meta. Kluczowe: dokładnie ten sam string w obu miejscach. Literówka, spacja albo różny prefix = brak deduplikacji.

Więcej o scenariuszach błędów w tracking setup znajdziesz w poradniku debugowania Facebook Ads.

App Tracking Transparency (iOS 14.5, wprowadzony w kwietniu 2021) oraz Link Tracking Protection (iOS 17.5, maj 2024) to dwa niezależne ograniczenia, które razem wycinają znaczną część sygnałów z urządzeń Apple. W praktyce: 26–32% polskiego ruchu mobilnego przychodzi z iPhone'a, a z tego ~70% użytkowników klika 'Ask App Not to Track' w banerze Meta.

ATT dotyczy aplikacji Facebook i Instagram. Gdy użytkownik nie wyraża zgody na śledzenie, Meta traci dostęp do IDFA i nie może jednoznacznie połączyć kliknięcia w reklamę z konwersją na stronie. Meta łata to mechanizmem Aggregated Event Measurement (AEM), który pozwala priorytetyzować 8 eventów na domenę – ale tylko dla domen zweryfikowanych w Business Manager.

Link Tracking Protection (iOS 17.5 w Mail, Messages i Safari Private Browsing) idzie krok dalej. Safari automatycznie usuwa z linków parametry śledzące, w tym `fbclid`, `gclid`, `utm_*`. Efekt: użytkownik klika reklamę, trafia na stronę, ale fbclid nie dociera do Twojego Pixela. CAPI nie może wygenerować `fbc` cookie i Match Quality dramatycznie spada.

Co z tym zrobić w 2026. Po pierwsze: zweryfikuj domenę w Business Manager (Brand Safety, Domains, Add Domain + DNS TXT record). Po drugie: skonfiguruj 8 priorytetowych eventów w AEM, gdzie Purchase idzie jako #1. Po trzecie: w CAPI zamiast polegać na fbc przekazuj jak najwięcej first-party data – hashed email, telefon, external_id z bazy klientów, client_user_agent, client_ip_address.

Po czwarte: rozważ implementację first-party tracking z własnej subdomeny przez Server-Side GTM. To obchodzi ITP i ETP, bo Pixel ładuje się z `track.twojsklep.pl`, a nie z `connect.facebook.net`. Koszt: ~300 zł miesięcznie za App Engine + konfiguracja (4–8h pracy dewelopera).

Firefox Enhanced Tracking Protection (domyślnie włączone od 2019) i Safari Intelligent Tracking Prevention (od 2017, rozwijane do dziś) blokują cookies 3rd party i skrypty z domen na listach trackerów Disconnect.me. Facebook Pixel (`connect.facebook.net`) jest na każdej liście, więc dla ~20% użytkowników frontend nie wysyła żadnych eventów.

Do tego dochodzi uBlock Origin, AdBlock Plus, Brave Shields, Ghostery i dziesiątki innych narzędzi anty-tracking. Łącznie w Polsce ~35–42% ruchu desktop korzysta z jakiejś formy blokera. Dla frontendowego Pixela to oznacza trwałą utratę tej części populacji, niezależnie od poprawności konfiguracji.

Jedyne realne obejście to Conversions API server-side. Bloker nie zatrzyma zapytania, które leci z Twojego backendu (PHP, Node, Python) do Graph API Meta – bo to połączenie server-to-server, przeglądarka użytkownika nawet o nim nie wie. Dlatego CAPI nie jest opcjonalnym dodatkiem do Pixela, tylko absolutnym must-have w 2026.

Priorytet wysyłki eventów przez CAPI: Purchase, InitiateCheckout, AddToCart, Lead, CompleteRegistration. PageView i ViewContent zostaw jako Pixel-only, bo ich waga w optymalizacji jest niska, a CAPI kosztuje czas ładowania strony. Dla Purchase deduplikacja jest kluczowa – patrz Przyczyna 4.

Wtyczki, które automatyzują CAPI w WooCommerce: PixelYourSite Pro (149 USD/rok, pełna dedupe + CAPI), Pixel Caffeine (darmowa, basic), GTM4WP + Server-Side GTM (darmowa, ale wymaga konfiguracji). Dla Shopify Meta oferuje natywną integrację CAPI Gateway (darmowa od 2023).

Dodatkowy tip: Server-Side GTM na własnej subdomenie to najskuteczniejsze rozwiązanie obchodzące jednocześnie ETP, ITP i ad blockery. Pixel ładuje się z Twojej domeny (np. `sgtm.twojsklep.pl`), więc bloker go nie zidentyfikuje jako trackera Meta.

Match Quality 8 lub więcej to próg, poniżej którego algorytm Meta znacząco gorzej dopasowuje konwersje do kampanii. W 2026 bez tego wyniku optymalizacja Advantage+ działa jak strzelanie po omacku, a koszt konwersji rośnie średnio o 25–40% względem kont z Match Quality 9–10.

Parametry, które wpływają na Match Quality (od najważniejszych): hashed email (em), hashed phone (ph), external_id (Twój identyfikator klienta z CRM/sklepu), client_ip_address, client_user_agent, fbp (cookie Pixela), fbc (cookie kliknięcia fbclid), fn (hashed first name), ln (hashed last name), ct (city), st (state), zp (postal code), country, db (date of birth).

Minimum dla porządnego Match Quality to em + ph + external_id + client_ip_address + client_user_agent + fbp + fbc. Z samym em + ph wynik zwykle plasuje się w okolicach 6–7. Dodanie external_id i client_ip_address podnosi go do 8–9. Pełny komplet z adresem + datą urodzenia daje 9–10.

Hashowanie parametrów: Meta wymaga SHA-256 w formacie lowercase, bez spacji, bez polskich znaków diakrytycznych. Dla telefonu: usuń wszystko oprócz cyfr, dodaj prefix kraju bez znaku +. Dla emaila: trim + lowercase + SHA-256. Jeśli wyślesz surowy email, Meta odrzuci event z błędem 'Parameter must be hashed'.

W WooCommerce + PixelYourSite Pro hashowanie leci automatycznie, wystarczy w ustawieniach zaznaczyć 'Advanced Matching'. Dla własnych integracji PHP: `hash('sha256', strtolower(trim($email)))`. Dla Node.js: `crypto.createHash('sha256').update(email.toLowerCase().trim()).digest('hex')`.

fbp i fbc to cookies, które Pixel ustawia automatycznie w przeglądarce. Dla CAPI musisz je odczytać po stronie serwera (`$_COOKIE['_fbp']`, `$_COOKIE['_fbc']`) i przekazać w payloadzie. Brak tych dwóch to najczęstszy błąd własnych integracji – Match Quality wtedy nie przekracza 5.

Pełna procedura debug zajmuje 30–60 minut dla pojedynczego sklepu. Idziesz po kolei, nie pomijając kroków – każdy eliminuje jedną grupę przyczyn.

Krok 1 (5 min). Otwórz sklep w trybie incognito, bez rozszerzeń. Włącz Pixel Helper. Przejdź ścieżkę zakupową: katalog, karta produktu, koszyk, checkout, thank-you page. Sprawdź, czy na każdym kroku widzisz odpowiedni event: PageView, ViewContent, AddToCart, InitiateCheckout, Purchase. Brak któregoś = debugujesz tę konkretną stronę.

Krok 2 (5 min). W Events Manager otwórz Overview i sprawdź wykres z ostatnich 24h. Zobacz proporcję Browser vs Server. Jeśli Browser = 100%, CAPI nie działa. Jeśli Server = 0, CAPI w ogóle nie strzela. Jeśli oba mają eventy, ale suma jest niższa niż realna liczba zamówień z WooCommerce – masz problem z deduplikacją.

Krok 3 (10 min). Uruchom Test Events. Podaj URL strony kasy. Zrób zakup testowy (stripe test mode albo voucher 100% zniżki). Obserwuj eventy w czasie rzeczywistym. Sprawdź kolumny: Deduplication Status, Event ID, Match Quality Score (per event). Rezultat pokaże Ci w 30 sekund, gdzie jest problem.

Krok 4 (10 min). Przejdź do Diagnostics tab. To lista wszystkich ostrzeżeń, które Meta wykryła w ostatnich 7 dniach. Typowe: 'Missing Consent Mode Signals', 'High Number of Duplicates', 'Missing Event ID', 'Low Match Quality'. Każde ostrzeżenie ma link do dokumentacji z naprawą.

Krok 5 (20 min). Napraw najpoważniejsze błędy. Priorytetyzuj w tej kolejności: Consent Mode v2 → CAPI token → deduplikacja → Match Quality → reszta. Po każdej zmianie czekasz 20–30 minut, bo Meta cache'uje ostrzeżenia i Diagnostics aktualizują się z opóźnieniem.

Kiedy potrzebujesz dewelopera: własna implementacja CAPI w PHP/Node/Python bez wtyczki, migracja do Server-Side GTM na subdomenie, niestandardowe eventy (np. Lead Quality Score), integracja z headless storefront (Next.js, Nuxt, Remix). W tych przypadkach koszt startowy to zwykle 2 000–6 000 zł za konfigurację + 300–500 zł miesięcznie za utrzymanie.

Jeśli po tej procedurze nadal masz braki w raportach, skontaktuj się z nami – robimy pełny audyt trackingu i dostrajamy kampanie Facebook Ads tak, żeby algorytm miał komplet sygnałów do optymalizacji. Więcej kontekstu: odrzucone płatności w Meta Ads.