Conversions API Meta w sklepie internetowym: jak wdrożyć CAPI i sprawdzić, czy działa (2026)

Conversions API Meta (CAPI) to sposób wysyłania zdarzeń, np. zakupu, z serwera sklepu bezpośrednio do Meta, a nie tylko z przeglądarki przez Piksel. W sklepie internetowym najlepiej działa razem z Pikselem: oba źródła wysyłają te same zdarzenia z jednym wspólnym event_id, a Meta usuwa duplikaty. Dzięki temu kampanie na Facebooku i Instagramie dostają pełniejsze dane o sprzedaży, także wtedy, gdy przeglądarka zablokuje skrypt. Wdrożenie sprowadza się do czterech decyzji: które zdarzenia wysyłać, jaką metodą (wtyczka, Gateway, serwerowy GTM czy własna integracja), jak deduplikować i jak uwzględnić zgody użytkowników. Poniżej pokazuję każdy z tych kroków na przykładzie sklepu, także na WooCommerce.

W skrócie

• CAPI nie zastępuje Piksela. Najlepszy układ to Piksel + CAPI z deduplikacją po event_id i event_name.
• Najważniejsze zdarzenie do wysyłki z serwera to Purchase z wartością i walutą.
• Dane klienta (e-mail, telefon) wysyłasz zahashowane SHA-256. Ciasteczek fbp i fbc, adresu IP ani user agenta nie hashujesz.
• Zdarzenie może być wysłane maksymalnie 7 dni po jego wystąpieniu.
• CAPI nie omija zgód. Zasady z art. 399 Prawa komunikacji elektronicznej i RODO obowiązują tak samo.

Spis treści

1. Czym jest Conversions API i czym różni się od Piksela Meta?
2. Dlaczego sklep internetowy potrzebuje CAPI?
3. Jakie zdarzenia wysyłać ze sklepu?
4. Anatomia zdarzenia: wymagane parametry
5. Deduplikacja: jak nie liczyć zakupów podwójnie
6. 4 sposoby wdrożenia CAPI w sklepie
7. Wdrożenie krok po kroku na przykładzie WooCommerce
8. Zgody, RODO i PKE: o czym pamiętać?
9. Jak sprawdzić, czy CAPI działa?
10. Najczęstsze błędy przy wdrożeniu CAPI
11. Pomiar w praktyce Netexo i koszt obsługi
12. Checklista wdrożenia Conversions API Meta
13. FAQ

Czym jest Conversions API i czym różni się od Piksela Meta?

Piksel Meta to skrypt w przeglądarce użytkownika. Gdy klient ogląda produkt albo kończy zamówienie, skrypt wysyła zdarzenie do Meta. Conversions API działa po stronie serwera: to Twój sklep (albo pośredniczący serwer) wysyła informację o zdarzeniu przez API Meta. Opis interfejsu znajdziesz w dokumentacji Conversions API.

Cecha	Piksel Meta	Conversions API
Gdzie działa	Przeglądarka użytkownika	Serwer sklepu lub serwer pośredniczący
Wrażliwość na blokery i ustawienia przeglądarki	Wysoka	Niska, bo dane nie przechodzą przez skrypt w przeglądarce
Dostęp do danych zamówienia	Tylko to, co jest na stronie podziękowania	Pełne dane z systemu: status płatności, wartość, produkty
Wdrożenie	Proste, często jedna wtyczka lub tag	Wymaga konfiguracji serwera, tokenu dostępu i deduplikacji
Wymaga zgody użytkownika	Tak, dla celów marketingowych	Tak, CAPI nie zmienia podstawy prawnej
Rekomendowany układ	Razem z CAPI	Razem z Pikselem

Najprościej: Piksel widzi, co dzieje się w przeglądarce, a CAPI wie, co naprawdę zapisało się w sklepie. Meta zaleca korzystanie z obu źródeł jednocześnie i deduplikację zdarzeń.

Dlaczego sklep internetowy potrzebuje CAPI?

Algorytm reklam Meta uczy się na zdarzeniach, które do niego docierają. Jeśli część zakupów nie trafia do Meta, kampania optymalizuje się na niepełnych danych, a raport pokazuje niższą sprzedaż niż w rzeczywistości.

Zdarzenia z Piksela giną m.in. przez:

• blokery reklam i rozszerzenia prywatności,
• ograniczenia ciasteczek i skryptów w przeglądarkach,
• zamknięcie karty przed załadowaniem strony podziękowania,
• płatności zewnętrzne, po których klient nie wraca do sklepu,
• błędy w szablonie albo konflikty wtyczek po aktualizacji.

CAPI rozwiązuje większość problemów technicznych, bo zdarzenie Purchase wysyła serwer w momencie, gdy zamówienie faktycznie powstaje lub zostaje opłacone. Nie rozwiązuje natomiast braku zgody. Jeśli użytkownik odmówił zgody marketingowej, nie wysyłasz jego danych w celach reklamowych także przez serwer. Więcej o tym w sekcji o zgodach.

Jakie zdarzenia wysyłać ze sklepu?

W e-commerce korzystasz ze zdarzeń standardowych Meta. Nie musisz wysyłać wszystkich przez serwer od pierwszego dnia. Zacznij od zakupu, a potem dokładaj kolejne.

Zdarzenie	Kiedy	Kluczowe parametry	Priorytet dla CAPI
Purchase	Zamówienie złożone lub opłacone (ustal jedną regułę)	value, currency, content_ids, contents, event_id	Najwyższy
InitiateCheckout	Wejście do kasy	value, currency, content_ids	Wysoki
AddToCart	Dodanie produktu do koszyka	content_ids, value, currency	Średni
ViewContent	Wyświetlenie karty produktu	content_ids, content_type	Średni, ważny dla katalogu i remarketingu
AddPaymentInfo	Wybór metody płatności	value, currency	Niski
PageView	Wyświetlenie strony	brak dodatkowych	Niski, zwykle wystarczy Piksel

content_ids muszą być zgodne z katalogiem produktów. Jeśli w katalogu Meta produkt ma identyfikator SKU „SOFA-OSLO-SZ”, to samo ID powinno pojawić się w zdarzeniach. Inaczej remarketing dynamiczny nie połączy oglądanych produktów z katalogiem. Tę spójność sprawdzamy przy każdym wdrożeniu Meta Ads dla e-commerce.

Anatomia zdarzenia: wymagane parametry

Każde zdarzenie wysyłane przez CAPI ma kilka obowiązkowych pól. Pełną listę opisuje dokumentacja parametrów zdarzenia serwerowego.

Pola wymagane:

• event_name – nazwa zdarzenia, np. Purchase,
• event_time – czas zdarzenia jako znacznik Unix w sekundach; może być wcześniejszy niż moment wysyłki, ale maksymalnie o 7 dni. Jeśli choć jedno zdarzenie w paczce jest starsze, Meta odrzuca całe żądanie,
• action_source – źródło konwersji; dla sklepu internetowego „website”,
• user_data – dane do dopasowania użytkownika,
• dla action_source = „website” także event_source_url (adres strony, na której doszło do zdarzenia) i client_user_agent.

Pola zalecane: event_id (do deduplikacji), a dla zakupu w custom_data wartość (value) i waluta (currency, np. PLN) oraz identyfikatory produktów.

Co hashować, a czego nie? Zgodnie z dokumentacją parametrów informacji o kliencie:

• hashujesz SHA-256 (po normalizacji, np. usunięciu spacji i zamianie na małe litery): e-mail (em), telefon (ph), imię i nazwisko, miasto, kod pocztowy, kraj, external_id,
• nie hashujesz: client_ip_address, client_user_agent, fbp (identyfikator przeglądarki z ciasteczka _fbp) i fbc (identyfikator kliknięcia z ciasteczka _fbc lub parametru fbclid).

Przykładowe zdarzenie Purchase (uproszczone):

• event_name: Purchase
• event_time: znacznik czasu złożenia zamówienia
• event_id: order_10482 (ten sam w Pikselu i w CAPI)
• action_source: website
• event_source_url: adres strony podziękowania
• user_data: em i ph (SHA-256), fbp, fbc, client_ip_address, client_user_agent
• custom_data: value 459.00, currency PLN, content_ids [SOFA-OSLO-SZ]

Wartości w przykładzie są poglądowe.

Deduplikacja: jak nie liczyć zakupów podwójnie

Gdy ten sam zakup wysyłasz z Piksela i z serwera, Meta musi wiedzieć, że to jedno zdarzenie. Według dokumentacji deduplikacji dzieje się to wtedy, gdy:

• eventID w Pikselu jest identyczny z event_id w CAPI,
• nazwa zdarzenia jest taka sama w obu źródłach (Purchase = Purchase),
• oba zdarzenia trafią do Meta w ciągu 48 godzin od pierwszego z nich.

Meta bierze pod uwagę pierwsze otrzymane zdarzenie. Jeśli oba dotrą mniej więcej w tym samym czasie (w ciągu ok. 5 minut), preferuje zdarzenie z przeglądarki. Zapasowo deduplikacja może działać na podstawie nazwy zdarzenia i spójnego fbp lub external_id, ale główną metodą powinien być event_id.

Praktyczna zasada: event_id generuje sklep, raz na zdarzenie, i przekazuje go do obu ścieżek. Dla zakupu dobrym wyborem jest numer zamówienia z prefiksem, np. „order_10482”. Dla AddToCart czy ViewContent potrzebny jest unikalny identyfikator generowany przy każdym zdarzeniu.

4 sposoby wdrożenia CAPI w sklepie

Metoda	Dla kogo	Zalety	Ograniczenia
Integracja partnerska (wtyczka lub natywna integracja platformy)	Mniejsze i średnie sklepy na popularnych platformach	Szybki start, bez programowania	Mniejsza kontrola nad danymi i regułami; przy dużych katalogach warto sprawdzić wpływ na wydajność
Conversions API Gateway	Sklepy, które chcą rozwiązania bez kodu po stronie sklepu	Konfiguracja z Menedżera zdarzeń, kopiuje zdarzenia Piksela na serwer	Działa w chmurze należącej do firmy lub partnera, co oznacza koszt infrastruktury; przekazuje to, co widzi Piksel
Serwerowy Google Tag Manager	Sklepy, które już używają GTM i chcą jednego miejsca na tagi	Kontrola nad danymi, jeden strumień dla wielu platform	Wymaga serwera tagowania i wiedzy technicznej
Własna integracja przez API	Duże sklepy, nietypowe procesy, B2B	Pełna kontrola, np. wysyłka zakupu dopiero po opłaceniu	Najwięcej pracy programistycznej i utrzymania

Kilka konkretów:

• Dla WooCommerce Meta udostępnia oficjalną wtyczkę Meta for WooCommerce, która łączy sklep z Pikselem, Conversions API i katalogiem produktów.
• Conversions API Gateway konfigurujesz z poziomu Menedżera zdarzeń. Uruchamia się go w chmurze należącej do firmy albo u partnera.
• Do serwerowego GTM Meta udostępnia szablon tagu Conversions API. Jeśli planujesz ten wariant, zacznij od uporządkowanego wdrożenia Google Tag Managera.

Wdrożenie krok po kroku na przykładzie WooCommerce

1. Sprawdź punkt wyjścia. W Menedżerze zdarzeń zobacz, jakie zdarzenia już docierają, z jakiego źródła (przeglądarka, serwer) i czy nie ma ostrzeżeń w diagnostyce. Porównaj liczbę zdarzeń Purchase z liczbą zamówień w sklepie za ten sam okres.
2. Ustal regułę zakupu. Zdecyduj, kiedy wysyłasz Purchase: po złożeniu zamówienia czy po opłaceniu. W sklepie z dużą liczbą płatności za pobraniem lub przelewem ta decyzja wpływa na to, czego uczy się algorytm.
3. Wybierz metodę wdrożenia z tabeli powyżej. Dla mniejszego sklepu zwykle wystarcza oficjalna wtyczka. Przy większym katalogu albo własnych procesach rozważ serwerowy GTM lub integrację przez API.
4. Wygeneruj token dostępu w ustawieniach zbioru danych (Piksela) w Menedżerze zdarzeń. Token przechowuj po stronie serwera. Nigdy nie umieszczaj go w kodzie strony.
5. Zapewnij wspólny event_id dla Piksela i serwera. Jeśli korzystasz z wtyczki, sprawdź w podglądzie zdarzeń, czy oba źródła przekazują ten sam identyfikator.
6. Przekaż dane dopasowania: zahashowany e-mail i telefon z zamówienia, ciasteczka _fbp i _fbc, adres IP i user agent klienta (a nie serwera).
7. Połącz wysyłkę z mechanizmem zgód. Zdarzenia marketingowe wysyłaj zgodnie z wyborem użytkownika w banerze cookies.
8. Przetestuj w narzędziu „Testuj zdarzenia” w Menedżerze zdarzeń, używając kodu testowego. Złóż testowe zamówienie i sprawdź, czy Purchase pojawia się z przeglądarki i z serwera oraz czy jest oznaczony jako deduplikowany.
9. Monitoruj przez 2–4 tygodnie liczbę zdarzeń, jakość dopasowania i zgodność z zamówieniami.

Zgody, RODO i PKE: o czym pamiętać?

CAPI często jest przedstawiane jako sposób na „odzyskanie danych utraconych przez brak zgody”. To błędne i ryzykowne podejście.

• Od 10 listopada 2024 r. zasady zapisu i odczytu informacji w urządzeniu użytkownika (m.in. ciasteczek takich jak _fbp) reguluje art. 399 ustawy Prawo komunikacji elektronicznej (Dz.U. 2024 poz. 1221). Poza wyjątkami dotyczącymi niezbędnego działania usługi wymaga on uprzedniej informacji i zgody użytkownika.
• Wysyłka danych klienta do Meta z serwera to przetwarzanie danych osobowych, więc potrzebujesz podstawy prawnej i rzetelnej informacji w polityce prywatności zgodnie z RODO.
• W praktyce: baner zgód (CMP) powinien sterować zarówno Pikselem, jak i wysyłką serwerową. Jeśli użytkownik odmówi zgody marketingowej, nie wysyłaj jego zdarzeń w celach reklamowych.

To nie jest porada prawna. Konfigurację zgód w sklepie warto skonsultować z prawnikiem lub inspektorem ochrony danych.

Jak sprawdzić, czy CAPI działa?

W Menedżerze zdarzeń zwróć uwagę na cztery rzeczy:

1. Źródła zdarzeń. Przy zdarzeniu Purchase powinny być widoczne dwa źródła: przeglądarka i serwer.
2. Deduplikacja. Liczba zdarzeń po deduplikacji powinna odpowiadać liczbie zamówień, a nie ich podwojonej liczbie.
3. Jakość dopasowania zdarzeń (Event Match Quality). To ocena w skali 0–10, pokazująca, jak dobrze przesłane dane pozwalają dopasować zdarzenie do konta w Meta. Pomagają poprawne e-mail, telefon, fbp i fbc. Traktuj ją jako wskazówkę, a nie cel sam w sobie.
4. Diagnostyka. Ostrzeżenia o brakujących parametrach, nieprawidłowym hashowaniu albo niezgodnych identyfikatorach katalogu.

Dodatkowo raz w miesiącu porównaj liczbę zdarzeń Purchase z liczbą zamówień w panelu sklepu i w GA4. Różnice będą zawsze, bo każda platforma inaczej przypisuje konwersje, ale nagły skok rozbieżności to sygnał błędu po aktualizacji sklepu albo wtyczki. Pomiar konwersji w GA4 i systemach reklamowych opisujemy szerzej na stronie analityka internetowa.

Najczęstsze błędy przy wdrożeniu CAPI

1. Różne event_id w Pikselu i w CAPI, przez co zakupy liczą się podwójnie, a ROAS w panelu jest zawyżony.
2. Hashowanie wszystkiego, także fbp, fbc, IP i user agenta, co uniemożliwia dopasowanie.
3. Brak normalizacji przed hashowaniem: wielkie litery albo spacje w adresie e-mail dają inny hash.
4. Adres IP serwera zamiast adresu klienta w zdarzeniach serwerowych.
5. Zdarzenia starsze niż 7 dni w paczce, przez co Meta odrzuca całe żądanie.
6. content_ids niezgodne z katalogiem, przez co remarketing dynamiczny pokazuje złe produkty albo nie działa.
7. Brak połączenia ze zgodami: Piksel respektuje baner, a serwer wysyła wszystko.
8. Token dostępu w kodzie strony albo w repozytorium publicznym.

Pomiar w praktyce Netexo i koszt obsługi

W jednej z prowadzonych przez nas kampanii Meta Ads decyzje o budżecie podejmowaliśmy na podstawie kosztu zakupu i zwrotu z reklamy. Efekt to 167 000 zł przychodu, 217 konwersji i ROAS 12,75 przy koszcie kampanii 13 099 zł. Taki sposób prowadzenia kampanii wymaga danych o zakupach, którym można ufać. Dlatego każdą współpracę przy reklamie na Facebooku i Instagramie zaczynamy od weryfikacji zdarzeń i ich wartości.

Według cennika Netexo (ceny brutto, budżet reklamowy opłacasz bezpośrednio do Meta):

• Meta Ads Start od 990 zł/mies.: podstawowe zdarzenia Piksela,
• Meta Ads Standard od 1 500 zł/mies.: pełne zdarzenia, Pixel i pomiar konwersji,
• Meta Ads Growth od 2 500 zł/mies. + 2% przychodu z reklam: pełne zdarzenia z Conversion API, katalog produktowy i zaawansowany remarketing.

Jeśli kampanie już działają, a nie wiesz, czy dane są poprawne, sprawdzi to audyt Meta Ads.

Checklista wdrożenia Conversions API Meta

• Porównana liczba zdarzeń Purchase z liczbą zamówień przed wdrożeniem
• Ustalona reguła wysyłki Purchase (złożenie lub opłacenie zamówienia)
• Wybrana metoda: wtyczka, Gateway, serwerowy GTM lub własna integracja
• Token dostępu przechowywany wyłącznie po stronie serwera
• Wspólny event_id dla Piksela i CAPI, ta sama nazwa zdarzenia
• Wymagane pola: event_name, event_time, action_source, event_source_url, client_user_agent
• value i currency w zdarzeniu Purchase
• content_ids zgodne z katalogiem produktów
• E-mail i telefon znormalizowane i zahashowane SHA-256
• fbp, fbc, IP i user agent klienta wysyłane bez hashowania
• Wysyłka serwerowa połączona z banerem zgód
• Testowe zamówienie widoczne w „Testuj zdarzenia” z obu źródeł i deduplikowane
• Monitoring jakości dopasowania i diagnostyki przez 2–4 tygodnie

FAQ

Czy Conversions API zastępuje Piksel Meta?

Nie. Meta zaleca korzystanie z Piksela i Conversions API jednocześnie, z deduplikacją zdarzeń. Piksel zbiera sygnały z przeglądarki, a CAPI uzupełnia je danymi z serwera, np. o zakupach, których Piksel nie zarejestrował.

Czy CAPI pozwala śledzić użytkowników, którzy nie wyrazili zgody?

Nie powinno być tak używane. Wysyłka danych z serwera nie zmienia wymogów art. 399 Prawa komunikacji elektronicznej ani RODO. Baner zgód powinien sterować także zdarzeniami serwerowymi.

Ile trwa wdrożenie Conversions API w sklepie?

To zależy od metody. Oficjalna wtyczka może działać tego samego dnia. Serwerowy GTM lub własna integracja wymagają zwykle kilku dni pracy i testów. W każdym wariancie zaplanuj 2–4 tygodnie monitoringu po uruchomieniu.

Skąd wiem, że zakupy nie liczą się podwójnie?

Sprawdź w Menedżerze zdarzeń, czy przy zdarzeniu Purchase widać dwa źródła i informację o deduplikacji, a następnie porównaj liczbę zdarzeń z liczbą zamówień w sklepie. Jeśli Meta pokazuje prawie dwa razy więcej zakupów, event_id w Pikselu i CAPI się różnią.

Czy CAPI ma sens przy małym budżecie reklamowym?

Tak, jeśli sprzedajesz przez kampanie Meta, bo algorytm potrzebuje poprawnych danych niezależnie od budżetu. Przy małym sklepie wystarczy zwykle prostsza metoda, np. oficjalna integracja, zamiast rozbudowanego serwera tagowania.

Chcesz uporządkować pomiar Meta Ads w sklepie?

Zacznij od prostego testu: porównaj liczbę zakupów w Menedżerze zdarzeń z liczbą zamówień w sklepie za ostatni miesiąc. Jeśli różnica jest duża albo nie wiesz, jak ją interpretować, umów bezpłatną, 20–30-minutową rozmowę z Netexo. Pracujemy z Warszawy dla sklepów z całej Polski. Sprawdzimy, które zdarzenia warto poprawić najpierw, bez zobowiązań. Jeśli wolisz zacząć od rozmowy o samych kampaniach, wybierz konsultację Facebook Ads.

Tematy

analityka e-commerce Conversions API deduplikacja zdarzeń Meta Ads Meta CAPI Piksel Meta WooCommerce