Shoper i Meta Conversions API: jak wysyłać zamówienia jako serwerowe zdarzenia Purchase

Zamówienie ze Shopera jako serwerowe zdarzenie Purchase to zakup, który do Meta wysyła serwer, a nie przeglądarka klienta. Taki zakup nie znika, gdy klient ma blokadę reklam, nie kliknie zgody albo zamknie kartę przed stroną podziękowania. Poniżej: jakie pola Meta wymaga, dlaczego zakupu nie może potwierdzać skrypt w przeglądarce, jak nie policzyć zamówienia dwa razy i jak to skonfigurować w Convs. Na końcu uczciwie: czego obecna wersja jeszcze nie robi.

Dlaczego Pixel w sklepie to za mało?

Pixel to skrypt w przeglądarce. Wysyła Purchase tylko wtedy, gdy strona podziękowania się załaduje, skrypt nie jest zablokowany, a klient zgodził się na pliki cookies marketingowe. Każdy z tych warunków czasem zawodzi, a Ty nie wiesz, ile zakupów w ten sposób przepada.

Meta sama zaleca, żeby Conversions API działało obok Pixela, a nie zamiast niego. Serwer widzi każde opłacone zamówienie, więc może wysłać Purchase niezależnie od tego, co stało się w przeglądarce. Dzięki temu Meta dostaje dane, których potrzebuje do optymalizacji kampanii sprzedażowych.

Ważne zastrzeżenie: lepsze dane to nie gwarancja lepszych wyników. Conversions API daje Mecie pełniejszy obraz zakupów, ale nie dowodzi, że kampania jest optymalizowana pod te zdarzenia, ani nie rozstrzyga atrybucji. Więcej o tym w artykule Meta Conversions API: co to jest.

Jakie pola musi mieć serwerowy Purchase?

Serwerowy Purchase ze sklepu to zdarzenie typu website. Meta wymaga dla niego kilku pól, a przy braku któregoś zdarzenie zostanie odrzucone albo słabo dopasowane do użytkownika.

Dwie rzeczy łatwo przeoczyć. Po pierwsze, client_user_agent to przeglądarka klienta, a nie Twojego serwera. Po drugie, czas ma znaczenie: Meta w przewodniku wdrożenia zaleca wysyłkę w czasie rzeczywistym albo w ciągu godziny od zdarzenia. Zakup wysłany z dużym opóźnieniem jest mniej przydatny do optymalizacji. Jakie dane klienta najbardziej pomagają w dopasowaniu, opisujemy w tekście o Event Match Quality.

Dwie części: skrypt po zgodzie i potwierdzenie z serwera

W Convs źródło Shoper składa się z dwóch elementów, które mają różne zadania i różny poziom zaufania.

Skrypt kolektora: tylko identyfikatory, tylko po zgodzie

Skrypt kolektora instalujesz w sklepie i wywołujesz z banera zgód (CMP). Przed zgodą niczego nie zapisuje i nie wysyła. Po zgodzie:

• korzysta z istniejącego ciasteczka _fbp albo tworzy własny identyfikator, więc działa także bez Pixela,
• zapisuje _fbc i prawdziwy parametr fbclid z linku reklamy; nigdy nie tworzy fbc bez rzeczywistego kliknięcia,
• trzyma identyfikator w przeglądarce do 30 dni i zwraca tracking_id, który trzeba dołączyć do zamówienia.

Wycofanie zgody (setConsent(false)) usuwa stan w przeglądarce i dane przypisania po stronie serwera. Nie cofa konwersji, które już trafiły do Meta.

Skrypt nie wysyła Purchase z przeglądarki i nie dodaje drugiego Pixela. To celowe: publiczny klucz zna każdy, kto otworzy stronę, więc nie może on potwierdzać zakupów.

Adapter serwerowy: potwierdzony zakup

Zakup potwierdza Twój serwer, czyli kod, który widzi opłacone zamówienie w Shoperze. Wysyła je do Convs żądaniem z prywatnym tokenem źródła:

POST /api/ingest/SOURCE_ID
Authorization: Bearer PRYWATNY_TOKEN_ŹRÓDŁA
Content-Type: application/json

{
  "external_id": "ORDER-123",
  "status": "purchase",
  "event_id": "purchase_ORDER-123",
  "event_time": "2026-05-12T12:00:00Z",
  "email": "klient@example.com",
  "value": 149.99,
  "currency": "PLN",
  "consent": true,
  "tracking_id": "IDENTYFIKATOR_ZE_SKRYPTU",
  "event_source_url": "https://twojsklep.pl/checkout/complete"
}

Hub sprawdza zamówienie, zanim cokolwiek trafi do kolejki:

1. Źródło Shoper przyjmuje wyłącznie status purchase.
2. event_id jest obowiązkowy, bo bez niego nie ma deduplikacji z Pixelem.
3. Zakup bez value i poprawnego kodu waluty jest odrzucany.
4. Adres strony musi należeć do domeny sklepu podanej w źródle; parametry i fragment adresu są usuwane przed zapisem i wysyłką.
5. Bez User-Agenta klienta (ze skryptu albo z adaptera) zdarzenie nie przejdzie.
6. E-mail i telefon są normalizowane i hashowane SHA-256. IP i User-Agent nie są hashowane, zgodnie z wymaganiami Meta.

Jeśli skrypt nie zebrał danych, adapter może sam przekazać client_user_agent i client_ip_address prawdziwego klienta. Nigdy nie wysyłaj adresu IP ani User-Agenta własnego serwera.

Pole consent: true oznacza, że Twój proces potwierdza właściwą podstawę prawną przekazania danych. Nie ustawiaj go automatycznie bez sprawdzenia. Szerzej o tym w tekście RODO i Conversions API (to nie jest porada prawna).

Jak nie policzyć zamówienia dwa razy?

Jeśli w sklepie działa już Pixel wysyłający Purchase, Meta dostanie ten sam zakup dwa razy: z przeglądarki i z serwera. Zliczy go raz tylko wtedy, gdy oba zdarzenia mają tę samą nazwę i ten sam identyfikator: eventID w Pixelu i event_id w Conversions API. Meta deduplikuje pary, które dotrą w ciągu 48 godzin.

Najprostsza zasada: identyfikator buduj z numeru zamówienia, np. purchase_ORDER-123, i używaj go w obu miejscach. Jeśli obecny Pixel w sklepie nie pozwala ustawić eventID, podwójnej wysyłki nie da się uczciwie uznać za rozwiązaną. Wtedy masz dwie drogi: zmienić sposób instalacji Pixela albo nie wysyłać Purchase z jednego z kanałów. Szczegóły i typowe błędy opisuje artykuł o deduplikacji zdarzeń Pixela i CAPI.

Po stronie huba działa druga warstwa ochrony: ta sama kombinacja zbioru danych, nazwy zdarzenia, event_id i trybu (test lub produkcja) nie trafi do kolejki dwa razy. Ponowne wysłanie tego samego zamówienia przez adapter nie tworzy więc drugiego zdarzenia.

Konfiguracja krok po kroku

Całość zajmuje zwykle 2–3 godziny, z czego większość to praca programisty nad adapterem serwerowym. Sama konfiguracja w panelu to kilkanaście minut.

1. Odbiorca testowy. Połącz konto Meta, wybierz konto reklamowe i Pixel, ustaw tryb Testowanie zdarzeń z kodem z Menedżera zdarzeń. Testy i produkcja mają osobną deduplikację.
2. Źródło Shoper. Dodaj źródło i podaj adres sklepu. W instrukcji źródła znajdziesz skrypt, publiczny klucz i prywatny token.
3. Skrypt i zgody. Wywołuj setConsent(true) z banera zgód dopiero po zgodzie marketingowej, a setConsent(false) przy jej wycofaniu. getLastError() pokaże, czy coś poszło nie tak.
4. tracking_id w zamówieniu. Zapisz identyfikator ze skryptu przy zamówieniu mechanizmem, który obsługuje Twój sklep (np. ukryte pole lub atrybut zamówienia).
5. Adapter serwerowy. Po potwierdzeniu płatności wyślij zamówienie na adres źródła z prywatnym tokenem.
6. Przepływ. Zmapuj status purchase na zdarzenie Purchase i włącz przepływ.
7. Test. Złóż zamówienie testowe i sprawdź je w zakładce testowania zdarzeń w Menedżerze zdarzeń. Meta podaje, że zdarzenie powinno być widoczne w ciągu około 20 minut.
8. Produkcja. Utwórz osobnego odbiorcę produkcyjnego i nowy przepływ. Hub nie zmienia po cichu przeznaczenia zdarzeń, które już czekają w kolejce.

Co dzieje się po wysłaniu?

Zamówienie trafia do trwałej kolejki. Jeśli Meta odpowie błędem sieci, limitem zapytań (429) albo błędem serwera, hub ponawia wysyłkę do 6 razy z rosnącymi odstępami i respektuje nagłówek Retry-After. Ponowienie zachowuje ten sam event_id, więc Meta może je zdeduplikować. Inne błędy trafiają do ręcznej obsługi, a operator może ponowić wysyłkę po naprawie przyczyny.

Status „przyjęte przez Meta” oznacza odpowiedź z events_received: 1. To potwierdzenie odbioru, a nie dowód jakości dopasowania, celu kampanii ani atrybucji. Więcej o kolejce i diagnostyce na stronie Meta Conversions API.

Ograniczenia: kiedy to nie wystarczy

Zanim zaczniesz, sprawdź, czy te ograniczenia Ci nie przeszkadzają:

• Nie ma jeszcze gotowego adaptera API ani webhooków Shopera. Hub ma kolektor i bezpieczny adres do przyjmowania zamówień, ale kod, który odczyta opłacone zamówienie ze Shopera i wyśle je dalej, trzeba dopasować do Twojego sklepu.
• Zapisanie tracking_id przy zamówieniu też jest po stronie sklepu. Bez tego zakup nadal dotrze do Meta, ale bez identyfikatorów kliknięcia.
• Tylko potwierdzone zakupy. Źródło Shoper nie wysyła koszyków, rozpoczętych płatności ani zwrotów.
• Limit 7 dni. Zamówienia starsze niż 7 dni Meta odrzuci; hub nie wyśle ich wcale.
• Raport kampanii obejmuje w tej wersji leady z formularzy Meta, nie zamówienia ze sklepu.

Jeśli masz dużą liczbę zdarzeń sklepowych poza zakupem (oglądanie produktów, dodanie do koszyka) i chcesz je wszystkie wysyłać z serwera, lepszym wyborem będzie integracja na poziomie platformy sklepu lub serwerowy menedżer tagów. Convs skupia się na jednym, pewnym zdarzeniu: potwierdzonym zakupie.

Następny krok

Załóż organizację, dodaj testowego odbiorcę Meta i źródło Shoper, a potem przekaż programiście kontrakt zamówienia z tego artykułu. Plany i limity zamówień miesięcznie znajdziesz w cenniku.