InPost Pay: w moim sklepie 80 procent zakupów dochodziło do Ads bez danych

InPost Pay rośnie szybciej, niż większość sklepów zdążyła zauważyć. W dwudziestu największych sklepach na Shoperze jego udział w transakcjach podwoił się w osiem miesięcy, z niecałych siedmiu procent do ponad trzynastu (maj 2025). W całym 2025 roku liczba transakcji wzrosła trzykrotnie, a sklepów z tą płatnością jest już ponad 4 000. W sklepie, w którym go wdrożyłem, to już co trzecia płatność, a w mocniejszych tygodniach cztery na dziesięć.

Sklepy wdrażają go, bo podnosi konwersję w koszyku. To akurat prawda. Rzadko kto im mówi, że ta sama płytka wycina im atrybucję do Google Ads i do Mety, i że nie dowiedzą się o tym z żadnego panelu.

Mechanizm jest prosty, tylko nie taki, jak się zwykle opowiada. Kupujący klika przycisk InPost Pay, wiąże koszyk z aplikacją i płaci w aplikacji InPostu. Do przeglądarki wraca stamtąd dokładnie jedno zdarzenie, informacja o utworzeniu zamówienia, i to kanałem, który żyje dokładnie tak długo, jak długo żyje otwarta karta sklepu. Zdarzenia o zapłacie w tym kanale nie ma w ogóle.

Cały pomiar w przeglądarce jest więc zakładem o dwie rzeczy naraz: że karta przetrwa przełączenie do aplikacji i że kupujący do niej wróci. A nawet kiedy ten zakład wychodzi, zdarzenie zakupu opisuje zamówienie złożone, nie opłacone.

Jeśli sklep wysyła konwersje z serwera, zakup dochodzi do Google Ads goły: numer, kwota i tyle. Bez gclid, bez _ga, bez _fbp. Nie ma też stanu zgody z przeglądarki, więc przy uczciwym podejściu do zgód nie powinno się dosyłać nawet zahashowanego e-maila do Enhanced Conversions, choć sklep ma dane kupującego w zamówieniu. W panelu wygląda to zdrowo, bo liczba się zgadza i kwota się zgadza. Jeśli sklep mierzy tylko w przeglądarce, takiego zakupu nie ma w ogóle.

Zmierzyłem u siebie, ile to kosztuje. Ponad osiemdziesiąt procent zamówień InPost Pay nie miało żadnego sygnału z przeglądarki. Przelewy24 w tym samym sklepie i w tym samym tygodniu: 13 procent.

Potem sprawdziłem, czy to tylko mój problem. Przeskanowałem 499 polskich sklepów, które mają InPost Pay na koszyku, a na próbie z nich wszedłem prawdziwą przeglądarką z podstawionym identyfikatorem kliknięcia, żeby zobaczyć, co faktycznie zapisuje się w przeglądarce kupującego.

Wynik wyszedł inaczej, niż zakładałem. Identyfikator kliknięcia najczęściej jest zapisany. Na sklepach Shopera zapisuje go sama platforma: jej serwer ustawia własne ciastko, ważne 90 dni. Do InPost Pay ta wartość prawie nigdy nie trafia. W całych 499 sklepach znalazłem jeden, który świadomie włączył przekazywanie identyfikatorów, i był to sklep spożywczy na Magento.

To nie są sklepy, które nie mierzą. Prawie wszystkie mają GA4, ponad połowa menedżer tagów, jedna trzecia widoczne konwersje Google Ads, jedna czwarta piksel Meta. Mierzą wszystko poza tą jedną rzeczą i nie mają jak się dowiedzieć, że ta jedna rzecz im ucieka.

Ważne jest też to, co siedzi w tej luce, i do tego dojdę w trzeciej sekcji: to nie jest ogon bez wartości. Na mojej próbie przepadający klienci byli zaatrybuowani co najmniej tak dobrze jak średnia sklepu: kliknęli w reklamę, wyrazili zgodę i poszli zapłacić w aplikacji.

Poniżej: dlaczego żadna platforma tego nie robi, co dokładnie ucieka, i mechanizm, którym to odzyskałem, razem z tym, co w nim nie zadziałało.

Dlaczego InPost Pay znika z pomiaru

Standardowy pomiar zakupu w e-commerce wisi na stronie podziękowania. Tam odpala się tag, tam czyta się cookies, tam powstaje zdarzenie purchase z pełnym kontekstem. Cała konstrukcja zakłada, że kupujący tam dotrze.

InPost Pay łamie to założenie na dwa sposoby naraz. Po pierwsze, płatność dzieje się w aplikacji mobilnej, a nie na stronie sklepu. Po drugie, klient już powiązany z aplikacją InPostu przy kliknięciu w przycisk w ogóle nie przechodzi przez sklep, bo widget otwiera deep link prosto do aplikacji.

Warto to powiedzieć precyzyjnie, bo od tego zależy cała reszta, a obiegowa wersja „kupujący nie wraca” jest nieścisła. Na desktopie, przy otwartej karcie sklepu, zwykle wraca. Widać to w moich danych: dwie trzecie zakupów InPost Pay, przy których przeglądarka dała znać o zamówieniu, przyszło z desktopu. Przy Przelewy24 proporcja jest odwrotna, 70 procent to telefony.

Rzecz w tym, że kanał, którym InPost rozmawia z przeglądarką, niesie sześć rodzajów zdarzeń i ani jedno z nich nie dotyczy płatności. Informacje o autoryzacji płatności czy o rozliczeniu istnieją wyłącznie w komunikacji serwer do serwera. Przeglądarka kupującego strukturalnie nie ma jak się dowiedzieć, że zamówienie zostało opłacone.

Dlatego strona podziękowania w tym przepływie z definicji pokazuje się przed zapłatą, a nie po niej. Tak to opisuje sama dokumentacja InPostu: sklep wyświetla ją, gdy zamówienie jest złożone, ale nieopłacone. Jeśli więc odpali się tam zdarzenie zakupu, opisuje ono coś, za co jeszcze nikt nie zapłacił.

Do tego dochodzi warstwa mobilna. Przy kliknięciu z koszyka widget wykonuje twardą nawigację pod adres InPostu, nie doklejając adresu powrotnego - dokleja go tylko przy wejściu z karty produktu. Czyli z koszyka nie ma dokąd wrócić, a jeśli system nie przechwyci linku do aplikacji, strona sklepu przestaje istnieć razem z całym kanałem zdarzeń.

I rzecz, która najlepiej pokazuje asymetrię tej sytuacji. InPost liczy u siebie, ilu kupujących kliknęło w przycisk i ilu dojechało na stronę podziękowania. Telemetria widgetu wysyła oba te zdarzenia na serwery InPostu. Sprzedawca nie ma ani jednego z nich.

Efekt jest taki, że ta sama luka, którą znamy z gubionych konwersji przy przekierowaniu na bramkę płatniczą, przy InPost Pay robi się regułą, a nie wyjątkiem. Metoda płatności sama w sobie decyduje o tym, czy zdarzenie w ogóle powstanie.

W sklepie z pomiarem z serwera wygląda to po stronie Google Ads jak zdrowa konwersja. Liczba się zgadza, kwota się zgadza. Nie ma tylko niczego, po czym Google mógłby ją przypisać do kliknięcia, więc tag serwerowy melduje zero konwersji z gclid, a Smart Bidding uczy się na danych bez połowy sygnału.

Ile to naprawdę kosztuje, zmierzone

Tydzień pomiaru na jednym sklepie, tylko zamówienia opłacone:

Cztery zamówienia na dziesięć w całym sklepie bez danych, z czego 83 procent tej luki to sam InPost Pay. Dla porównania: w sklepie meblowym bez InPost Pay, na tej samej platformie i z tą samą konstrukcją pomiaru, pokrycie sygnałem z przeglądarki wynosi 99,4 procent.

To nie jest kwestia jakości wdrożenia. Ten sam kod, ta sama platforma, inny miks płatności i wynik gorszy o prawie czterdzieści punktów procentowych.

„Bez sygnału” znaczy tu: bez click-id, bez sesji GA4 i bez stanu zgody. Dane kupującego są w zamówieniu, ale bez zgody znanej z przeglądarki ich nie wysyłam, więc takie zamówienie idzie do Google Ads bez niczego, po czym dałoby się je dopasować do reklamy.

Ile to znaczy w innym sklepie, zależy od udziału InPost Pay i od tego, ilu kupujących płaci z telefonu. Przy średniej z dwudziestu największych sklepów Shopera, czyli około 13 procentach transakcji, podobna strata daje mniej więcej co dziesiąte zamówienie. U mnie było to co trzecie.

Przepadali dobrze zaatrybuowani klienci, nie ogon

Tu jest rzecz, która zmieniła moje myślenie o tym problemie. Brakujące zamówienia zwykle są gorsze od średniej: to ruch bez zgody, z adblockiem, z przypadku. Przy InPost Pay tak nie jest.

Wziąłem 24 koszyki odzyskane przez parowanie i sprawdziłem, co dokładnie w nich było. Obok wynik dla zamówień, przy których kupujący normalnie wrócił na stronę podziękowania, z siedmiu dni i próby 320 zamówień:

Grupa, która przepadała, wypadła lepiej od średniej sklepu w każdej kategorii. Trzeba to jednak czytać ostrożnie. 24 koszyki to mała próba i różnice mieszczą się w granicach błędu. Do tego parowanie obejmuje tylko koszyki z rozstrzygniętą zgodą, a w grupie porównawczej są też kupujący, którzy zgody nie rozstrzygnęli, więc zestawienie trochę faworyzuje koszyki InPost Pay. Wniosek, który się broni, jest skromniejszy: ta grupa nie jest gorsza od średniej. InPost Pay wybiera klient zalogowany w aplikacji, z zapisaną kartą, który kupuje szybko i świadomie.

Czyli sklep nie traci szumu. Traci kupujących, którzy w większości kliknęli w reklamę i zgodzili się na pomiar, a więc tych, których Google Ads i Meta potrzebują zobaczyć, żeby wiedzieć, na kogo licytować. Algorytm dostaje obraz, w którym reklama przyciąga ludzi, którzy nie kupują, bo część tych, którzy kupili, jest niewidzialna.

Jedno doprecyzowanie, żeby nie przesadzić w drugą stronę. Po stronie Mety strata dotyczy identyfikatora służącego do dopasowania użytkownika, a nie identyfikatora kliknięcia w reklamę Meta. Tego drugiego na tych koszykach nie było w ogóle, więc nie ma czego tracić. Prawdziwa dziura jest po stronie Google.

InPost to rozwiązał. Prawie

Zanim przejdę do własnego mechanizmu, muszę powiedzieć rzecz, która w dyskusji o InPost Pay prawie nie pada: InPost ma oficjalną ścieżkę przekazywania identyfikatorów reklamowych i ma ją od czerwca 2025 roku.

Składa się z dwóch części. Pierwsza to pole order_additional_parameters w API, czyli worek na pary klucz-wartość dopinany do zamówienia. Oficjalnie obsługuje client_id, gclid, fbclid, ttclid oraz identyfikatory Criteo i RTB House. Druga to gotowy mechanizm wysyłkowy: funkcja w chmurze Google, uruchamiana cyklicznie (domyślnie co cztery godziny, można częściej), która pobiera nowe zamówienia z API InPostu i rozsyła zdarzenie zakupu do GA4, Google Ads, Meta, TikTok i kilku innych systemów, z deduplikacją. Razem z zakupem wysyła zahashowane dane klienta, czyli e-mail, telefon, imię, nazwisko i adres, bo te sklep dostaje od InPostu w każdym zamówieniu.

Na papierze wygląda to jak rozwiązanie problemu. W praktyce zostaje osiem rzeczy.

Droga do Google Ads jest wolniejsza, niż sugeruje harmonogram. Sam cykl czterech godzin nie jest problemem: Google zaleca wysyłkę konwersji co najmniej raz dziennie i przypisuje je do daty kliknięcia. Problem zaczyna się dalej. Tryb zalecany przez InPost, czyli import z BigQuery, Google Ads wykonuje najwyżej raz na dobę. Bezpośredni upload przez Google Ads API od 15 czerwca 2026 nie przyjmuje nowych użytkowników, bo Google przenosi import konwersji na Data Manager API. A Meta zaleca wysyłkę w ciągu godziny od zakupu.

Sklep i tak musi zbudować całą warstwę przechwycenia sam. Dokumentacja mówi to wprost: bez tych parametrów system nie powiąże zakupów z kampaniami. Bez nich funkcja wyśle zakup tylko z danymi klienta, a te Google i Meta dopasują wyłącznie do osób zalogowanych na swoich kontach. InPost daje rurę, nie daje tego, co ma przez nią płynąć.

To nie jest przełącznik, tylko projekt wdrożeniowy. Uruchomienie wymaga własnego projektu w chmurze Google z płatnościami, narzędzi wiersza poleceń z wysokimi uprawnieniami i ręcznego odpalenia skryptu instalacyjnego, który zakłada tabele, funkcję i harmonogram w infrastrukturze sklepu. Do tego własne poświadczenia do każdego systemu reklamowego i token, który trzeba rotować co dwa miesiące. Żaden właściciel sklepu na platformie abonamentowej tego nie zrobi.

Apple wypada podwójnie. Brakuje identyfikatorów kliknięcia dla części ruchu z urządzeń Apple, a kupujący, który loguje się do InPost Pay kontem Apple, trafia do sklepu z zastępczym adresem e-mail w domenie InPostu. Takiego adresu Google ani Meta nie dopasują do nikogo, więc nawet poprawnie wdrożona ścieżka nie domyka wszystkiego.

Zgoda jest wpisana na sztywno. W kodzie funkcji, przy wysyłce do Google Ads, oba pola zgody mają stałą wartość GRANTED dla każdego zamówienia, z komentarzem, że tak ma być dla EEA. Funkcja czyta zamówienia z API i nie ma skąd wiedzieć, czy kupujący zgodził się na cokolwiek, bo stan zgody żyje w przeglądarce. Zahashowany e-mail wysłany z deklaracją zgody, której nikt nie sprawdził, to ryzyko, które bierze na siebie sklep.

Przechwyt identyfikatorów też nie pyta o zgodę. Dokumentacja radzi jednym zdaniem, żeby odpalać znacznik po zgodzie użytkownika. Sam snippet niczego nie sprawdza.

Nie ma nic o deduplikacji z własnym zdarzeniem zakupu sklepu. Kto włączy oba naraz, policzy transakcje podwójnie.

I najważniejsze: dokumentacja przechwytu istnieje dla integracji własnej, WooCommerce, PrestaShop i Magento. Dla Shopera i IdoSella nie ma jej wcale. Sklep na tych platformach może uruchomić samą funkcję, bo ma dostęp do API InPostu, ale identyfikatorów kliknięcia nie ma skąd do niej podać. Zostaje mu dopasowanie po danych klienta.

Co która platforma robi z tym problemem

Tu dochodzimy do sedna, bo to nie jest wada jednej platformy. To jest wada domyślnej konfiguracji na wszystkich naraz.

Przejrzałem kod integracji InPost Pay dla WooCommerce, PrestaShop, Magento i Shopware, publiczny moduł IdoSella, publiczny pakiet motywu Shoper Storefront oraz sam skrypt widgetu. Potem sprawdziłem, jak to wygląda w praktyce, na 499 sklepach, które mają InPost Pay na koszyku.

WooCommerce ma sytuację najbardziej absurdalną. Wtyczka odczytuje z pamięci przeglądarki trzy klucze z identyfikatorami, a w całym jej kodzie nie ma ani jednego miejsca, które te klucze zapisuje. Zapisać ma je sam sklepikarz, ręcznie utworzonym znacznikiem w menedżerze tagów, według instrukcji schowanej w dokumentacji InPostu. W panelu wtyczki nie ma o tym ani słowa, a opis ustawienia urywa się w pół zdania, bez odsyłacza. Na dodatek wtyczka podmienia stronę podziękowania na stronę wirtualną bez kontekstu zamówienia, przez co nie odpala się na niej żaden z popularnych dodatków pomiarowych dla tej platformy. Zbiera też atrybucję zamówienia i nadpisuje jej źródło na własne, bez możliwości wyłączenia.

PrestaShop wypada z tej czwórki najlepiej, jeśli chodzi o wtyczki InPostu. Odzyskuje identyfikatory z adresu i poprawnie przetwarza identyfikator klienta GA4, a po płatności przekierowuje na natywną stronę potwierdzenia, więc standardowe moduły pomiarowe mają szansę zadziałać. Ma jednak dwa haczyki: zbieranie danych jest domyślnie wyłączone, a identyfikator kliknięcia przechowuje przez godzinę, więc zakup dokonany później i tak przepada.

Magento zbiera najwięcej ze wszystkich, łącznie z identyfikatorami dla ruchu z urządzeń Apple, i jako jedyne bramkuje to zgodą. Ma też najstaranniejszy powrót: przed przekierowaniem odtwarza stan sesji zakupowej, więc natywna strona sukcesu dostaje dokładnie to, czego potrzebują jej tagi. A mimo to jest tu pułapka, której nie ma nigdzie indziej. Równolegle do tej drogi moduł wysyła zakup do GA4 z serwera, w momencie utworzenia zamówienia. Czyli ta sama transakcja potrafi polecieć dwa razy, a przed podwójnym policzeniem ratuje wyłącznie deduplikacja po numerze transakcji, o ile oba źródła wstawią ten sam numer. Przy kupującym, który nie wrócił, GA4 i tak dostanie zakup z serwera, więc raporty wyglądają zdrowo. Meta go nie zobaczy wcale, a Google Ads tylko przez import konwersji z GA4 i tylko wtedy, gdy identyfikator klienta dojdzie w poprawnym formacie.

Shopware ma najczystszą implementację z całej stawki, i to nie od InPostu, tylko od zewnętrznego dostawcy. Poprawnie zbiera, poprawnie przetwarza, a szablon strony potwierdzenia rozszerza natywny zamiast go zastępować, więc nic nie ginie po drodze.

IdoSell nie zbiera niczego. W całym module nie ma ani jednego odwołania do identyfikatorów reklamowych. Po utworzeniu zamówienia przekierowuje na własną stronę potwierdzenia, gdzie odpalają się natywne integracje platformy, więc dopóki karta przeglądarki żyje, coś zostaje policzone. Kanał do InPostu jest jednak pusty, więc oficjalna funkcja InPostu może wysłać zakup najwyżej z samymi danymi klienta, bez identyfikatora kliknięcia.

Shopify bywa wymieniany jako platforma, na której InPost Pay nie działa. To nieprawda: działa u tych sklepów, które zastąpiły natywną kasę własną aplikacją. Co ciekawe, ta implementacja jest jedyną ze wszystkich, które widziałem, wysyłającą prawdziwe zdarzenie zakupu do warstwy danych. Ktoś to zrobił, bo chciał, poza wtyczkami InPostu. Nie zapisuje za to identyfikatora kliknięcia na później, więc gubi każdego powracającego klienta.

Shoper jest przypadkiem najostrzejszym i wymaga osobnego akapitu, bo tam problem jest wbudowany w architekturę. Pakiet motywu Storefront jest publiczny, więc da się to sprawdzić. Moduł InPost Pay i moduł analityki nie stykają się w kodzie ani razu. Łączy je tylko szyna zdarzeń, a tam jest dziura: po utworzeniu zamówienia InPost Pay ogłasza zdarzenie bez żadnych danych, a moduł analityki nasłuchuje innego zdarzenia i przy pustych danych po prostu kończy. To zdarzenie z danymi emituje wyłącznie komponent strony podziękowania, w momencie wyrenderowania.

Innymi słowy: na Shoper Storefront zakup nie jest przypięty do zamówienia ani do płatności, tylko do wyrenderowania strony podziękowania w przeglądarce klienta. Nie ma żadnego zabezpieczenia po stronie serwera. Kontrakt między Shoperem a InPostem ma cztery pola i ani jedno z nich nie niesie identyfikatora pomiarowego, więc platforma nie ma nawet czym wypełnić tego, czego chce od niej InPost.

Skan: 499 sklepów i jeden, który to robi

Przy takim stanie integracji wynik skanu z początku tekstu przestaje dziwić. Ten jeden sklep, który przekazuje identyfikatory, to Magento, gdzie ktoś wszedł w konfigurację modułu i włączył opcję domyślnie wyłączoną. Nigdzie indziej nie ma czego włączać albo nikt tego nie zrobił.

Sam skan to jednak za słaby dowód, bo czyta kod stron. Dlatego na próbie sklepów wszedłem prawdziwą przeglądarką z podstawionym identyfikatorem kliknięcia i sprawdziłem, co realnie zapisuje się kupującemu. I tu wyszła rzecz, która zmieniła mi obraz tego problemu.

Identyfikator kliknięcia zwykle jest zapisany. Na Shoperze robi to sama platforma, do własnego ciastka o nazwie shop_gclid. Ustawia je serwer Shopera, z ważnością 90 dni, razem z podobnymi ciastkami na parametry UTM. Przeglądarką odczytałem 40 sklepów z tej próby: ciastko było na wszystkich 25 sklepach Shopera i na żadnym z 15 pozostałych. Próbka jest mała i tak ją traktuję, ale rozdział jest w niej zupełnie czysty. Czyli wartość, której brakuje Google Ads, leży w przeglądarce kupującego przez trzy miesiące, a serwer platformy ją zna.

Tylko że do InPostu ta wartość nie trafia, bo opisany wyżej kontrakt między Shoperem a InPostem nie ma pola, w które dałoby się ją włożyć. Nie ma jej też w danych zamówienia, które Shoper udostępnia przez API. Co platforma robi z nią u siebie, z zewnątrz nie widać.

To jest dużo bardziej prawdopodobna wersja tej historii niż „pięćset sklepów nic nie mierzy”. Nikt tu nie zaniedbał pomiaru. Dwa systemy robią swoje poprawnie, każdy z osobna, a nikt nie połączył ich w miejscu, w którym się stykają.

Reszta próby wygląda różnie i dobrze to widać po platformach. Na WooCommerce identyfikator utrwala typowy dodatek do atrybucji zamówień. Na Shopify łapie go skrypt TikToka. A na sklepach IdoSella, zgodnie z tym, co widać w kodzie ich modułu, najczęściej nie zapisuje się nic i nie ma nawet czego przekazywać.

Uczciwie o granicach tej metody: sprawdzam, co zapisuje przeglądarka, a nie co dzieje się po stronie serwera sklepu. Nie zobaczę sklepu, który uruchomił oficjalną funkcję InPostu i wysyła zakupy z samymi danymi klienta, ani rozwiązania, które zapisuje identyfikatory po swojemu, na przykład przez własny serwer tagowania. Część domen w ogóle nie dała się przeskanować, a wśród nich są największe sklepy, te z agencjami i budżetami. Wynik mówi więc jedno: przekazywanie identyfikatorów kliknięcia z przeglądarki do InPostu prawie nie występuje. Nie mówi, że pozostałe sklepy nie mierzą InPost Pay w żaden sposób.

Jest jeszcze jeden powód tej ciszy, prozaiczny. Ten błąd nie ma gdzie zostać zgłoszony. Wtyczki InPost Pay nie ma w oficjalnym repozytorium WordPressa, więc nie ma forum wsparcia, na którym zwykle lądują takie rzeczy. Shoper nie ma publicznego forum. A repozytoria czterech integracji, które są publiczne na GitHubie, mają zgłoszenia otwarte i w całej historii nie ma w nich ani jednego zgłoszenia. Szukałem zgłoszeń wszędzie, gdzie mogłyby być, i nie znalazłem ani jednego. Znalazłem za to pytanie sprzedawcy z webinaru IdoSella i InPostu z grudnia 2023 roku, czy InPost Pay wymaga zmian w analityce, i odpowiedź, że nie wymaga żadnych.

W panelu sklepu naprawdę nie widać, że coś nie działa.

Klucz: identyfikator koszyka

Żeby odzyskać dane, potrzebny jest identyfikator, który widzą obie strony: przeglądarka kupującego przed odejściem do aplikacji i sklep po zapłacie.

Tym identyfikatorem jest identyfikator koszyka. Warto wiedzieć, że nadaje go sklep, nie InPost - to sklep zakłada koszyk pod własnym numerem, a InPost odsyła ten sam numer przy tworzeniu zamówienia. To dobra wiadomość, bo klucz jest pod pełną kontrolą sklepu.

Numer zamówienia do niczego się tu nie nada, bo w chwili kliknięcia w przycisk InPost Pay jeszcze nie istnieje. Zamówienie powstaje dopiero przy płatności.

Sygnał zbiera się więc w jedynym momencie, w którym kupujący jeszcze jest u nas: przy koszyku, zanim odejdzie do aplikacji. Trzeba wtedy zapisać komplet, czyli click-id Google, identyfikator sesji GA4, cookie tagu Google, identyfikator Meta i stan zgody, pod kluczem koszyka. Dopiero po zapłacie przepina się to wszystko na numer zamówienia.

Brzmi prosto i w podstawowym wariancie takie jest. Problem w tym, że kupujących są dwa rodzaje, a ten drugi jest podstępny. Klient, który ma już powiązaną aplikację InPostu, po kliknięciu leci deep linkiem i w ogóle nie przechodzi przez wiązanie koszyka. Dla niego trzeba szukać innego momentu na przechwyt.

I tu muszę powiedzieć rzecz niewygodną, bo zmierzyłem skuteczność własnego pomysłu i wyszła inaczej, niż zakładałem. W dotychczasowym pomiarze ten dodatkowy przechwyt nie dowiózł ani jednego koszyka, którego nie miałbym bez niego. Zamówienia bez żadnego sygnału i tak się zdarzają, a grupy, którą miał ratować, on po prostu nie widzi.

Zostawiam go włączonego, bo nic nie kosztuje i może łapać rzadszy wariant, którego w tej próbce nie było. Ale nie mam dowodu, że cokolwiek ratuje, i uczciwiej jest to napisać, niż sprzedawać kompletność. To jest ta część, której jeszcze nie domknąłem.

Warto też wiedzieć, że sam widget jest w tym miejscu nieprzyjazny. Renderuje się w sposób, który sprawia, że typowe reguły z menedżera tagów go nie widzą, a moment przejścia do aplikacji to twarda nawigacja, w której zwykła wysyłka w tle po prostu nie zdąży. To są te dwie rzeczy, przez które wdrożenie na poziomie samego menedżera tagów się nie uda, i przez które większość prób kończy się na tym, że w panelu wszystko wygląda dobrze, a danych nie ma.

Zostaje jeszcze strona serwera. Przy integracji własnej identyfikator koszyka przychodzi wprost i wystarczy go odczytać. Na platformie abonamentowej odpowiedni moment obsługuje moduł platformy, a nie warstwa pomiarowa, więc trzeba go odzyskać okrężną drogą. To jest ta część, która na Shoperze jest najtrudniejsza.

Parowanie musi zdążyć przed wysyłką konwersji

Po informacji o zapłacie serwer odzyskuje identyfikator koszyka, znajduje zapis spod tego klucza i przepina sygnał na numer zamówienia.

Cała wartość tej operacji zależy od jednej rzeczy: czy zdąży przed wysłaniem konwersji. I to jest moment, w którym większość takich konstrukcji się wywraca, bo wysyłka konwersji musi mieć zaprojektowane opóźnienie, dobrane do tego, jak szybko odpowiada API, i z zapasem na ponowienie. Za krótkie i parowanie nie zdąży. Za długie i konwersja przychodzi do Ads po czasie.

U mnie zapas jest na tyle duży, że parowanie kończy się grubo przed wysyłką, i dzięki temu odzysk jest pełny: konwersja wychodzi już z identyfikatorami, więc trafia normalną drogą do Google Ads, Meta i GA4, a nie awaryjnym kanałem.

Gdyby parowanie spóźniło się za wysyłkę, zostaje wyłącznie dosyłka rekordu osobnym kanałem. Pingu nie wolno wtedy powtórzyć, bo drugie zdarzenie z tym samym numerem transakcji zdubluje ją w GA4. Google Ads i Meta deduplikują, GA4 nie. Ten scenariusz trzeba obsłużyć, ale jest gorszy i trzeba go liczyć osobno.

Czego parowanie nie może robić

Mechanizm, który dopisuje dane do zamówień, jest niebezpieczny z natury. Cztery bramki, bez których bym tego nie włączył.

Nie ufa samemu faktowi, że API coś zwróciło. Trzeba jeszcze zweryfikować, że zwróciło to, o co pytaliśmy, i jest to zabezpieczenie mniej oczywiste, niż się wydaje. Bez niego da się, w bardzo konkretnym scenariuszu, skopiować koszyk obcego kupującego do własnego zamówienia. To jest ten rodzaj błędu, którego nikt nie zauważy, a który skaża dane u klienta.

Nie nadpisuje własnego sygnału kupującego. Jeżeli klient jednak wrócił na stronę podziękowania i jego tag zdążył zapisać dane, parowanie odpuszcza. Reguły pierwszeństwa są pisane pod sygnał z przeglądarki i to one mają wygrywać.

Nie kopiuje adresu IP. Adres widoczny przy zamówieniu InPost Pay to adres zaplecza InPostu, nie kupującego. Skopiowany udawałby adres klienta i zalałby logi fałszywymi niezgodnościami przy każdej wysyłce. Pole zostaje puste, co w kodzie znaczy „nie ma czego porównać”, a nie „nie zgadza się”.

Nie rozstrzyga zgody za kupującego. Zgoda jedzie z koszyka taka, jaka jest. Odmowa zostaje odmową i takie zamówienie nie dostaje ani identyfikatorów, ani danych klienta. Koszyk z nierozstrzygniętą zgodą nie jest parowany w ogóle, bo wtedy lepiej zostawić kupującemu drogę powrotną: jeśli wróci na stronę, jego własny tag zapisze prawdziwy stan.

Sufit metody

Parowanie nie dochodzi do stu procent i warto wiedzieć dlaczego, zanim obieca się to komukolwiek.

Zostaje przypadek, w którym nie ma z czego parować, bo przeglądarka kupującego nie zostawiła żadnego śladu: ani kliknięcia w przycisk, ani renderu widgetu. Dla takiego zamówienia nie powstaje żaden zapis koszyka, więc nie ma czego przepiąć.

Nie umiem dziś powiedzieć, czym ta grupa różni się od reszty, i to jest wątek otwarty, a nie rozwiązany. Dlatego osiemdziesiąt kilka procent pokrycia to realny poziom tej metody, nie sto. Kto obiecuje sto, albo nie mierzył, albo nie mówi wszystkiego.

Druga rzecz do pilnowania to niezgodność parowania, czyli sytuacja, w której API zwróciłoby nie ten koszyk. To jedyny scenariusz, który psuje dane zamiast ich brakować, bo doklejałby cudze identyfikatory do zamówienia. Licznik takich przypadków musi być twardym zerem, a nie „małą liczbą”. U mnie jest zerem i to jest warunek, przy którym w ogóle wolno to trzymać włączone.

Wyniki

Przed wdrożeniem parowania sygnał z przeglądarki miało około 60 procent zamówień w całym sklepie, wszystkie metody płatności razem. Po wdrożeniu poziom trzyma się w okolicach 90 procent. To jakieś trzydzieści punktów procentowych różnicy, wziętych z jednego mechanizmu, bez ruszania czegokolwiek w kampaniach.

Sam mechanizm parowania odzyskuje około 80 procent zamówień, które tego potrzebują. Liczę to uczciwie, czyli tylko na tych zamówieniach, przy których kupujący faktycznie nie wrócił. Jeśli wrócił i jego własny tag zdążył zapisać dane, parowanie odpuszcza i nie wliczam sobie tego jako sukcesu, bo nim nie jest.

Najtwardszy dowód wartości jest jednak inny niż procent pokrycia. Konwersje InPost Pay, które docierają do Google Ads z click-id, mają go wyłącznie dzięki parowaniu. Bez niego nie miałyby żadnego, bo nie ma skąd. Odzyski mieszczą się w oknie przed wysyłką, więc idą normalną drogą, a nie awaryjną dosyłką.

Dla zamówień z odmową zgody parowanie kopiuje odmowę i konwersja idzie bez identyfikatorów, tak jak powinna.

Co to znaczy dla wyników kampanii, zależy już od tego, ile z tych zamówień pochodzi z reklamy, ale kierunek jest prosty: Smart Bidding uczy się na danych, które dostaje, a nie na tych, które gdzieś są.

Podsumowanie

InPost Pay rośnie w polskim e-commerce i w sklepach, które go mają, potrafi odpowiadać za grubą część zamówień. Domyślnie ta część jest dla pomiaru niewidoczna, bo cały pomiar w przeglądarce wisi na jednym zdarzeniu o utworzeniu zamówienia, wysyłanym do karty, która została po drugiej stronie przełączenia do aplikacji.

Nie jest to problem jednej platformy. WooCommerce czeka na znacznik, którego nikt nie wkleił. PrestaShop ma przełącznik domyślnie wyłączony. Magento pokazuje zdrowe raporty GA4 także wtedy, gdy Google Ads i Meta nie dostały zakupu. IdoSell nie zbiera niczego. Shoper nie ma nawet czego włączyć. A na 499 sklepach z InPost Pay identyfikator kliknięcia zwykle jest zapisany w przeglądarce i mimo to do InPostu trafia tylko w jednym z nich.

Odzysk jest możliwy i nie wymaga niczego od InPostu poza dostępem do jego API. Potrzebne są dwie rzeczy pewne: przechwyt sygnału przy koszyku pod kluczem koszyka oraz opóźnienie wysyłki konwersji na tyle długie, żeby parowanie zdążyło. Plus komplet bramek, żeby mechanizm nigdy nie nadpisał prawdziwych danych swoimi. Trzecia, przechwyt na renderze widgetu dla klientów już powiązanych z aplikacją, w moim pomiarze nie dowiozła jeszcze niczego i zostaje otwartym wątkiem.

Jeśli masz sklep z InPost Pay i nie wiesz, ile zamówień dochodzi do Google Ads bez danych, to jest pierwsza rzecz, którą warto policzyć. Wystarczy rozbić zamówienia po metodzie płatności i sprawdzić, przy ilu z nich w ogóle powstało zdarzenie w przeglądarce. Jak to poukładać na Shoper Storefront, opisałem w przewodniku po server-side GTM dla Storefront, a zakres samego wdrożenia znajdziesz na stronie usług dla Shopera.