BLIK, Przelewy24, PayU: czemu Pixel gubi te zakupy i jak je odzyskać

Fakty w skrócie (stan na 2026-10-29)

• Pixel odpala zakup na stronie podziękowania, więc zakup bez powrotu klienta na tę stronę nie trafia do Pixela.
• Przelewy24 wysyła powiadomienie o statusie niezależnie od tego, czy klient wrócił na adres powrotu (dokumentacja REST).
• PayU wysyła powiadomienia asynchronicznie po zmianie statusu płatności i oczekuje odpowiedzi HTTP 200.
• Basketly czyta opłacone zamówienie ze sklepu i wysyła zakup z serwera; bez zgody klienta i skryptu w sklepie przypisanie do reklamy bywa słabsze.
• Przyjęcie zdarzenia przez Metę nie dowodzi optymalizacji ani przypisania zakupu reklamie.

W polskich sklepach popularne są płatności online przez BLIK, Przelewy24 i PayU. Wszystkie mają jedną cechę wspólną dla Pixela: zanim zamówienie zostanie opłacone, klient opuszcza sklep (do banku, do aplikacji bankowej, do strony operatora). Co się wtedy dzieje ze zdarzeniem Purchase?

Co się dzieje przy przekierowaniu do banku

Pixel Mety jest kodem JavaScript na stronie. Dokumentacja Mety każe wywołać zdarzenie zakupu na stronie potwierdzenia zakupu. W typowym sklepie wygląda to tak:

1. Klient składa zamówienie i wybiera Przelewy24.
2. Sklep rejestruje transakcję u operatora i wysyła klienta na jego stronę.
3. Klient płaci w banku.
4. Operator przekierowuje klienta na adres powrotu w sklepie. To jest strona podziękowania z kodem Pixela.

Krok 4 jest jedynym momentem, w którym przeglądarka może wysłać zakup do Mety. Jeśli klient go nie wykona, Pixel milczy, mimo że zamówienie jest opłacone. Przelewy24 opisuje oba adresy osobno: urlReturn to adres, na który wraca klient, a urlStatus to adres, na który operator wysyła status transakcji. W dokumentacji REST czytamy, że powiadomienie jest wysyłane niezależnie od tego, czy klient został przekierowany na adres urlReturn. PayU działa podobnie: powiadomienia o statusie wysyła asynchronicznie, zaraz po zmianie statusu płatności i oczekuje odpowiedzi HTTP 200.

Sklep wie więc o opłaceniu zamówienia z serwera operatora. Przeglądarka klienta może o tym nie wiedzieć nigdy.

Dlaczego klient bywa nieobecny w kroku 4? Wymieniamy to, co jest możliwe technicznie, bez podawania skali, której nie mamy zmierzonej: zamknięcie karty zaraz po potwierdzeniu w aplikacji banku, utrata połączenia, bank bez automatycznego powrotu, strona podziękowania, która nie ładuje się pełnym kodem, albo blokada skryptu w przeglądarce. Wszystkie kończą tak samo: zamówienie opłacone, zdarzenia nie ma.

Drugi skutek przekierowania to jakość danych. Po powrocie z banku adres strony może nie mieć już parametrów z reklamy, więc przypisanie zakupu do kliknięcia bywa słabsze. Nie znamy jednak skali tego zjawiska w polskich sklepach, więc traktuj to jako ryzyko do sprawdzenia, a nie liczbę.

Jak rozpoznać problem w Menedżerze zdarzeń

Objaw jest jeden: opłaconych zamówień online jest więcej niż zdarzeń Purchase z przeglądarki. Sprawdzenie zajmuje kwadrans:

1. Weź pełny dzień sprzed co najmniej dwóch dni. Policz opłacone zamówienia według metody płatności: BLIK, Przelewy24, PayU osobno od karty i płatności przy odbiorze.
2. W Menedżerze zdarzeń otwórz zdarzenie Purchase i zobacz, ile zdarzeń z przeglądarki odebrano tego dnia.
3. Jeśli braki koncentrują się w płatnościach z przekierowaniem, a karta „się zgadza”, przyczyna jest właśnie tu. Jeśli braki są równomierne, szukaj gdzie indziej: zgody na cookies i blokery opisujemy w tekście Dlaczego Meta pokazuje mniej zakupów niż sklep.
4. Zrób zamówienie testowe w trybie testowym operatora, zamknij kartę zaraz po zapłacie i sprawdź, czy zdarzenie powstało.

Nie ma tu żadnej uniwersalnej liczby. BLIK nie „zawsze” gubi zakup. U jednych sklepów klient po płatności grzecznie wraca, u innych nie. Dlatego mierz u siebie.

Trzy sposoby naprawy

1. Odpalaj zakup po potwierdzeniu płatności, nie po złożeniu zamówienia

Jeśli Twój Pixel wysyła zakup już przy składaniu zamówienia (zanim bank potwierdzi płatność), liczysz też zamówienia nieopłacone i porzucone. Zakup powinien odpalać się dopiero na stronie, która pokazuje się po potwierdzeniu płatności. To porządkuje liczby, ale nie rozwiązuje przypadku, gdy klient nie wraca.

2. Wtyczka lub bramka, która wysyła zdarzenie z serwera po powiadomieniu operatora

Część wtyczek sklepowych wysyła zakup do Conversions API w momencie, gdy sklep dostaje powiadomienie o płatności. To właściwy kierunek, ale sprawdź w jej ustawieniach, czy: używa wspólnego identyfikatora zdarzenia z Pixelem (inaczej dubel; patrz Meta liczy zakupy podwójnie) i czy zna statusy płatności Twojego operatora.

3. Zakup z zamówienia, z oddzielnego narzędzia

Opłacone zamówienie jest faktem zapisanym w sklepie, niezależnie od przeglądarki. Narzędzie czytające zamówienia z API sklepu może wysłać z niego zakup do Mety z serwera. O różnicy między Pixelem, Conversions API i bramką piszemy w co to jest Meta Conversions API. Tak działa Basketly.

Co zrobić dziś, zanim zmienisz cokolwiek w sklepie

Zanim wybierzesz rozwiązanie, zmierz skalę. Trzy pytania pomagają ją ocenić bez żadnego dodatkowego narzędzia:

• Jaki odsetek opłaconych zamówień w ostatnim tygodniu przyszedł przez płatność z przekierowaniem, a jaki przez kartę lub przy odbiorze? Dane są w panelu sklepu i u operatora płatności.
• Czy brak zdarzeń Purchase koncentruje się w tych płatnościach?
• Czy kampanie optymalizujesz pod zakupy? Jeśli tak, brak części zakupów w Pixelu oznacza, że Meta widzi mniej sygnałów, niż się wydarzyło w sklepie. Jak bardzo to wpływa na wyniki, zależy od Mety i nie da się tego zmierzyć z zewnątrz, więc nie podajemy liczby.

Jeśli odpowiedź na pierwsze dwa pytania brzmi „znacząca”, warto rozważyć drogę z serwera.

Jak Basketly czyta zakup z zamówienia

Basketly nie czeka na powrót klienta. Opłacone zamówienie w sklepie staje się zakupem:

• Shoper: Basketly zakłada w sklepie własny webhook (m.in. zamówienie opłacone), a dodatkowo czyta zamówienia co 15 minut, więc zakup nie zginie, gdy pojedyncze powiadomienie nie dojdzie. Opłacone = flaga „opłacone” w Shoperze albo status, który wskażesz (np. za pobraniem).
• IdoSell, BaseLinker, WooCommerce, Shopify: zamówienia są czytane co 15 minut; zakup powstaje, gdy płatności pokrywają wartość zamówienia albo status jest jednym z wybranych.
• Wysyłka: zakup trafia do kolejki z ponawianiem, ma stały identyfikator z numeru zamówienia i jest wysyłany do Mety z serwera. Meta przyjmuje zdarzenia do 7 dni wstecz.

Co zobaczysz: w Zamówieniach opłacone zamówienie jest od razu po odczycie, a w Konwersje → Bilans zakupów widzisz, że liczba zakupów przyjętych przez Metę zbliża się do liczby opłaconych zamówień także dla płatności z przekierowaniem. Kolumna Źródło pokazuje kanał ostatniego kliknięcia według odczytu Basketly, o ile wizyta klienta była zapisana.

Pixel możesz zostawić. Pamiętaj tylko o wspólnym identyfikatorze zdarzenia albo o wyłączeniu zakupu w jednym z kanałów. Więcej o zakupie z zamówienia w Shoperze w tekście Shoper i Meta Conversions API.

Czego Basketly nie rozwiąże

• Słabszego przypisania do reklamy bez zgody. Zakup czytany z API sklepu nie niesie danych z przeglądarki (np. kliknięcia fbc) i trafia do Mety jako zdarzenie generowane przez system. Skrypt Basketly w sklepie dołączy je tylko po zgodzie klienta i tylko gdy zamówienie da się powiązać z wizytą. Bez tego Meta ma mniej do dopasowania, a przypisanie bywa słabsze. Basketly to ogranicza, nie usuwa.
• Pixela w przeglądarce. Nie naprawiamy go ani nie zmieniamy wtyczki sklepu.
• Opóźnienia odczytu. Platformy poza Shoperem czytamy co 15 minut, więc zakup z tych sklepów pojawia się z takim opóźnieniem.
• Dowodu optymalizacji. Przyjęcie zakupu przez Metę nie znaczy, że kampania optymalizuje pod niego ani że przypisano go reklamie.
• Zakupów starszych niż 7 dni.

Następny krok

Zrób punkty 1 i 2 z listy „Jak rozpoznać problem” dla wczorajszego dnia, z podziałem na metodę płatności. Jeśli chcesz zobaczyć, jak wygląda Bilans zakupów i lista zamówień, otwórz demo. Aby podłączyć własny sklep, załóż konto; limity planów opisuje cennik. Cały mechanizm kolejki znajdziesz na stronie Konwersje.

Źródła

• Przelewy24: dokumentacja REST (urlReturn, urlStatus, powiadomienie niezależne od powrotu klienta)
• PayU: Payment lifecycle (notifyUrl, powiadomienia asynchroniczne, odpowiedź HTTP 200)
• Meta for Developers: Meta Pixel, śledzenie konwersji (zdarzenie Purchase na stronie potwierdzenia zakupu)
• Meta for Developers: Server Event Parameters (czas zdarzenia do 7 dni wstecz, action_source, event_id)
• Meta for Developers: Deduplicate Pixel and Server Events (wspólny identyfikator i nazwa, okno 48 godzin)