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 testami natychmiastowego checkoutu poza sklepem z partnerami takimi jak Google i Stripe, 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.

Skala rośnie szybko: według Stripe system płatności Link obsługuje dziś około 200 agentów AI, wobec około 70 we wrześniowych danych firmy (Upstarts Media, 18.10.2026). Stripe zastrzega, że Anthropic i OpenAI używają Link, ale jeszcze nie do zakupów przez agentów.

#Dlaczego zamówień agenta AI nie ma w GA4

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 GA4 i piksel Meta potrzebują przeglądarki

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.

#Które raporty WooCommerce psują się przy zamówieniach agentów

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.

#Czy Conversions API Meta śledzi zamówienia agentów

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.

#Jak śledzić zakupy WooCommerce po stronie serwera

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ę.

#Jak WooCommerce zapisuje źródło zamówienia

Zanim dodasz własne pole ze źródłem, sprawdź dwa miejsca, w których WooCommerce już zapisuje dane o pochodzeniu zamówienia, bo każde z nich inaczej zachowuje się przy zamówieniach agentów.

Pierwsze to właściwość zamówienia created_via. W kodzie źródłowym WooCommerce klasyczny checkout oparty na shortcode ustawia ją na checkout (class-wc-checkout.php), Store API na store-api (OrderController.php), a endpoint zamówień w REST API v3 na rest-api, chyba że żądanie przekaże własną wartość created_via (class-wc-rest-orders-controller.php). Ten ostatni szczegół się przydaje: integracja, która tworzy zamówienia agentów przez REST API, może oznaczać je własną wartością. Ograniczeniem jest Store API. Blokowy checkout w przeglądarce także korzysta ze Store API, więc sama wartość store-api nie odróżni klienta w karcie przeglądarki od agenta, który woła ten sam endpoint.

Drugie miejsce to atrybucja zamówień. Dokumentacja atrybucji zamówień WooCommerce opisuje zestaw ciasteczek sbjs_, które przechowują stronę odsyłającą, parametry UTM, typ urządzenia i liczbę odsłon w sesji. WooCommerce odczytuje je dopiero w chwili złożenia zamówienia i zapisuje jako metadane zamówienia z prefiksem _wc_order_attribution. Etykieta pochodzenia na liście zamówień powstaje z typu źródła: UTM, ruch organiczny, odesłanie, wejście bezpośrednie, aplikacja mobilna, panel administratora albo punkt sprzedaży. Wszystko inne trafia do kategorii “Nieznane” (OrderAttributionMeta.php). Agent, który nigdy nie ładuje Twojego sklepu, nigdy nie dostaje tych ciasteczek, więc jego zamówienia pojawiają się w kolumnie Pochodzenie jako Nieznane, obok każdego innego zamówienia, którego dane gdzieś się zgubiły.

Praktyczna kolejność pracy wygląda więc tak: najpierw odczytaj created_via, własny znacznik dodaj tylko tam, gdzie ta wartość nie odróżnia agenta od przeglądarki, a rosnący udział zamówień o nieznanym pochodzeniu traktuj jako wczesny sygnał, że ruch agentów już się zaczął.

#Jakie dane o atrybucji przekazują sprzedawcy ACP i UCP

To, czy zamówienie agenta przyjdzie z jakąkolwiek atrybucją, zależy od protokołu, który za nim stoi. Wpis na blogu WooCommerce wymienia Agentic Commerce Protocol od Stripe i prace nad MCP; nie wspomina o UCP ani o AP2. Zanim zaczniesz polegać na którymkolwiek z poniższych pól, sprawdź, co faktycznie obsługuje Twoja integracja płatności albo agenta.

Agentic Commerce Protocol utrzymują OpenAI i Stripe. Protokół jest wciąż w fazie beta, ma licencję Apache 2.0 i wersje oznaczane datą. W specyfikacji checkoutu w wersji 2026-04-17 agent korzysta z POST /checkout_sessions, a potem z /complete albo /cancel dla tej sesji. Zarówno wywołanie tworzące sesję, jak i kończące ją przyjmują opcjonalny obiekt affiliate_attribution: wymagane pole provider, do tego token albo publisher_id, opcjonalne identyfikatory kampanii, kreacji i podśledzenia oraz touchpoint o wartości first albo last. Według specyfikacji obiekt jest tylko do zapisu: sprzedawca przechowuje go razem z powstałym zamówieniem, ale nie zwraca go w odpowiedzi. Zamówienie zwracane po zakończeniu checkoutu ma własne id, checkout_session_id, permalink_url i status, a sprzedawca wysyła kolejne zdarzenia zamówienia z powrotem do platformy agenta, podpisane HMAC w nagłówku Merchant-Signature. Warto zapisać checkout_session_id przy zamówieniu WooCommerce, bo łączy zamówienie z rozmową z agentem, z której się wzięło.

Aktualizacja, 28 października 2026. Opisana wyżej sesja zakupu to dziś ścieżka tylko dla zatwierdzonych partnerów. 24 marca 2026 OpenAI ograniczyło Instant Checkout w ChatGPT do zatwierdzonych partnerów, pozwoliło sprzedawcom korzystać z własnej kasy i zapowiedziało, że skupia się na odkrywaniu produktów, a ACP służy do przekazywania danych o produktach i promocji (OpenAI). W większości sklepów WooCommerce zakup, który zaczyna się w ChatGPT, kończy się więc wizytą w twojej własnej kasie w przeglądarce. Ta wizyta ładuje sklep, więc ciasteczka sbjs_, kolumna Pochodzenie oraz tagi GA4 i Meta widzą ją jak każdą inną sesję: atrybucja dzieje się w twoim sklepie, a nie w polu ACP. Zanim napiszesz dla takich wizyt osobną regułę, sprawdź w danych swoich zamówień, z jaką stroną odsyłającą albo parametrami UTM faktycznie przychodzą.

Universal Commerce Protocol ma ogólne pole atrybucji. Przegląd specyfikacji definiuje pole attribution, które platformy mogą wysyłać w żądaniach dotyczących koszyka, checkoutu i katalogu. Niesie ono te same parametry kampanii i identyfikatory kliknięć, takie jak gclid czy fbclid, które w przeglądarce przyszłyby w adresie URL. UCP nie narzuca modelu atrybucji, pole jest opcjonalne, a specyfikacja zaznacza, że identyfikatory kliknięć i klucze sesji mogą być danymi osobowymi. Twoje zasady dotyczące zgód i okresu przechowywania obejmują więc także to pole. Zamówienie może pokazywać kopię atrybucji z checkoutu tylko do odczytu, a zdarzenia z cyklu życia zamówienia trafiają do platformy jako webhooki z nagłówkami Standard Webhooks.

AP2, ogłoszony 16 września 2025 roku, to warstwa zaufania dla płatności, a nie źródło danych analitycznych. Podpisane Checkout Mandate i Payment Mandate dowodzą, na co zgodził się użytkownik. Mówią Ci, że zamówienie złożył agent, ale nie mówią, która kampania do niego doprowadziła.

#Ograniczenia Measurement Protocol i Conversions API przy zamówieniach agentów

Przeniesienie zbierania danych na serwer rozwiązuje problem brakujących zdarzeń, ale oba API mają reguły, o które zamówienie bez odsłony strony się potyka.

Measurement Protocol GA4 oczekuje dla strumieni internetowych identyfikatora client_id, który zgadza się z ID wygenerowanym przez tag Google w przeglądarce odwiedzającego. Zamówienie agenta takiego ID nie ma, więc trzeba je utworzyć, a najlepiej zapisać przy zamówieniu, żeby zwroty i późniejsze zdarzenia używały tego samego identyfikatora. Zdarzenia można antydatować maksymalnie o 72 godziny, jedno żądanie mieści najwyżej 25 zdarzeń, a api_secret musi zostać na serwerze. Google opisuje protokół jako przeznaczony do środowisk serwerowych, ze zdarzeniami łączonymi z tym, co zbiera gtag.js. Zamówienie agenta wysłane z nowo utworzonym client id liczy się więc jako nowy użytkownik, a nie jako zakończenie wcześniejszej sesji w przeglądarce.

Parametry zdarzeń serwerowych Meta wyznaczają krótszy termin: event_time może mieć najwyżej 7 dni, a jedno starsze zdarzenie sprawia, że Meta odrzuca całe żądanie. Każde zdarzenie potrzebuje pola action_source z jedną z wartości: email, website, app, phone_call, chat, physical_store, system_generated, business_messaging albo other. Jeśli wyślesz website, wymagane jest event_source_url, a zamówienie agenta nie ma adresu strony, który można by tam wpisać. Na liście Meta nie ma wartości dla agentów AI, więc wybierz jedną świadomie, zapisz powód i trzymaj się jej, bo późniejsza zmiana utrudnia porównania przed i po. Ta sama strona potwierdza, że numer zamówienia jest dopuszczalnym event_id.

Te terminy wyznaczają też Twój budżet na ponowne próby. Jeśli hook wysyłający zdarzenie zawiedzie, ponowna próba z kolejki ma 72 godziny w GA4 i 7 dni w Meta, zanim zdarzenie przepadnie.

#Zamówienia agentów AI a 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.

#Czy sklep WooCommerce powinien wpuszczać agentów AI

Zanim zamówienie agenta zniknie z GA4, agent musi w ogóle przejść przez checkout. The Verge opisał 17 października 2026, że coraz więcej serwisów zamyka się na agentów: Yelp wpuszcza tylko tych, którzy płacą za licencję na dane, Delta Air Lines nie pozwala im kupować biletów, a JPMorgan Chase i Charles Schwab blokują im dostęp do kont ze względów bezpieczeństwa. Amazon zablokował zakupy agenta Perplexity i pozwał firmę, a po tym, jak sąd apelacyjny uchylił w sierpniu zakaz, złożył poprawiony pozew. Po drugiej stronie Meta uruchomiła zakupy swojego asystenta Muse w sklepach Walmart, Gap, Sephora i Best Buy, a Shopify otworzył swoje sklepy dla agentów.

Dla sklepu WooCommerce ważniejsza jest dalsza część tekstu: agenci odbijają się też od zabezpieczeń antybotowych, które wcale nie były ustawione przeciw nim. Użytkownicy zgłaszali problemy z checkoutem w Walmarcie mimo partnerstwa z Metą. W WordPressie ten sam efekt dają reguły WAF, Bot Fight Mode w Cloudflare, Turnstile albo CAPTCHA w formularzu zamówienia i limity zapytań we wtyczce bezpieczeństwa. Takiego zamówienia nie zobaczysz ani w GA4, ani w WooCommerce, bo nigdy nie powstało.

Decyzja należy do właściciela sklepu, ale powinna być świadoma:

1. Przejrzyj zdarzenia WAF i logi serwera dla /checkout/ oraz Store API (/wp-json/wc/store/v1/checkout) i sprawdź, ile żądań kończy się kodem 403 albo wyzwaniem.
2. Jeśli chcesz przyjmować zamówienia od agentów, wpuść ich przez integrację, którą sam wybierasz (ACP albo UCP), a nie przez wyłączenie ochrony formularza dla wszystkich.
3. Jeśli nie chcesz, zablokuj ich jawnie regułą na konkretne ścieżki albo user-agenty, zamiast zostawiać przypadkowi, który bot przejdzie przez antybot.

Zasady Walmartu dla agentów zakupowych, aktualizacja z 23 października 2026: 21 października Walmart ogłosił trzy elementy. Agent Profiles, które mają ruszyć w ciągu miesiąca, dają każdemu agentowi upoważnionemu przez klienta osobny profil w jego koncie, więc zakupy agenta widać oddzielnie. Klient wybiera, czy zatwierdza każde zamówienie, czy ustala limit wydatków. Walmart Agent Gateway pozwala agentom kupować przez MCP zamiast klikać po stronach zaprojektowanych dla ludzi i startuje jako beta dla firm i programistów. Zasady dla agentów AI mówią, że klient domyślnie zatwierdza zakupy agenta, agent nie dostaje danych karty i nie może zmieniać metod płatności, zwroty działają tak samo, nawet gdy agent zrobi coś wbrew intencji klienta, a agenci łamiący zasady będą blokowani. Po stronie klienta Agent Profiles zamykają tę samą lukę, którą ten artykuł opisuje po stronie sprzedawcy: odróżnienie zamówień agenta od zamówień człowieka. Każdy sklep, na WooCommerce, Shopify czy własnym systemie, może przyjąć ten wzór już teraz: zapisywać agenta jako osobne źródło zamówienia, zostawić zatwierdzenie przez człowieka przed płatnością i opublikować, co agentom wolno, a czego nie. Takie wdrożenie obejmuje nasza usługa przygotowania sklepu do handlu z agentami AI.

#Kiedy naprawić śledzenie zamówień agentów w WooCommerce

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 października 2026.