Tracking konwersji przy płatności za pobraniem i zewnętrzne checkouty

Tracking konwersji przy płatności za pobraniem oznacza wysyłanie każdego zakupu do platform reklamowych z samego zamówienia, na serwerze, zamiast polegać na pikselu w przeglądarce na stronie z podziękowaniem. Zamówienia z aplikacji do płatności za pobraniem, zewnętrznych checkoutów, formularzy zamówień i lejków sprzedażowych często kończą się poza zwykłym checkoutem, więc piksel je pomija albo raportuje w złym momencie.

Ten poradnik wyjaśnia, dlaczego te zamówienia giną i dlaczego status płatności ma znaczenie. Porównuje trzy momenty wysłania zakupu: gdy zamówienie jest utworzone, gdy jest potwierdzone i gdy jest opłacone. Opisuje też odrzucone zamówienia i zwroty oraz to, jak ROASaurus obsługuje zewnętrzne checkouty.

Dlaczego piksele pomijają zamówienia z płatnością za pobraniem?

Piksel w przeglądarce raportuje zakup, gdy kupujący trafia na stronę, która go uruchamia. Zwykle jest to strona z podziękowaniem w twoim checkoucie. Każda ścieżka zamówienia, która pomija tę stronę albo uruchamia ją na innej domenie, traci zdarzenie zakupu albo kliknięcie w reklamę, które do niego należy.

Samo zamówienie nigdy nie ginie. Trafia do twojego sklepu internetowego albo narzędzia lejka z numerem zamówienia, kwotą, adresem e-mail i często numerem telefonu. Dlatego niezawodnym rozwiązaniem jest wysyłanie zakupu z danych zamówienia, server-side, i przenoszenie kliknięcia w reklamę do zamówienia. Ogólną metodę wyjaśnia artykuł server-side tracking w Shopify. Ten wpis opisuje zamówienia, które wymagają dodatkowej uwagi.

Niektóre aplikacje do płatności za pobraniem wysyłają też własne zdarzenia piksela. Jeśli używają tego samego piksela co twój server-side tracking, ale innego event id, platforma liczy zamówienie dwa razy. Wyłącz te zdarzenia z aplikacji albo wykonaj kroki, żeby zapobiec podwójnemu liczeniu.

Dlaczego status płatności ma znaczenie

Płatność kartą jest pobierana w checkoucie, więc zamówienie jest opłacone w chwili, gdy powstaje. Zamówienie za pobraniem jest inne. Shopify traktuje płatność za pobraniem jako ręczną metodę płatności, a takie zamówienia mają status Payment pending, dopóki nie oznaczysz ich jako opłaconych. W praktyce dzieje się to po odebraniu gotówki przez kuriera, co może zająć kilka dni. Niektóre zamówienia nie są opłacone nigdy, bo kupujący odmawia przyjęcia paczki albo nie ma go w domu.

Wiele konfiguracji trackingu wysyła zakup, gdy zamówienie zostaje opłacone, bo dla zamówień kartą to najbezpieczniejszy moment. Przy zamówieniu za pobraniem ta sama reguła oznacza, że zakup dociera z kilkudniowym opóźnieniem albo wcale. Poniższy log pokazuje typowy przypadek w sklepie, który wysyła zakupy w momencie płatności.

WooCommerce działa odwrotnie. Ustawia zamówienia za pobraniem na Processing, dopóki płatność nie zostanie odebrana, z wyjątkiem zamówień z produktem do pobrania, które trafiają na On hold. Konfiguracja wysyłająca zamówienia w statusie Processing wysyła je więc od razu po złożeniu. Sprawdź, jaki status twoja platforma nadaje tym zamówieniom, zanim zdecydujesz cokolwiek innego.

Utworzone, potwierdzone czy opłacone: kiedy wysłać zakup?

Do wyboru są trzy momenty. Każdy zamienia szybkość na dokładność.

Dlaczego spóźnione zdarzenia zakupu to problem

Platformy reklamowe przypisują zakup do reklamy tylko wtedy, gdy nastąpi w oknie atrybucji po kliknięciu. Przy ustawieniu atrybucji 7 dni od kliknięcia w Meta zakup liczy się dla reklamy do 7 dni po kliknięciu. Conversions API Meta odrzuca też zdarzenia, których event_time jest starszy niż 7 dni, i odrzuca całe żądanie, gdy jedno zdarzenie jest zbyt stare. Zakup wysyłany przy płatności ma więc dwie złe opcje:

• Wysłać go z czasem zamówienia. Jeśli płatność przyszła ponad 7 dni później, Meta go odrzuci.
• Wysłać go z czasem płatności. Meta go przyjmie, ale kliknięcie w reklamę może mieć już ponad 7 dni, więc zakup nie zostanie przypisany do reklamy.

Szybkość ma też znaczenie dla optymalizacji. Kampanie optymalizowane pod zakupy uczą się na zakupach, które wysyłasz. Sygnał spóźniony o tydzień mówi algorytmowi o odbiorcach z zeszłego tygodnia.

Który moment wybrać

W większości sklepów z płatnością za pobraniem lepszym domyślnym wyborem jest wysyłanie przy utworzeniu zamówienia. Sygnał jest natychmiastowy, kliknięcie nadal mieści się w oknie i nic nie jest odrzucane. Koszt jest taki, że odrzucone zamówienia liczą się jako zakupy w Ads Manager. Korygujesz to w swoich celach, jak pokazuje następna sekcja.

Jeśli twój zespół potwierdza każde zamówienie telefonicznie lub wiadomością przed wysyłką, potwierdzenie to dobry kompromis. Usuwa fałszywe zamówienia i zwykle następuje w ciągu doby. Użyj go, gdy twój własny system może wysłać zakup w tym momencie, na przykład przez API. Fałszywe zamówienia znaczą więcej, niż się wydaje: jeśli platforma reklamowa uczy się na nich, szuka kolejnych osób, które składają zamówienia i ich nie płacą.

Jak obsłużyć odrzucone zamówienia, anulowania i zwroty

Gdy zakup zostanie wysłany, zostaje w Ads Manager. Paczka odrzucona pod drzwiami go nie usuwa. ROASaurus nie wysyła też zwrotów ani anulowań do Meta, TikTok i większości innych platform reklamowych, więc raportowany przez nie przychód obejmuje zamówienia, za które nigdy nie otrzymano pieniędzy. Tylko wartości w Google Ads i Microsoft Advertising można skorygować po zwrocie, gdy korekty wartości są włączone. Rozwiązaniem jest zmierzenie odsetka odmów i skorygowanie liczb, z którymi porównujesz.

Oto przykład obliczeń dla jednego miesiąca. Dla prostoty ceny są bez VAT.

Przy $3,000 wydatków na reklamy ten sam miesiąc wygląda bardzo różnie w zależności od tego, którego przychodu użyjesz:

Wskaźnik marży brutto na dostarczonym przychodzie to $3,878 ÷ $8,200 = 47.3%, więc ROAS progu rentowności wynosi 1 ÷ 0.473 = 2.11. Ten próg dotyczy dostarczonego przychodu. Ads Manager liczy też odrzucone zamówienia, więc musisz go przeliczyć, zanim porównasz. Artykuł ROAS progu rentowności wyjaśnia podstawowy wzór.

Wynik możesz sprawdzić bezpośrednio. Reklamy wychodzą na zero, gdy wydatki na reklamy równają się zyskowi brutto $3,878, a $10,000 raportowanego przychodu ÷ $3,878 = 2.58.

Wskaźniki odmów często różnią się w zależności od regionu, produktu i kampanii. Gdy masz dość zamówień, licz je dla każdej kampanii i użyj kalkulatora POAS, żeby sprawdzić wynik na zysku brutto.

Zwroty i anulowania w twoich własnych liczbach

W Shopify anulowania i zwroty trafiają do ROASaurus przez webhook, więc analityka zysku odejmuje zwroty od przychodu. Sam wybierasz, czy liczyć anulowane zamówienia, które nigdy nie zostały zrealizowane, i domyślnie są pomijane. Anulowane zamówienie, które zostało już wysłane, zostaje w danych, bo jego wysyłka nadal kosztowała cię pieniądze. Dla niedawnych zamówień, które jeszcze mogą wrócić, ustawienie Predicted returns wstrzymuje oczekiwaną część sprzedaży, dopóki nie pojawią się prawdziwe zwroty.

Jak ROASaurus obsługuje płatność za pobraniem i zewnętrzne checkouty

Shopify

Każdy sklep Shopify ma Checkout type w Store settings, z dwiema opcjami:

• Shopify checkout: zakup jest wysyłany, gdy Shopify zgłasza zamówienie jako opłacone, przez webhook orders/paid.
• External / COD checkout: zakup jest wysyłany, gdy zamówienie zostaje utworzone, przez webhook orders/create. Użyj go dla płatności za pobraniem i dla zewnętrznych checkoutów, takich jak CheckoutChamp czy Checkify, które same tworzą zamówienie w Shopify.

Ustawienie dotyczy każdego zamówienia w sklepie. Zamówienia kartą, opłacane w checkoucie, są tworzone i opłacane niemal w tej samej chwili, więc wybór zmienia głównie moment wysłania nieopłaconych zamówień. Każde zamówienie jest wysyłane raz. Gdy później przychodzi aktualizacja o opłaceniu zamówienia za pobraniem, drugi zakup nie jest wysyłany.

Zakup korzysta z własnych danych zamówienia: kwoty, waluty, produktów oraz e-maila, telefonu i adresu kupującego, zahashowanych, zanim opuszczą sklep. ROASaurus dopasowuje zamówienie do kliknięcia w reklamę przez visitor id, który jego skrypt zapisuje w koszyku. Gdy zamówienie go nie niesie, ROASaurus próbuje po kolei: tokenów koszyka i checkoutu, zdarzenia zakupu z checkoutu, adresu e-mail podanego wcześniej przez odwiedzającego na twojej stronie oraz tego samego adresu IP i przeglądarki tuż przed zamówieniem, gdy pasuje dokładnie jeden odwiedzający. Pełną konfigurację opisuje strona integracji z Shopify.

WooCommerce i inne sklepy internetowe

Wtyczka WooCommerce wysyła zamówienie, gdy osiągnie status Processing lub Completed. Zamówienia za pobraniem trafiają do Processing w chwili złożenia, więc są wysyłane od razu. Zamówienia z przelewem bankowym są wysyłane, gdy przechodzą do Processing. Pozostałe konektory sklepów wysyłają zamówienie w tych momentach:

• Wix, Squarespace, Ecwid, Lightspeed, CCV Shop i Shopware: gdy status płatności zamówienia to opłacone.
• BigCommerce: gdy zamówienie osiąga status taki jak Awaiting Fulfillment, Awaiting Shipment, Shipped lub Completed.
• Magento: gdy stan zamówienia to Processing lub Complete.
• PrestaShop: gdy zamówienie zostaje oznaczone jako ważne.
• Własny webhook i API zamówień: gdy twój własny system wyśle zamówienie.

Sprawdź, jak twoja platforma oznacza zamówienia za pobraniem. Jeśli pozostają nieopłacone, dopóki kurier nie wypłaci gotówki, ich zakupy docierają z opóźnieniem.

Lejki i własny checkout

1. Dodaj skrypt do stron lejka

   Użyj tego samego klucza sklepu co w twoim sklepie internetowym, żeby odwiedzający zachował jeden visitor id na obu domenach.

2. Wypisz swoje domeny

   W Store settings dodaj domeny lejka i sklepu w sekcji Linked domains. Linki między tymi domenami przenoszą wtedy visitor id i click id.

3. Wysyłaj zamówienia przez API zamówień

   Jeśli lejek sam przyjmuje zamówienie, wysyłaj każde zamówienie na /api/v1/orders, podając cookie _tl jako visitor_id. Moment wybiera twój system: przy utworzeniu, potwierdzeniu lub płatności.

4. Sprawdź Event log

   Gdy pojawią się pierwsze prawdziwe zamówienia, otwórz Event log i sprawdź, czy każde zostało wysłane do każdej podłączonej platformy.

POST /api/v1/orders
X-Roasaurus-Key: <store key>
Authorization: Bearer <API key>
Content-Type: application/json

{
  "order_id": "F-20931",
  "created_at": "2026-10-20T14:05:00Z",
  "total": 50.00,
  "currency": "USD",
  "email": "buyer@example.com",
  "phone": "+15555550123",
  "country": "US",
  "visitor_id": "<value of the _tl cookie>",
  "click_ids": { "fbc": "<_fbc cookie>", "fbp": "<_fbp cookie>" },
  "client_ip": "203.0.113.7",
  "user_agent": "Mozilla/5.0 ...",
  "items": [{ "variant_id": "SKU1", "quantity": 1, "price": 50.00 }]
}

API zamówień zachowuje pierwszą kopię każdego order id. Jeśli twój system wywołuje je przy utworzeniu i ponownie przy płatności, tylko pierwsze wywołanie wysyła zakup. Więcej szczegółów w artykule lejki i wiele domen.

Typowe błędy, których warto unikać

• Czekanie na status opłacone w sklepie z płatnością za pobraniem. Zakupy docierają z tygodniowym opóźnieniem albo wcale, a spóźnione zdarzenia są odrzucane lub wypadają poza okno atrybucji.
• Porównywanie ROAS z Ads Manager z progiem rentowności liczonym dla opłaconych zamówień. Najpierw podziel próg rentowności przez swój wskaźnik opłacenia.
• Dwa źródła dla jednego zakupu. Własny piksel aplikacji z formularzem i twoje zdarzenia server-side liczą to samo zamówienie dwa razy. Zobacz zduplikowane zdarzenia zakupu.
• Gubienie kliknięcia między domenami. Lejek na innej domenie potrzebuje skryptu i połączonych domen, bo inaczej jego zamówienia docierają bez kliknięcia w reklamę.
• Pomijanie zamówień ręcznych. Zamówienia telefoniczne i z czatu nie mają sesji w przeglądarce, ale nadal mają adres e-mail lub numer telefonu. Wysłane z danych zamówienia dają platformie reklamowej coś do dopasowania.

Źródła

1. Meta for Developers: Server Event Parameters
2. Shopify: WebhookSubscriptionTopic (GraphQL Admin API)
3. Shopify Help Center: Manual payment methods
4. Shopify Help Center: Understanding your order statuses
5. WooCommerce: Cash on Delivery documentation

W ROASaurus

• Integracja ze Shopify
• Integracja z WooCommerce
• Pomoc: lejki i wiele domen
• Analityka zysku w ROASaurus

Czytaj dalej