Facebook Conversions API - kompletny poradnik konfiguracji

Pixel działa w przeglądarce, a CAPI odbiera zdarzenia wysłane z serwera lub obsługującej go integracji. Dzięki temu informacja potwierdzona przez system sklepu może trafić do Meta także inną drogą niż skrypt strony. Nie oznacza to odzyskania każdej brakującej konwersji ani automatycznej poprawy kosztu reklamy. Trzeba odróżnić dostarczenie zdarzenia od dopasowania go do użytkownika oraz przypisania reklamie.

Przed wdrożeniem zapisz, co uznajesz za Purchase albo Lead. Zakup może oznaczać przyjęcie zamówienia lub potwierdzenie płatności; wybór powinien być świadomy i spójny z raportami. Lead nie powinien oznaczać samego kliknięcia przycisku, jeżeli formularz mógł zwrócić błąd. Zdarzenie musi odpowiadać działaniu, które naprawdę wystąpiło.

Dane wysyłane serwerowo nadal wymagają oceny dopuszczalnego wykorzystania. CAPI nie zastępuje zgód, informacji dla użytkownika ani ustalenia podstawy przetwarzania. Haszowanie adresu e-mail nie rozwiązuje tych kwestii. Gdy podstawą jest zgoda, art. 7 RODO dotyczy między innymi jej wykazania i wycofania. Zakres dla konkretnej witryny ustal z osobą odpowiedzialną za prywatność.

Zacznij od sprawdzenia możliwości swojej platformy. Integracja partnerska może ograniczyć ilość własnego kodu, ale trzeba ustalić, jakie zdarzenia wysyła, kiedy je uruchamia i jak uwzględnia wybór użytkownika. Nie zakładaj, że każde zdarzenie widoczne w Pixelu ma automatycznie odpowiednik serwerowy.

Dobrym przykładem jest opis udostępniania danych Meta w Shopify. Dokumentacja rozróżnia poziomy udostępniania i opisuje serwerowy Purchase przy odpowiednich ustawieniach. Sam fakt połączenia kont nie wystarcza więc do oceny zakresu pomiaru.

Serwerowy Google Tag Manager daje dodatkowy punkt przetwarzania danych i wymaga hostingu oraz utrzymania kontenera. Własna integracja z backendem lub CRM daje kontrolę nad momentem wysyłki, lecz wymaga obsługi błędów, ponowień i zmian API. Rozwiązania typu Gateway również mają własne wymagania infrastrukturalne. Wybór powinien wynikać z potrzeb i możliwości utrzymania, a nie z obietnicy bezpłatnego wdrożenia.

W ustaleniach zapisz oddzielnie pracę wdrożeniową, opłaty narzędzi, infrastrukturę i późniejszy monitoring. Potrzebny jest też właściciel integracji: osoba, która zauważy błąd autoryzacji lub brak zdarzeń po aktualizacji sklepu. Instalację samego skryptu przeglądarkowego opisuje poradnik konfiguracji Pixela Facebooka.

Dla każdego zdarzenia przygotuj prostą specyfikację: nazwa, rzeczywisty moment wystąpienia, system potwierdzający akcję, identyfikator, wartość i waluta, dostępne dane dopasowania oraz warunek dopuszczający wysyłkę. Taka tabela pozwala sprawdzić implementację bez zgadywania, co autor wtyczki rozumiał przez zakup.

Przy Purchase ustal sposób traktowania rabatów, dostawy i podatków. Ważniejsza od wyboru jednej uniwersalnej definicji jest jej zgodność między systemem sprzedaży a raportem. Nie przesyłaj ceny produktu zamiast wartości zamówienia tylko dlatego, że ta pierwsza zmienna jest łatwiej dostępna.

Zgody i ograniczenia powinny docierać do miejsca podejmowania decyzji o wysyłce. Sprawdź również wycofanie zgody i zdarzenia powstające później, na przykład po aktualizacji statusu w CRM. Nie traktuj braku informacji o wyborze użytkownika jako automatycznego pozwolenia. Własna polityka danych powinna określać, co integracja robi w takim przypadku.

Nie uzupełniaj brakujących danych fikcyjnym e-mailem, IP serwera ani losowym identyfikatorem kliknięcia. Niepoprawne wartości mogą sprawiać wrażenie kompletnego payloadu, choć nie opisują rzeczywistej akcji. Ogranicz też zawartość logów: do diagnozy zwykle potrzebujesz statusu, czasu i identyfikatora technicznego, a nie pełnej treści zamówienia.

Dokumentacja rozpoczęcia integracji Meta opisuje uzyskanie tokenu przez Events Manager lub własną aplikację. Token CAPI umieść wyłącznie w chronionej konfiguracji serwerowej lub konfiguracji zaufanej integracji. Nie wklejaj go do webowego kontenera GTM, HTML, publicznego repozytorium czy zrzutów ekranu.

Ustal dostęp do sekretu, sposób wymiany po ujawnieniu i reakcję na błędy autoryzacji. Nie opieraj utrzymania na założeniu, że token będzie działał bezterminowo. Przykłady w dokumentacji traktuj jako objaśnienie struktury, nie jako gotowe żądania do wysłania z danymi produkcyjnymi.

Specyfikacja parametrów serwerowych Meta określa event_time jako czas rzeczywistego zdarzenia w sekundach Unix. Nie przekazuj milisekund i nie podmieniaj czasu starego zakupu na bieżący, aby ponowić wysyłkę. Limit wynosi 7 dni; zdarzenie starsze od limitu może spowodować odrzucenie całego żądania. Wysyłaj dane możliwie szybko i kontroluj zaległości kolejki.

Dla zdarzeń witryny sprawdź także action_source, event_source_url i wymagane dane przeglądarki. Adres źródłowy nie powinien przypadkowo ujawniać danych z formularza zapisanych w URL. Waliduj wartości i walutę przed wysyłką, zamiast odkrywać błędy dopiero w raporcie reklamowym.

Zgodnie z dokumentacją deduplikacji Meta zalecany mechanizm wykorzystuje nazwę zdarzenia i jego identyfikator. Pixel przekazuje eventID, a CAPI event_id. Dwie kopie tej samej akcji mają trafić do tego samego Pixel ID i używać zgodnej nazwy, na przykład Purchase. Dokumentacja opisuje okno odbioru 48 godzin.

Zespół dokumentacji Meta ujmuje to następująco:

Identyfikator powinien powstać raz dla konkretnej akcji i zostać udostępniony obu kanałom. Nie generuj niezależnych UUID w przeglądarce i na serwerze, bo ich wartości nie będą zgodne. Nie używaj też jednego stałego ID dla różnych zamówień. Jeżeli ten sam klient kupuje ponownie, to kolejne zdarzenie wymaga własnego identyfikatora.

Sprawdź ponowne wejście na stronę potwierdzenia i retransmisję po błędzie sieci. Przechowanie wspólnego ID pomaga zachować tożsamość akcji, lecz integracja musi również kontrolować własne ponowienia. Mechanizmu między Pixelem a CAPI nie należy traktować jako uniwersalnego usuwania wszystkich duplikatów w każdym źródle.

Browser i Server w Events Manager oznaczają kanały odbioru. O poprawności deduplikacji świadczy dopiero zgodność danych i odpowiednia diagnostyka. Nie wyciągaj wniosku o jej działaniu wyłącznie z obecności obu etykiet.

Dokumentacja danych klienta Meta rozróżnia pola wymagające haszowania i wyjątki. Dane kontaktowe, takie jak em i ph, przygotowuje się zgodnie z opisanymi zasadami normalizacji oraz SHA-256. IP, client_user_agent, fbc i fbp mają instrukcję, aby ich nie haszować.

Przed dodaniem własnego haszowania ustal, co robi używany SDK lub integracja. Meta Business SDK może wykonać je automatycznie. Podwójne przekształcenie albo niewłaściwa normalizacja utrudniają dopasowanie. Nie oceniaj poprawności po samym wyglądzie długiego ciągu znaków.

Event Match Quality pomaga ocenić dane dopasowania. Nie sprawdza jednak za Ciebie, czy Purchase odpowiada opłaconemu zamówieniu albo czy zgoda została prawidłowo obsłużona. Wysoki wynik nie potwierdza też rentowności kampanii. Nie ma powodu przedstawiać jednej wartości EMQ jako obowiązkowego progu odbioru każdej integracji.

Jeśli wynik budzi wątpliwości, sprawdź kompletność i prawidłowość dozwolonych parametrów dla danego zdarzenia. Nie rozszerzaj zbierania danych tylko po to, aby poprawić ocenę. Najpierw popraw błędy mapowania i wyjaśnij, jakich informacji rzeczywiście potrzebujesz.

W instrukcji używania CAPI Meta ostrzega, że zdarzenia z test_event_code nie są odrzucane i mogą służyć pomiarowi reklam oraz targetowaniu. Kod ułatwia diagnostykę, ale sam nie jest sandboxem. Nie wysyłaj więc sztucznego Purchase do produkcyjnego źródła tylko po to, aby zobaczyć zielony status.

Przygotuj środowisko i źródło danych przeznaczone do testów, odłączone od produkcyjnych kampanii. Użyj kontrolowanych danych, bez informacji prawdziwych klientów. Ustal również, czy scenariusz nie tworzy prawdziwych zamówień, wiadomości lub płatności. Test bramki płatniczej nie wyłącza automatycznie pozostałych integracji sklepu.

Sprawdź osobno poprawną akcję, odmowę odpowiednich zgód, brak wymaganego parametru, ponowienie i odświeżenie potwierdzenia. Zachowaj wynik oczekiwany i rzeczywisty. Sama odpowiedź API nie rozstrzyga jeszcze, czy kampania użyje zdarzenia zgodnie z zamierzeniem.

Przewodnik weryfikacji Meta rozdziela odbiór, świeżość, deduplikację i dopasowanie. Tak samo podziel protokół odbioru. Jeżeli prowadzisz też kampanie Google, osobne narzędzia opisuje diagnostyka konwersji przez GTM.

Przy odbiorze poproś o listę mierzonych akcji, ich definicje, schemat przepływu i wyniki kontrolowanych testów. Dokument powinien wyjaśniać, kto utrzymuje integrację i gdzie sprawdza błędy. Nie wystarczy informacja, że wtyczka jest aktywna albo Events Manager pokazuje jakieś zdarzenia.

Porównuj dane o tych samych akcjach w podobnym zakresie czasu. Liczba zdarzeń odebranych przez Meta nie jest tym samym co konwersje przypisane reklamie. Znaczenie ma także model atrybucji Facebook Ads. Różnica między systemami wymaga wyjaśnienia, a nie automatycznego uznania jednego za zepsuty.

Po zmianie checkoutu, CMP, wtyczki lub backendu wróć do kluczowych kontroli. Monitoruj brak zdarzeń, opóźnienia, błędy autoryzacji i niespodziewane powtórzenia. Publiczny skan strony może dostarczyć wskazówek o części tagów, ale nie potwierdzi całej konfiguracji serwerowej.

Jeśli potrzebujesz pomocy, sprawdź usługę pomiaru konwersji i napisz do nas. Wystarczy adres witryny lub platforma oraz opis problemu. Nazwę integracji i zdarzenia dopisz, jeśli je znasz; nie przesyłaj tokenów ani danych klientów.