Strona główna / Poradniki

Meta Pixel i CAPI: dlaczego zakupy liczą się dwa razy

Jak naprawdę działa deduplikacja, jak wygląda eid w żądaniu przeglądarki i pięć błędów, które zamieniają jedno zamówienie w dwie konwersje.

Opublikowano 10 sierpnia 2026

Uruchomienie Pixela i Conversions API obok siebie to konfiguracja zalecana przez Metę i podwaja liczbę zakupów w chwili, gdy deduplikacja nie jest do końca poprawna. Przez tydzień raporty wyglądają świetnie, ROAS wygląda świetnie, a potem ktoś porównuje je z tabelą zamówień.

Jak działa deduplikacja

Meta odrzuca drugą kopię zdarzenia, gdy spełnione są jednocześnie dwa warunki: oba zdarzenia mają tę samą nazwę i ten sam identyfikator zdarzenia. To cały mechanizm. W przeglądarce identyfikator jest czwartym argumentem fbq:

• fbq('track', 'Purchase', { value: 1648.25, currency: 'TRY' }, { eventID: 'ORD-70412' })

Zdarzenie serwerowe wysłane przez Conversions API musi nieść event_name: "Purchase" i event_id: "ORD-70412". Ta sama nazwa, ten sam identyfikator, jedna konwersja. W każdym innym przypadku masz dwie.

Meta łączy parę w oknie 48 godzin, więc obie połowy nie muszą dotrzeć razem — muszą się jednak zgadzać.

Co pokazuje żądanie przeglądarki

Pixel wysyła zdarzenie na facebook.com/tr/, a wszystko istotne jest w query stringu:

• id — identyfikator pixela.
• ev — nazwa zdarzenia. Purchase i purchase to dla Mety dwa różne zdarzenia: drugie jest zdarzeniem niestandardowym i nigdy nie zdeduplikuje się z pierwszym.
• eid — identyfikator zdarzenia i klucz deduplikacji. Jeśli go nie ma, deduplikacja nie nastąpi, cokolwiek wyśle serwer.
• cd[...] — dane niestandardowe: cd[value], cd[currency], cd[content_ids] i pozostałe.
• ud[...] — dane użytkownika, zahaszowane. ud[em] powinien być skrótem SHA-256; jeśli czytasz tam adres e-mail, masz pilniejszy problem niż deduplikacja.
• fbp i fbc — cookie identyfikatora przeglądarki i identyfikatora kliknięcia.

Odczytanie eid wprost z żądania odpowiada na pierwsze pytanie — czy połowa przeglądarkowa w ogóle bierze udział w deduplikacji — w kilka sekund i bez otwierania Events Managera.

Pięć sposobów, w jakie to się psuje

1. Tylko jedna strona wysyła identyfikator. Serwer zrobiony starannie, pixel zostawiony bez zmian albo odwrotnie. Brak eid, brak deduplikacji.
2. Każda strona generuje własny. Świeży UUID po obu stronach to dwa identyfikatory i dwie konwersje. Identyfikator musi pochodzić z czegoś, co obie strony już znają: z numeru zamówienia.
3. Nazwy zdarzeń się różnią. Niestandardowe purchase w przeglądarce wobec standardowego Purchase na serwerze. Wielkość liter ma znaczenie.
4. Pixel uruchamia się dwa razy. Jednostronicowe koszyki inicjalizują się ponownie przy zmianie trasy i wysyłają drugi Purchase z nowym identyfikatorem. Przeładowanie lub dodanie strony potwierdzenia do zakładek daje ten sam efekt.
5. Dwa tagi na jedno zdarzenie. Tag w GTM i snippet wpisany na sztywno w motywie uruchamiają się oba. Ten błąd przeżywa każdy audyt, bo każdy tag z osobna jest poprawny.

Co przeglądarka może, a czego nie udowodni

Uczciwie o granicy: rozszerzenie przeglądarki nie widzi Twoich zdarzeń serwerowych. Nie powie, czy wywołanie Conversions API wyszło, jaki niosło identyfikator ani czy Meta połączyła parę. Jedynym miejscem, które raportuje wynik deduplikacji, jest Events Manager, a jego diagnostyka deduplikacji jest warta przeczytania.

Przeglądarka rozstrzyga tę połowę, która zwykle zawodzi. Cztery z pięciu powyższych awarii są po stronie przeglądarki — brak identyfikatora, losowy identyfikator, zła nazwa zdarzenia, podwójne wywołanie — i wszystkie cztery widać w żądaniu, zanim ktokolwiek zajrzy do logów serwera.

Procedura sprawdzenia

1. Wykonaj zakup testowy z otwartym panelem.
2. Znajdź żądanie Purchase i potwierdź, że ev jest zapisane dokładnie tak jak na serwerze.
3. Odczytaj eid. Powinien być i powinien być rozpoznawalny — Twój numer zamówienia, nie losowy ciąg.
4. Policz żądania Purchase. Powinno być dokładnie jedno. Przeładuj stronę potwierdzenia i policz ponownie.
5. Porównaj cd[value] i cd[currency] z zamówieniem. Zdeduplikowana para ze złą wartością wciąż raportuje zły przychód.
6. Dopiero teraz otwórz Events Managera i sprawdź wskaźnik deduplikacji dla tego zdarzenia.

Wybór identyfikatora zdarzenia

Identyfikator musi dać się wyprowadzić z tego samego faktu po obu stronach i przetrwać przeładowanie. Dla zakupu jest to numer zamówienia i nic innego się nie zbliża. Dla zdarzeń bez naturalnego klucza — ViewContent, AddToCart — wygeneruj identyfikator raz, umieść go w dataLayer i niech zarówno pixel, jak i serwer czytają go stamtąd. Identyfikator wymyślony niezależnie w dwóch miejscach nie jest identyfikatorem; to dwa identyfikatory o wspólnej nazwie pola.

Powiązane poradniki

• Jak debugować GTM bez trybu podglądu
• Test Events dla TikToka, Snapa, UET i pięciu platform
• Testowanie śledzenia bez zaśmiecania produkcyjnych raportów