Meta Conversions API: co to jest, czym różni się od Pixela i czego nie zrobi

Meta Conversions API (w skrócie CAPI) to sposób, żeby Meta dowiedziała się o konwersji od Ciebie, a nie od przeglądarki klienta. Twój serwer, sklep albo CRM wysyła zdarzenie: „ta osoba kupiła za 349 zł”, „to zamówienie zostało opłacone”. Meta łączy je z kontami użytkowników i wykorzystuje do mierzenia i optymalizacji reklam. Ten przewodnik wyjaśnia, jak to działa, czym CAPI różni się od Pixela i, co równie ważne, czego nie zrobi.

Czym jest Meta Conversions API?

Conversions API to interfejs Meta, przez który system firmy wysyła zdarzenia marketingowe bezpośrednio z serwera. Dokumentacja Meta opisuje go jako połączenie danych reklamodawcy z systemami reklamowymi Meta i wymienia zdarzenia ze strony, z aplikacji, z wiadomości oraz konwersje offline, także te pochodzące z CRM.

W praktyce zdarzenie to mała paczka danych:

• co się stało (event_name, np. Purchase, Lead, QualifiedLead),
• kiedy (event_time, czas w sekundach Unix),
• gdzie (action_source, np. website dla zakupu w sklepie internetowym albo system_generated dla zdarzenia z systemu),
• kto (user_data: zahashowany e-mail, telefon, identyfikator leada z Meta, dla stron także IP i User-Agent),
• ile (custom_data: wartość i waluta, jeśli to sprzedaż),
• unikalny identyfikator (event_id), żeby to samo zdarzenie nie liczyło się dwa razy.

Meta nie pobiera opłat za samo wysyłanie zdarzeń. Płacisz za wdrożenie: programistę, partnera albo narzędzie, które robi to za Ciebie.

Pixel a Conversions API: jaka jest różnica?

Pixel to skrypt na stronie, który wysyła zdarzenia z przeglądarki. Conversions API wysyła je z serwera. Różnica nie polega na tym, że jedno jest „nowsze”, tylko na tym, co każde z nich widzi.

Meta w dokumentacji deduplikacji pisze wprost, że dla najlepszych wyników zaleca wdrożenie Conversions API razem z Pixelem. To oznacza dwa kanały dla tych samych zdarzeń, więc potrzebna jest deduplikacja.

Jak działa deduplikacja Pixela i CAPI?

Meta uznaje dwa zdarzenia za to samo, gdy mają tę samą nazwę i ten sam identyfikator: eventID w Pixelu i event_id w Conversions API. Działa to tylko wtedy, gdy drugie zdarzenie dotrze w ciągu 48 godzin od pierwszego. Jeśli treść się nie różni, Meta zwykle zostawia to, które przyszło pierwsze. Szczegóły i typowe błędy opisujemy w artykule o deduplikacji zdarzeń z Pixela i CAPI.

Zdarzeń, których Pixel nigdy nie wysyła (np. zakupu z zamówienia telefonicznego), deduplikować z Pixelem nie trzeba. Wciąż jednak trzeba pilnować, żeby Twój system nie wysłał tego samego zdarzenia dwa razy.

Jakie dane przyjmuje Conversions API?

Meta przyjmuje dane klienta tylko w określonej postaci. Część pól trzeba znormalizować i zahashować SHA-256 przed wysyłką, część wysyła się jawnie. Według listy parametrów klienta:

Hashowanie nie czyni danych anonimowymi w sensie prawnym. To nadal dane osobowe, więc potrzebujesz podstawy prawnej i informacji dla klientów. Szerzej piszemy o tym w artykule o RODO i hashowaniu w Conversions API (to nie jest porada prawna).

Im więcej poprawnych identyfikatorów, tym łatwiej Meta dopasuje zdarzenie do osoby. Meta pokazuje to w Menedżerze zdarzeń jako jakość dopasowania zdarzeń. Jak ją podnieść, wyjaśnia poradnik o Event Match Quality.

Limit czasu: 7 dni

Parametry zdarzenia serwerowego mówią jasno: event_time może być najwyżej 7 dni wcześniejszy niż wysyłka. Jedno za stare zdarzenie w paczce powoduje odrzucenie całego żądania. Dlatego wysyłka „raz w miesiącu z eksportu” nie zadziała. Zdarzenia trzeba wysyłać na bieżąco, najlepiej od razu albo co najmniej raz dziennie.

Ważne jest też, żeby event_time był rzeczywistym czasem zdarzenia, a nie czasem wysyłki. Zakup z poniedziałku wysłany w środę ma mieć datę poniedziałkową.

Co Conversions API daje, a czego nie?

CAPI daje Meta dane, których bez niego by nie miała. To wszystko. Reszta zależy od tego, co z tymi danymi zrobisz w kampaniach i co zrobi z nimi Meta.

Co realnie zyskujesz:

• Meta widzi konwersje, których Pixel nie zobaczy: zamówienie potwierdzone po płatności, zakup bez powrotu na stronę podziękowania, sprzedaż przez telefon.
• Możesz wybrać w kampanii cel oparty na tych zdarzeniach, np. optymalizację pod zakupy z zamówień sklepu wysyłanych z serwera.
• Decydujesz, które dane wychodzą z firmy i w jakiej postaci.

Czego CAPI nie robi:

• Nie gwarantuje niższego kosztu ani wyższego zwrotu. Meta może lepiej optymalizować, mając lepsze dane, ale wynik zależy od kampanii, budżetu, oferty i jakości danych.
• Nie dowodzi atrybucji. To, że Meta przyjęła zakup, nie znaczy, że kupił on z powodu reklamy.
• Nie potwierdza dopasowania. Odpowiedź events_received: 1 oznacza tylko, że Meta przyjęła zdarzenie.
• Nie ustawia kampanii. Samo wysyłanie zdarzenia Purchase z serwera nie sprawia, że jakikolwiek zestaw reklam się pod nie optymalizuje. To wybór w Menedżerze reklam.

Jak wdrożyć Conversions API?

Są trzy drogi. Wybór zależy od tego, skąd pochodzą Twoje konwersje.

1. Gotowa integracja platformy. Wiele platform sklepowych i CRM ma wbudowane połączenie z Meta. Jeśli Twoja je ma i obejmuje potrzebne zdarzenia, to zwykle najprostsza droga.
2. Własna integracja. Programista wysyła zdarzenia z Waszego serwera. Pełna kontrola, ale też pełna odpowiedzialność: kolejka, ponawianie błędów, deduplikacja, hashowanie, wersje Graph API.
3. Narzędzie pośredniczące. Usługa, która zbiera konwersje z kilku źródeł i wysyła je do Meta za Ciebie.

Basketly jest narzędziem trzeciego typu. Zbiera konwersje z Arkuszy Google, potwierdzonych zamówień ze sklepu (Shoper, IdoSell, BaseLinker) i z własnego API, a potem wysyła je przez trwałą kolejkę. Ty ustawiasz przepływ: który status ze źródła odpowiada któremu zdarzeniu Meta. Zamówienia ze Shopera Basketly czyta sam przez API sklepu i webhooki, a opłacone wysyła jako zakupy; ten sam zakup może też iść z serwera do Google Analytics 4 i TikToka.

Co robi kolejka, gdy coś pójdzie nie tak?

Integracja, która wysyła zdarzenie raz i zapomina, gubi dane przy każdej awarii sieci. W Basketly każde zdarzenie czeka w trwałej kolejce, aż Meta je przyjmie:

• błędy sieci, przeciążenie i limity zapytań Meta powodują do 6 prób z rosnącym odstępem,
• każda próba ma ten sam event_id, więc Meta może zdeduplikować powtórkę,
• to samo zdarzenie biznesowe (źródło, identyfikator, status) wchodzi do kolejki raz,
• zdarzenia starsze niż 7 dni są odrzucane od razu, z czytelnym komunikatem, a nie po cichu przez Meta.

Wynik każdej wysyłki widać w panelu. „Przyjęte przez Meta” oznacza odpowiedź z events_received: 1, nic więcej.

Najpierw test, potem produkcja

Meta ma w Menedżerze zdarzeń narzędzie testowe: zdarzenia wysłane z kodem testowym widać na żywo i nie mieszają się z produkcją. W Basketly tryb testowy to osobny odbiorca z tym kodem. Testy i produkcja mają osobną deduplikację, a przejście na produkcję to świadome utworzenie nowego odbiorcy. Opis wszystkich funkcji wysyłki znajdziesz na stronie Meta Conversions API w Basketly.

Kiedy Basketly nie jest dobrym wyborem?

Uczciwie: nie każdy potrzebuje osobnego narzędzia.

• Sklep ma natywną integrację z Meta, która wysyła serwerowe zakupy z deduplikacją. Wtedy kolejne narzędzie dla samego Purchase niczego nie doda.
• Potrzebujesz zdarzeń przeglądarkowych (wyświetlenie produktu, dodanie do koszyka). Basketly nie zastępuje Pixela ani menedżera tagów i nie wysyła zdarzeń z przeglądarki.
• Potrzebujesz zdarzeń z aplikacji mobilnej. Tego Basketly nie obsługuje.
• Konwersje masz tylko w eksporcie raz w miesiącu. Limit 7 dni Meta i tak to wyklucza.

Jeśli natomiast sprzedaż kończy się poza stroną, w rozmowie, w CRM albo w arkuszu, to właśnie te zdarzenia najtrudniej przekazać Meta i tu narzędzie pośredniczące ma sens.

Następny krok

Zacznij od jednego źródła i trybu testowego: połącz konto Meta, wybierz Pixel, dodaj sklep albo arkusz i sprawdź w Menedżerze zdarzeń, czy zdarzenie testowe dotarło. Plany i limity są w cenniku.