Meta Pixel i Conversions API (CAPI) w SalesCRM

SalesCRM śledzi zdarzenia Meta (Facebook/Instagram) dwoma kanałami naraz: Pixelem w przeglądarce oraz Conversions API z naszego serwera. Oba dla tego samego zakupu wysyłają identyczny event_id, dzięki czemu Meta deduplikuje zdarzenia i nie liczy konwersji podwójnie.

1. Dwa kanały — o co chodzi

Meta zbiera te same zdarzenia (np. Purchase) z dwóch źródeł, bo każde ma inne mocne strony:

• Pixel (client-side) — kod fbq wstrzykiwany na strony sklepu. Działa w przeglądarce kupującego, dostarcza sygnały przeglądarkowe (m.in. _fbp, _fbc). Wadą jest podatność na blokery reklam, brak zgody na ciasteczka i ograniczenia przeglądarek — część zdarzeń nigdy nie dolatuje.
• Conversions API / CAPI (server-side) — zdarzenie wysyłane bezpośrednio z serwera SalesCRM do Meta (Graph API). Omija blokery i ograniczenia przeglądarki, więc łapie praktycznie 100% zakupów.

Najlepszy efekt daje uruchomienie obu kanałów jednocześnie — wtedy Meta ma komplet danych, a duplikaty usuwa po wspólnym event_id (patrz sekcja 4).

2. Konfiguracja w panelu

Wejdź w Konfiguracja → Integracje → Pixel Meta. Dostępne pola:

Checkboxy „client-side" i „po stronie serwera" są niezależne. Aby uzyskać deduplikację, włącz dla danego zdarzenia oba (np. Śledzenie zakupów + Śledzenie zakupów po stronie serwera).

3. Jakie zdarzenia i którym kanałem

SalesCRM używa standardowych nazw zdarzeń Meta (pisownia PascalCase). Nazwy małymi literami, np. purchase czy view_cart, to konwencja Google Analytics 4, a nie Meta — do Meta ich nie wysyłamy.

InitiateCheckout nie jest nadawany przez SalesCRM — pojawia się tylko, jeśli własny front sklepu (architektura headless) odpala je samodzielnie.

4. Deduplikacja po event_id

Meta uznaje dwa zdarzenia (jedno z Pixela, drugie z CAPI) za ten sam fakt, gdy mają identyczne event_name oraz event_id. Dla zakupu SalesCRM używa po obu stronach klucza:

event_id = orders_<wewnętrzny numer zamówienia>   // np. orders_18345

To ten sam identyfikator wysyłany przez Pixel (jako eventID) i przez Conversions API (jako event_id), więc Meta widzi jeden zakup zamiast dwóch. Analogicznie AddToCart deduplikuje się po wspólnym kluczu atc-….

Aby deduplikacja działała, ten sam zakup musi dolecieć oboma kanałami z tym samym event_id. Jeśli któryś kanał jest wyłączony albo wysyła inny identyfikator, Meta nie ma czego sparować.

5. Dane dopasowania (Event Match Quality)

Kanał serwerowy (CAPI) dołącza do zdarzenia dane dopasowania, które podnoszą skuteczność atrybucji. Dane osobowe są hashowane SHA-256 przed wysyłką:

• Hashowane: e-mail kupującego (oraz, jeśli dostępne, telefon, imię, nazwisko, miasto, kod pocztowy, kraj).
• Niehashowane sygnały: adres IP, user-agent, fbc (identyfikator kliknięcia reklamy z ?fbclid), fbp (cookie pixela) oraz external_id — anonimowy, trwały identyfikator odwiedzającego (cookie scrm_eid), wysyłany identycznie przez Pixel i CAPI.

6. Architektura headless (własny front sklepu)

Jeśli sklep działa na własnym froncie (np. Next.js), a SalesCRM pełni rolę zaplecza, to przeglądarkowy Pixel odpala Twój front, a Conversions API wysyła SalesCRM. Żeby oba kanały deduplikowały się poprawnie, front musi użyć tego samego event_id co serwer (orders_<id>).

Udostępniamy do tego endpoint REST API (uwierzytelnienie nagłówkiem X-API-KEY sklepu), który zwraca kanoniczne dane zakupu na podstawie identyfikatora płatności z adresu powrotu bramki:

GET /api/v1/purchase_pixel_data?payment_id=<OrderID z powrotu płatności>
X-API-KEY: <klucz API sklepu>

→ { "event_id": "orders_18345", "value": 59.98, "currency": "PLN", "contents": [ ... ] }

Front pobiera stąd event_id (oraz autorytatywną wartość zamówienia) i oznacza nim przeglądarkowe zdarzenie Purchase — dzięki czemu jest zgodne z tym, co równolegle wysyła Conversions API.

Bramki płatności (np. Autopay) na powrocie przekazują zwykle własny identyfikator transakcji/płatności, a nie wewnętrzny numer zamówienia. To najczęstsza przyczyna „rozjazdu" event_id między frontem a serwerem — powyższy endpoint mapuje jedno na drugie.

7. Najczęstsze pytania

Odznaczyłem checkboxy, a kod pixela dalej jest na stronie. Dlaczego?

Bazowy kod pixela (fbq('init', …) z external_id oraz znacznik <noscript> PageView) renderuje się zawsze, gdy wpisany jest Pixel ID — niezależnie od checkboxów. Checkboxy sterują tylko wysyłką poszczególnych zdarzeń, nie samą inicjalizacją. Aby usunąć pixel całkowicie, wyczyść pole Pixel ID.

W Menedżerze Zdarzeń mam niskie pokrycie deduplikacji (np. 9,6%) i ostrzeżenia o event_id.

To znaczy, że dla większości zakupów Meta dostaje zdarzenie tylko z jednego kanału albo z dwoma różnymi event_id. Sprawdź kolejno:

• Czy włączone są oba kanały dla Purchase (client-side + po stronie serwera) i czy uzupełniony jest token API.
• Czy w architekturze headless front używa kanonicznego event_id (sekcja 6).

Pamiętaj, że 100% jest nieosiągalne — część przeglądarkowych Pikseli zawsze utną blokery reklam i brak zgody na ciasteczka. To normalne i bezpieczne: Conversions API łapie wszystkie zakupy, więc atrybucja pozostaje kompletna niezależnie od wskaźnika deduplikacji.

Czy wysyłacie zdarzenia purchase / view_cart (małymi literami)?

Nie do Meta. To nazewnictwo Google Analytics 4. Do Meta lecą standardowe zdarzenia PageView, AddToCart, ViewContent, Purchase.

Czy event_id to numer zamówienia?

Pełni dokładnie tę rolę. Kanoniczny klucz deduplikacji zakupu to orders_<wewnętrzny numer zamówienia> — spójny między Pixelem a Conversions API.