Meta Conversions API (CAPI): praktyczny poradnik

Meta Conversions API (CAPI) pozwala twojemu serwerowi wysyłać zdarzenia, takie jak Purchase, prosto do Meta. Piksel Meta wysyła te same zdarzenia z przeglądarki kupującego. CAPI wysyła je z twojego serwera, więc docierają nawet wtedy, gdy bloker reklam zatrzyma piksel, cookie zniknie albo strona z podziękowaniem nigdy się nie załaduje.

Ten poradnik wyjaśnia, co zawiera zdarzenie Conversions API, jak uruchomić je obok piksela z jednym event_id, jakich parametrów Meta wymaga i jakie zaleca, jak testować w Test events oraz jakie błędy pojawiają się najczęściej.

Czym jest Meta Conversions API?

Conversions API jest częścią Graph API Meta. Twój serwer wysyła żądanie HTTPS POST na adres graph.facebook.com/VERSION/PIXEL_ID/events z tokenem dostępu i listą data zawierającą do 1,000 zdarzeń. Każde zdarzenie opisuje jedną akcję, na przykład zakup, w trzech częściach: co się stało, kto to zrobił i szczegóły.

Skrócone zdarzenie Purchase wygląda tak:

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1792929600,
    "event_id": "order-1042",
    "action_source": "website",
    "event_source_url": "https://yourstore.com/checkouts/thank-you",
    "user_data": {
      "em": ["<SHA-256 of the normalized email>"],
      "ph": ["<SHA-256 of the normalized phone>"],
      "client_ip_address": "203.0.113.24",
      "client_user_agent": "Mozilla/5.0 (iPhone; ...)",
      "fbp": "fb.1.1792928400000.1234567890",
      "fbc": "fb.1.1792928400000.AbCdEf123"
    },
    "custom_data": { "value": 74.00, "currency": "USD" }
  }]
}

Pola kontaktowe, takie jak e-mail i telefon, są normalizowane i hashowane algorytmem SHA-256, zanim opuszczą twój serwer. Adres IP, user agent, fbp i fbc są wysyłane w niezmienionej postaci.

Po co uruchamiać Conversions API obok piksela?

Meta zaleca uruchamianie Conversions API obok piksela i wysyłanie tych samych zdarzeń obiema drogami. Każda strona widzi coś, czego druga nie widzi, a razem dają Meta pełniejsze dane.

Ceną za uruchomienie obu jest to, że Meta dostaje teraz dwie kopie każdego zdarzenia. Następna sekcja pokazuje, jak Meta zachowuje tylko jedną.

Jak działa deduplikacja z jednym event_id?

Meta traktuje zdarzenie z przeglądarki i zdarzenie z serwera jako to samo zdarzenie, gdy zgadzają się dwie rzeczy: nazwa zdarzenia i event id. W pikselu id trafia do opcji eventID. W Conversions API ta sama wartość trafia do event_id.

fbq('track', 'Purchase', { value: 74.00, currency: 'USD' }, { eventID: 'order-1042' });

Meta deduplikuje pasującą parę tylko wtedy, gdy obie kopie dotrą w ciągu 48 godzin od siebie. Kilka zasad sprawia, że w praktyce to działa:

• Utwórz id tylko raz. Zbuduj je z czegoś, co znają obie strony, na przykład z numeru zamówienia, i przekaż zarówno przeglądarce, jak i serwerowi. Dwa systemy, które tworzą własne id, nie będą do siebie pasować.
• Używaj jednego formatu. order-1042 i 1042 to różne id.
• Dopasuj nazwę zdarzenia co do znaku. Purchase i purchase to różne zdarzenia.
• Wysyłaj zdarzenie z serwera szybko. Zdarzenie z serwera, które dociera po więcej niż 48 godzinach od zdarzenia z przeglądarki, jest liczone drugi raz.

Meta opisuje też drugą metodę, która łączy zdarzenia w pary po fbp lub external_id. Według Meta zwykle działa ona tylko wtedy, gdy zdarzenie z przeglądarki dociera przed zdarzeniem z serwera, więc wspólny event_id jest pewniejszym wyborem. Jeśli Meta nadal raportuje więcej zakupów, niż miał twój sklep, nasz poradnik o zduplikowanych zdarzeniach zakupu wymienia typowe przyczyny.

Które parametry są wymagane, a które zalecane?

Wymagane pola sprawiają, że zdarzenie jest poprawne. Zalecane pola decydują o tym, ile twoich zdarzeń Meta może dopasować do osoby, a tylko dopasowane zdarzenia można wykorzystać do atrybucji i dostarczania reklam.

Trzy szczegóły powodują większość problemów:

• Normalizuj przed hashowaniem. Meta oczekuje e-maila bez spacji na brzegach i małymi literami oraz numerów telefonu jako cyfr z kodem kraju. Anna@Example.com i anna@example.com dają różne hashe i tylko drugi może się dopasować.
• Nie hashuj identyfikatorów przeglądarki. fbp, fbc, adres IP i user agent trafiają jako zwykłe wartości.
• Zachowaj click id dokładnie w takiej postaci, w jakiej jest. Wartość fbc to fb.1., czas utworzenia w milisekundach, kropka i fbclid z adresu URL strony docelowej. fbclid rozróżnia wielkość liter. Zapisz go, gdy odwiedzający wejdzie na stronę, bo w checkoucie nie ma go już w adresie URL.

To, jak dobrze te pola się dopasowują, mierzy wynik Event Match Quality w Meta. Nasz poradnik o Event Match Quality omawia każdy parametr, zasady hashowania i wynik, do którego warto dążyć.

Jak testować zdarzenia w Test events?

Events Manager ma kartę Test events, która pokazuje zdarzenia w miarę ich nadchodzenia. Użyj jej, zanim zaczniesz polegać na nowej konfiguracji.

1. Otwórz Test events

   W Events Manager wybierz swój zestaw danych (piksel) i otwórz kartę Test events. Skopiuj pokazany tam kod testowy.

2. Dodaj kod do swoich zdarzeń z serwera

   Wyślij go jako test_event_code w żądaniu. W ROASaurus wklej go w pole Test event code piksela Meta.

3. Złóż zamówienie testowe

   Wejdź do sklepu, dodaj produkt i zapłać, żeby zarówno piksel, jak i serwer wysłały Purchase.

4. Porównaj obie kopie

   Obie kopie powinny pokazywać tę samą nazwę zdarzenia, event id, wartość i walutę.

5. Sprawdź dane klienta

   Zdarzenie z serwera powinno zawierać zahashowany e-mail i telefon, adres IP, user agent i fbp, a także fbc, jeśli wizyta zaczęła się od kliknięcia w reklamę.

6. Usuń kod testowy

   Meta mówi, że to pole służy tylko do testów, więc usuń je, zanim zaczniesz polegać na zdarzeniach.

Częste błędy Conversions API i jak je naprawić

Po kilku dniach rzeczywistego ruchu otwórz kartę Diagnostics w Events Manager. Meta wymienia tam problemy wraz z zaleceniami, jak je naprawić. Potem porównaj dzienną liczbę zdarzeń Purchase w Events Manager z opłaconymi zamówieniami w twoim sklepie z tych samych dni. Jeśli Meta jest wyraźnie wyżej, nasza strona pomocy o zapobieganiu podwójnemu liczeniu wymienia ustawienia do sprawdzenia.

Jak skonfigurować Conversions API z ROASaurus

ROASaurus wysyła zdarzenia Conversions API z danych zamówień twojego sklepu, więc nie musisz sam budować strony serwerowej. W Tracking & platforms kliknij Connect with Facebook i wybierz swoje konto reklamowe i piksel albo wklej id piksela (zestawu danych) i token Conversions API. Poradnik konfiguracji Meta przeprowadza przez obie opcje, a strona integracji z Meta wymienia każde wysyłane pole.

• Jedno id po obu stronach. Zdarzenia z przeglądarki i z serwera mają wspólny event id. Dla zakupu to order- z dopisanym id zamówienia.
• Krótkie wstrzymanie przed zakupem. Purchase z serwera czeka chwilę po nadejściu zamówienia, żeby można było najpierw dołączyć zdarzenie zakupu z przeglądarki. Jego adres IP, user agent i adres URL strony trafiają wtedy ze zdarzeniem z serwera, razem z fbp i fbc zapisanymi dla odwiedzającego.
• Dane klienta z zamówienia. E-mail, telefon, imię i nazwisko oraz adres są normalizowane i hashowane algorytmem SHA-256. Id klienta ze sklepu i visitor id z ROASaurus trafiają zahashowane jako external_id.
• Zdarzenia, których Meta nie może dopasować, są pomijane. Zdarzenie bez fbc, fbp, e-maila, telefonu ani adresu IP nie jest wysyłane.

Event log pokazuje każdą wysyłkę z serwera wraz z żądaniem i odpowiedzią Meta. Jeśli twoje marże mocno różnią się między produktami, możesz też wysyłać wartość zysku obok każdego zakupu: wyjaśnia to nasz poradnik o optymalizacji wartości w Meta pod zysk. Pełną ścieżkę danych od kliknięcia do zamówienia opisuje server-side tracking.

Źródła

1. Meta for Developers: Handling Duplicate Pixel and Conversions API Events
2. Meta for Developers: Server Event Parameters
3. Meta for Developers: Customer Information Parameters
4. Meta for Developers: Using the API - Conversions API
5. Meta for Developers: ClickID and the fbp and fbc Parameters

W ROASaurus

• Integracja z Meta
• Pomoc: połącz Meta
• Pomoc: zapobieganie podwójnemu liczeniu
• Server-side tracking

Czytaj dalej