Meta Conversions API: co wysłać z serwera i jak nie zdublować zakupu

Klient patrzy w Menedżerze zdarzeń Meta i widzi mniej zakupów, niż ma w sklepie. Nie dlatego, że piksel jest źle wklejony. Dlatego, że część zdarzeń nie dociera: przeglądarka zamyka stronę przed wysłaniem, blokada ucina żądanie, a po drodze ginie jeszcze to, co zależy od plików cookie.

Conversions API odpowiada na to jednym ruchem. To samo zdarzenie leci z serwera, niezależnie od tego, co zrobi przeglądarka. Cena jest jedna i łatwo ją przeoczyć. Dwa źródła tych samych zdarzeń bez wspólnego identyfikatora dają dwa zakupy zamiast jednego.

Co piksel traci po drodze

Dokumentacja Meta wymienia powody wprost: przeglądarka może się zawiesić, połączenie może paść, a ograniczenia w transmisji danych coraz częściej wycinają pliki cookie i sam piksel. Serwer tych warunków nie zna. Wysyła zdarzenie wtedy, gdy je zapisze, a nie wtedy, gdy użytkownik zdąży z kliknięciem.

Drugi powód jest mniej oczywisty i dla wielu firm ważniejszy. Serwer widzi dane, których przeglądarka nie ma: status leada z CRM, wartość klienta z historii zamówień, konwersję, która domyka się trzy dni po wizycie. Tego nie da się dopisać do zdarzenia, którego nikt nie wysłał.

I zastrzeżenie, żeby nie sprzedawać tego klientowi jako leku na wszystko. Conversions API nie naprawia zgody. Jeśli piksel nie ma podstawy, żeby wysłać zdarzenie, serwer też jej nie ma.

Czym to jest, a czym nie jest

Wysyłka to jedno żądanie POST pod adres https://graph.facebook.com/<wersja>/<PIXEL_ID>/events z tokenem dostępu. Ten sam punkt końcowy obsługuje zdarzenia z witryny, z aplikacji i ze sklepu stacjonarnego, więc nie trzeba trzymać trzech integracji.

Dane trafiają do tego samego zbioru danych, do którego pisze piksel. To nie jest drugi system pomiarowy ani kopia zapasowa. Meta pisze wprost, że przy istniejącym pikselu integrację buduje się jako rozszerzenie piksela, a nie jako osobne połączenie.

Trzy warianty wdrożenia

Pierwszy, zalecany, to wysyłka tych samych zdarzeń dwoma kanałami: piksel w przeglądarce i Conversions API z serwera. Warunkiem jest wspólny event_id. Bez niego wariant przestaje być zalecany i staje się źródłem podwójnego liczenia.

Drugi dzieli zdarzenia: na przykład odsłony i wyświetlenia produktu idą pikselem, a lead i zakup serwerem. Meta nazywa go gorszym od pierwszego i ostrzega, że przy zmianach w przeglądarkach trzeba będzie wracać do tematu.

Trzeci, tylko serwer, brzmi najczyściej i jest ostatni w kolejności. Dokumentacja mówi wprost: wdrażaj go po pierwszym albo drugim, nie zamiast nich.

Co musi być w żądaniu

Cztery pola są wymagane zawsze: event_name, event_time, user_data i action_source. Przy zdarzeniach z witryny dochodzą event_source_url i client_user_agent.

action_source mówi, gdzie doszło do konwersji, i ma zamkniętą listę wartości: website, app, email, phone_call, chat, physical_store, system_generated, business_messaging, other. Dla odnowienia subskrypcji z automatu właściwa jest system_generated, nie website.

event_time to znacznik Unix w sekundach, w GMT. Może być starszy niż moment wysyłki, ale nie więcej niż siedem dni. Jedno zdarzenie starsze w paczce wywala całe żądanie i Meta nie przetworzy żadnego rekordu z tej paczki.

Paczka mieści do tysiąca zdarzeń. Meta zaleca wysyłkę w godzinie od zdarzenia, bo opóźnienie psuje optymalizację dostarczania reklam.

Deduplikacja: event_id i event_name

Meta zna dwie metody. Zalecana to para event_id i event_name. W pikselu identyfikator jest czwartym argumentem wywołania:

fbq('track', 'Purchase', {value: 249, currency: 'PLN'}, {eventID: 'ZAM-1041'});

W Conversions API to pole event_id o tej samej wartości. Meta porównuje identyfikator i nazwę zdarzenia z tym samym identyfikatorem piksela w oknie 48 godzin i drugą kopię odrzuca.

Numer zamówienia jest najlepszym kandydatem na event_id, bo jest naturalnie niepowtarzalny. Przy zdarzeniach bez własnego numeru losowy ciąg działa, pod warunkiem że ten sam ciąg poleci w obu kanałach.

Druga metoda opiera się na fbp i external_id. Ma dwa ograniczenia, które trzeba znać przed wyborem: działa głównie wtedy, gdy zdarzenie z przeglądarki dotarło pierwsze, i nie deduplikuje nic, gdy źródło jest tylko jedno.

Jeszcze jedna reguła, która ratuje przy błędach. Jeśli w paczce jest zdarzenie niepoprawne, żądanie zwróci błąd, ale poprawna część z event_id zostanie przyjęta. Całą paczkę można więc wysłać ponownie bez ryzyka podwójnego liczenia.

Dopasowanie decyduje, czy zdarzenie się liczy

Zdarzenie przyjęte to nie to samo, co zdarzenie użyte. Meta rozdziela dopasowane od niedopasowanych: tylko dopasowane służą do atrybucji i optymalizacji dostarczania reklam. Niedopasowane zostają w pomiarze podstawowym i nic więcej.

Dlatego jakość danych klienta jest tu elementem wdrożenia, a nie dodatkiem. Największą wartość mają e-mail, numer telefonu, imię i nazwisko oraz adres IP. Meta ocenia je wskaźnikiem Event Match Quality w skali do dziesięciu punktów, dostępnym na razie dla zdarzeń z witryny.

Format jest sztywny. E-mail i telefon idą jako skrót SHA-256, po usunięciu spacji, literowania i zer na początku numeru, małymi literami. Adresu IP, przeglądarki oraz wartości fbp i fbc nie hashuje się wcale. Jeśli używasz Business SDK, hashowanie robi się samo.

Meta uznaje też zdarzenie za niepoprawne, gdy jedyne dane klienta to jeden z wąskich zestawów: miasto, kraj, region, kod pocztowy i przeglądarka, data urodzenia z przeglądarką, imię z płcią, nazwisko z płcią. Podzbiór takiego zestawu też jest niepoprawny. To nie jest błąd wdrożenia, tylko sygnał, że brakuje identyfikatora, który cokolwiek dopasuje.

Wartości fbp i fbc trzeba odświeżać, bo to dane cookie, a nie stałe identyfikatory.

Jak sprawdzić, czy działa

Test Events w Menedżerze zdarzeń generuje kod, który wysyłasz jako test_event_code. Dwie rzeczy trzeba z tego zapamiętać. Kod musi zniknąć z produkcyjnego żądania. I zdarzenia testowe nie są odrzucane: wchodzą do Menedżera i liczą się w pomiarze oraz w targetowaniu.

Po wdrożeniu wracasz do widoku źródeł danych i kolumny Sposób połączenia. Widać tam, którym kanałem przyszło zdarzenie, oraz liczby surowych, dopasowanych i przypisanych zdarzeń. Pierwsze dane pojawiają się w około dwadzieścia minut.

Zgoda i granica hashowania

Meta pisze wprost: jeśli masz logikę zgody dla piksela, użyj tej samej logiki dla Conversions API. To wygodne zdanie i zarazem pułapka, bo pozwala uznać, że temat jest zamknięty. Nie jest. Zapis informacji na urządzeniu wymaga zgody z art. 399 PKE w standardzie z art. 400 PKE, a wysyłka zdarzenia z danymi klienta to osobne przetwarzanie z podstawą z art. 6 ust. 1 lit. a RODO.

Hash nie jest anonimizacją. Zestaw skrótów e-maili to nadal dane osobowe w rozumieniu art. 4 pkt 5 RODO, bo dopóki masz listę źródłową, da się je przypisać do osoby. Kto tego nie zapisze w rejestrze czynności, ten przy pierwszej kontroli tłumaczy się z decyzji, której nigdzie nie podjął.

Praktyczna granica jest prosta. Do user_data nie wysyłaj niczego, czego nie wysłałbyś w formularzu, i niczego, na co nie masz zgody w tym konkretnym celu. Różnica między pikselem a serwerem nie zmienia zakresu danych, zmienia tylko kanał.

Decyzja na jedno zdanie

Zanim włączysz Conversions API, odpowiedz, czym jest ten sam zakup w obu kanałach. Jeśli odpowiedź brzmi numer zamówienia, wdrożenie jest proste. Jeśli brzmi nie wiem, najpierw uporządkuj identyfikator, bo bez niego lepsza wysyłka tylko szybciej pokaże podwójne liczby.