Analityka WooCommerce a agenci AI

Klient nie musi już odwiedzić Twojego sklepu, żeby w nim kupić. W 2026 roku agent AI potrafi przeczytać katalog, dodać produkt i sfinalizować zamówienie WooCommerce w imieniu kupującego, a robi to wszystko przez interfejs, nie w karcie przeglądarki. Zamówienie ląduje w panelu. Pieniądze wpływają. A Twoja analityka nie rejestruje niczego.

To nie jest hipoteza. Blog deweloperski WooCommerce nakreślił mapę drogową AI i agentic commerce, łącznie z natywną ścieżką agenta do kasy, a ekosystem dopina się wokół niej szybciej, niż nadążają wtyczki śledzące. W WPPoland budujemy i oskryptowujemy sklepy WooCommerce dla klientów sprzedających w całej UE, i pierwsze sklepy z zamówieniami od agentów już widzą rozjazd między tym, co sprzedały, a tym, co pokazują ich panele.

Oto mechanizm, konkretne rzeczy, które się psują, dlaczego Conversions API nie ratuje automatycznie i jak oskryptować to poprawnie.

#Co dzieje się z analityką, gdy agent AI robi zakup?

Krótka odpowiedź: z analityką nie dzieje się nic i na tym polega problem. Twój stos raportowy zbudowano na założeniu, że każdy zakup poprzedza człowiek ładujący strony w przeglądarce. Agent łamie to założenie. Finalizuje zamówienie po stronie serwera, więc żaden sygnał przeglądarkowy, na którym opiera się analityka, po prostu się nie odpala.

Zostajesz z zamówieniem WooCommerce bez pasującej sesji w Google Analytics, bez pasującego zdarzenia na pikselu Meta i bez atrybucji, bo nie było kliknięcia, nie było wejścia z tagiem UTM i nie było przeglądarki, z której cokolwiek dałoby się odczytać. Przychód jest prawdziwy. Ślad jest pusty.

#Dlaczego Twoje śledzenie mieszka w przeglądarce

Większość pomiaru w WooCommerce jest z założenia po stronie klienta. Google Analytics 4 zbiera dane przez gtag.js, skrypt, który przeglądarka odwiedzającego pobiera i uruchamia. Piksel Meta działa tak samo: fragment kodu wykonujący się w przeglądarce i raportujący PageView, AddToCart, InitiateCheckout i Purchase w miarę ruchu kupującego przez lejek. Google Tag Manager, kontener, przez który sklepy zwykle przepuszczają te tagi, to też środowisko przeglądarki.

Każde z tych narzędzi potrzebuje wyrenderowanej strony i wykonanego skryptu. To jest ten jeden punkt awarii. Zabierz sesję przeglądarki, a zabrałeś jedyne miejsce, w którym te tagi miały się kiedykolwiek wykonać.

Checkout agenta zabiera sesję przeglądarki.

#Co dokładnie się psuje

Warto być precyzyjnym, bo “analityka się psuje” ukrywa, ile osobnych raportów przestaje działać naraz.

1. Lejek i zdarzenia zakupu w GA4. Brak page_view, brak add_to_cart, brak begin_checkout, brak purchase. Zamówienie nie trafia do GA4, więc przychód, współczynnik konwersji i porzucenia lejka są zaniżone.
2. Konwersja na pikselu Meta. Zdarzenie Purchase nie dociera z przeglądarki, więc sprzedaż wypada z raportowania reklam i z sygnału optymalizacyjnego, na którym uczy się algorytm.
3. Atrybucja. Modele atrybucji czytają kliknięcie, referrera, parametry UTM lub zapisany client id z sesji przeglądarki. Zamówienie agenta nie ma żadnego z nich, więc nie da się go przypisać do kanału, kampanii ani źródła. Pojawia się w najlepszym razie jako bezpośrednie lub nieprzypisane, a często wcale.
4. Grupy remarketingowe. Kupującego, którego piksel nigdy nie zobaczył, nie da się dodać do grupy klientów ani wykluczyć z grupy prospektowej. Będziesz płacić za reklamę do ludzi, którzy już kupili przez agenta.
5. Zwrot z wydatków na reklamę. Przychód w WooCommerce przestaje zgadzać się z przychodem w panelach reklamowych. ROAS wygląda gorzej niż w rzeczywistości, a naturalną, lecz błędną reakcją jest ścięcie właśnie tych kampanii, które działają.

Nic z tego nie rzuca błędem. To właśnie czyni to groźnym. Sklep działa dalej, zamówienia wpływają dalej, a panele po cichu odjeżdżają od prawdy.

#Conversions API nie ratuje automatycznie

Oczywisty kontrargument brzmi: Meta przecież rozwiązała już śledzenie po stronie serwera. Conversions API wysyła zdarzenia wprost z Twojego serwera, bez przeglądarki. Więc zamówienia agentów powinny być objęte.

Nie są, przynajmniej nie przy standardowej instalacji, a powodem jest deduplikacja. Conversions API zaprojektowano, by pracowało obok piksela, nie zamiast niego. Oczekuje się, że wyślesz tę samą konwersję dwa razy, raz z piksela w przeglądarce i raz z serwera, a Meta scala parę w jedno po współdzielonym event_id i event_name. O to właśnie chodzi: mierzyć wiarygodnie bez podwójnego liczenia.

Zamówienie agenta nie ma połowy przeglądarkowej. Nie ma zdarzenia piksela do sparowania, a popularne konfiguracje CAPI dla WooCommerce budują klucz deduplikacji w momencie renderu strony podziękowania. Dla zamówienia agenta ta strona nigdy się nie renderuje, więc klucz nigdy nie powstaje, a zdarzenie serwerowe jest albo niewysłane, albo wysłane bez informacji o tożsamości, których Meta oczekuje. Ten sam model deduplikacji, który chroni Cię przed podwójnym liczeniem zamówień przeglądarka-plus-serwer, po cichu gubi zamówienie, które istniało wyłącznie na serwerze.

Śledzenie po stronie serwera to właściwy kierunek. Doklejenie go do założenia “najpierw przeglądarka” to nie to samo, co gotowość na agentów.

#Naprawa: przenieś zdarzenie zakupu na zamówienie

Trwała naprawa polega na tym, by przestać traktować render strony podziękowania jako moment prawdy i zacząć traktować jako moment prawdy samo zamówienie. Zamówienie to jedna rzecz, która niezawodnie istnieje niezależnie od sposobu złożenia.

Konkretnie:

• Odpalaj zakup po stronie serwera z haka zamówienia. WooCommerce podnosi woocommerce_order_status_completed i pokrewne haki płatności na serwerze dla każdego zamówienia, przeglądarkowego czy agenta. Wyślij zakup do GA4 przez Measurement Protocol, a Purchase do Meta przez Conversions API z tego haka, żeby zbiórka nie zależała od załadowania strony.
• Deduplikuj po numerze zamówienia. Użyj numeru zamówienia WooCommerce jako event_id. Zamówienie przeglądarkowe i jego bliźniak serwerowy nadal scalają się w jedno, bo oba niosą ten sam numer, a zamówienie tylko od agenta przechodzi czysto, bo klucz nie potrzebuje odpowiednika z piksela.
• Oznaczaj źródło zamówienia. Zapisz, skąd przyszło zamówienie, identyfikator bramki lub dedykowane pole meta, przy jego utworzeniu. Teraz każdy raport rozdzieli przychód od agentów od przychodu przeglądarkowego, zamiast zlewać je w średnią, która ukrywa zmianę.
• Odbuduj atrybucję wokół tożsamości, którą naprawdę masz. Dla zamówień agentów to konto klienta, adres e-mail lub identyfikatory samego agenta są tym, co masz. Zmapuj je świadomie na kanały, zamiast liczyć, że pojawi się ciąg UTM.

To zwykła inżynieria WooCommerce, haki, webhooki i zdarzenia serwer-do-serwera, ale trzeba ją zaprojektować pod przypadek agenta od początku, a nie łatać na pikselu, który zakłada przeglądarkę.

#Polski kontekst: agent nie zwalnia z KSeF i JPK

W Polsce ten rozjazd ma drugą warstwę. Zamówienie od agenta i tak trzeba zafakturować w KSeF i ująć w JPK, więc dla księgowości ono jak najbardziej istnieje, nawet gdy w GA4 go nie ma. To bywa pierwszy moment, w którym właściciel sklepu zauważa problem: liczba faktur w rejestrze nie zgadza się z liczbą transakcji w panelu marketingowym. Jeśli sklep korzysta z mechanizmu podzielonej płatności, zamówienie agenta przechodzi przez rachunek VAT tak samo jak każde inne, a mimo to nie ma śladu w lejku, na podstawie którego rozliczasz budżet reklamowy. Uzgadnianie sprzedaży z KSeF przeciw danym z reklam to praktyczny sposób, by w ogóle wykryć, ile zamówień przyszło przez agentów, zanim naprawisz zbiórkę po stronie serwera.

#Co to oznacza dla Twojego raportowania w 2026

Na razie zamówienia agentów to dla większości sklepów strumyk i właśnie dlatego to jest właściwy moment na naprawę. Sklepy, które oskryptują zbiórkę serwerową, gdy wolumen jest mały, będą miały czyste, porównywalne liczby, gdy przestanie być mały. Sklepy, które poczekają, spędzą 2027 rok na tłumaczeniu rosnącej różnicy między przychodem w WooCommerce a panelami reklamowymi, a odbudowa atrybucji pod presją jest znacznie droższa niż zbudowanie jej raz, na spokojnie, teraz.

Jeśli sprzedajesz przez WooCommerce i zaczynasz widzieć zamówienia, których piksele nie potrafią wytłumaczyć, to jest ten sygnał. To problem hydrauliczny ze znaną naprawą, i jest to rodzaj pracy, która zwraca się przy pierwszej kampanii, którą miałeś ściąć, a okazała się rentowna.

Robimy tę pracę w ramach naszych wdrożeń programisty WooCommerce, a stoi ona obok szerszego pytania, czy Twój sklep jest w ogóle odnajdywalny i kupowalny dla agentów, które omawiamy w przewodniku gotowości na AI commerce oraz w wyjaśnieniu Universal Commerce Protocol. Jeśli chcesz zrozumieć, jak agenci docierają do Twojego katalogu, nasz tylko-do-odczytu serwer MCP dla WooCommerce pokazuje mechanikę, a dla fundamentów po stronie klienta, które nadal się liczą, przewodnik Google Analytics 4 dla WordPress omawia stronę przeglądarkową, którą zamówienia agentów omijają.

Ostatnia aktualizacja: 20 lipca 2026.