Coraz częściej między klientem a sklepem staje agent AI: asystent, który rozumie polecenie „znajdź mi buty do biegania po asfalcie, rozmiar 43, dostawa do piątku, budżet 500 złotych”, sam przegląda oferty, porównuje je i w części przypadków finalizuje transakcję. To jest agentic commerce i w 2026 roku przestał być prezentacją z konferencji, a stał się kanałem, który da się zmierzyć w raportach.
Różnica względem klasycznego e-commerce jest zasadnicza. Człowiek wybacza sklepowi mylący opis i nieaktualny stan magazynowy, bo potrafi kliknąć dalej albo zapytać na czacie. Agent nie wybacza: jeśli dane są niekompletne lub sprzeczne, wybiera inną ofertę i nie wraca. Ten tekst opisuje, co konkretnie trzeba zmienić w sklepie, żeby znaleźć się po właściwej stronie tego wyboru.
Czym jest agentic commerce i co się zmienia
Agentic commerce to model, w którym autonomiczny program działający w imieniu użytkownika realizuje część lub całość ścieżki zakupowej: rozumie intencję, zawęża zbiór ofert, weryfikuje warunki i przekazuje decyzję dalej. Agentem może być asystent w ChatGPT z włączonym trybem zakupowym, Gemini zintegrowany z przeglądarką, wyspecjalizowany bot porównywarki albo integracja wbudowana w system firmowych zakupów B2B.
Zmieniają się trzy rzeczy naraz. Znika przewaga wizualna, bo agent nie widzi banera ani animowanego licznika „zostało 5 sztuk”, a liczy się wyłącznie to, co da się odczytać maszynowo. Skraca się okno decyzyjne: kilkanaście ofert porównanych w kilka sekund oznacza, że każdy brakujący atrybut to natychmiastowa dyskwalifikacja. Rośnie też znaczenie spójności między źródłami, bo agent konfrontuje kartę produktu z feedem, porównywarką i opiniami, a rozbieżność traktuje jako sygnał ryzyka.
Skala przestała być marginalna. Dane platform sprzedażowych pokazują wzrosty ruchu z asystentów AI liczone w setkach procent rok do roku, wciąż przy niskiej bazie: opisaliśmy to w analizie danych Shopify o ruchu z AI. Wniosek jest prosty: to jeszcze nie kanał, z którego zbudujesz budżet na przyszły kwartał, ale już kanał, w którym przygotowanie zajmuje więcej czasu niż samo pojawienie się popytu.
Ścieżka agenta: od zapytania do koszyka
Żeby wiedzieć, co optymalizować, trzeba zrozumieć, jak agent porusza się po ofercie. W praktyce ścieżka ma pięć etapów i na każdym z nich sklep może wypaść z gry.
- Rozbicie zapytania. Agent zamienia jedno polecenie użytkownika na wiele zapytań szczegółowych: kategoria, parametry, ograniczenie budżetowe, warunek dostawy. Mechanizm ten opisaliśmy przy okazji tematu query fan-out i on stosuje się do produktów tak samo jak do treści.
- Zebranie kandydatów. Źródłem są wyniki wyszukiwania, feedy produktowe, API partnerskie oraz strony pobrane bezpośrednio przez crawler agenta.
- Normalizacja danych. Oferty trafiają do wspólnej tabeli: nazwa, wariant, cena brutto, koszt dostawy, termin, zwrot. Oferty z pustymi polami spadają w rankingu.
- Weryfikacja w czasie rzeczywistym. Przed rekomendacją agent sprawdza cenę i dostępność jeszcze raz, bo nie chce zaproponować czegoś, czego nie da się kupić.
- Przekazanie lub realizacja. Albo agent zwraca użytkownikowi link i podsumowanie, albo (przy zintegrowanym checkoucie) sam składa zamówienie.
Najwięcej ofert odpada na etapie trzecim i czwartym, czyli tam, gdzie sklep ma pełny wpływ techniczny i nie musi niczego negocjować z dostawcą modelu.
Dane produktowe jako fundament
Jeżeli miałbyś zrobić tylko jedną rzecz z tej listy, zrób tę. Agent buduje obraz produktu z danych ustrukturyzowanych, a nie z opisu marketingowego, dlatego najlepiej sprawdza się krótki akapit definiujący produkt i pod nim tabela parametrów, czyli ten sam układ, który opisaliśmy przy okazji tabel porównawczych cytowanych przez modele. Minimalny zestaw pól w znacznikach schema.org/Product oraz w feedzie wygląda tak. Szczegółowe omówienie pól, wymaganej jakości danych i harmonogramu aktualizacji zebraliśmy w tekście o tym, jak zbudować feed produktowy dla agentów AI.
| Pole | Dlaczego agent go potrzebuje | Częsty błąd |
|---|---|---|
| GTIN / MPN | Jednoznaczna identyfikacja tego samego produktu u wielu sprzedawców | Puste pole lub wewnętrzny SKU podany jako GTIN |
| brand | Filtrowanie po marce i ocena wiarygodności | Nazwa sklepu wpisana jako marka |
| price + priceCurrency | Porównanie ofert w jednej walucie | Cena bez waluty albo netto tam, gdzie klient widzi brutto |
| availability | Odrzucenie ofert niedostępnych | Statyczne InStock na każdej karcie |
| shippingDetails | Realny koszt i termin dostawy | Informacja tylko w regulaminie, poza znacznikami |
| hasMerchantReturnPolicy | Ocena ryzyka zakupu | Brak pola przy jednoczesnej deklaracji „30 dni na zwrot” w banerze |
| size, color, material | Dopasowanie do parametrów z zapytania | Parametry ukryte wyłącznie w tekście opisu |
| image | Prezentacja w interfejsie asystenta | Obraz w rozdzielczości miniatury |
Dwie zasady techniczne ratują więcej wdrożeń niż jakakolwiek optymalizacja treści. Pierwsza: warianty muszą być osobnymi bytami powiązanymi przez isVariantOf, a nie jednym rekordem z ceną „od”, bo agent proszony o rozmiar 43 potrzebuje ceny i dostępności dokładnie dla rozmiaru 43. Druga: znaczniki muszą być poprawnie zakodowane. Google zaostrzył parsowanie podwójnie zakodowanych encji w JSON-LD, co potrafi wyłączyć całą strukturę bez ostrzeżenia w interfejsie, a szczegóły opisaliśmy w tekście o zmianie w parsowaniu JSON-LD. Same pola warto weryfikować w dokumentacji Google Search Central, bo lista wymaganych atrybutów zmienia się kilka razy w roku.
Cena, dostępność i czas dostawy w czasie rzeczywistym
Agent weryfikuje ofertę tuż przed rekomendacją. Jeżeli zobaczy wtedy inną cenę niż w feedzie, uznaje sprzedawcę za niewiarygodnego i podmienia go na konkurenta. Problemem nie jest to, że ceny się zmieniają, tylko to, że różne warstwy sklepu aktualizują się w różnym tempie.
Praktyczny standard: feed odświeżany nie rzadziej niż co godzinę dla cen i co 15 minut dla dostępności, znaczniki generowane z tego samego źródła co feed, oraz zero rozbieżności między ceną w JSON-LD a ceną renderowaną w HTML. Ta ostatnia jest zaskakująco częsta tam, gdzie promocje nakłada warstwa frontendowa w JavaScripcie, a znacznik zostaje z ceną katalogową.
Czas dostawy zasługuje na osobną uwagę, bo pojawia się w zapytaniach wyjątkowo często. „Do piątku” to warunek twardy, weryfikowalny tylko wtedy, gdy podasz deliveryTime z rozbiciem na czas kompletacji i transportu. Deklaracja „wysyłka 24h” w grafice na karcie produktu jest dla agenta niewidoczna.
Checkout i integracje płatnicze dla agentów
Tutaj rynek jest najmniej ustabilizowany i warto uczciwie oddzielić to, co działa dziś, od tego, co jest zapowiedzią. Realnie funkcjonują trzy modele.
- Przekazanie do sklepu. Agent kończy na linku z podsumowaniem, transakcję domyka człowiek. To dziś większość ruchu, więc strona docelowa musi utrzymać kontekst: ten sam wariant, ta sama cena, żadnego przekierowania na stronę główną.
- Checkout delegowany. Agent składa zamówienie przez protokół uzgodniony z platformą (rozwiązania tego typu wdrażają dostawcy modeli razem z dużymi platformami e-commerce). Wymaga integracji po stronie platformy, więc dla większości sklepów jest to decyzja o wyborze dostawcy, a nie własny projekt.
- Agent sterujący przeglądarką. Program klika w interfejs jak człowiek, więc jest najbardziej wrażliwy na przeszkody: captcha, wieloetapowe formularze, wymuszoną rejestrację przed dodaniem do koszyka.
Wspólny mianownik dla wszystkich trzech: usuń z checkoutu wszystko, co nie jest niezbędne do złożenia zamówienia. Zakup jako gość, jeden ekran z podsumowaniem, jawne koszty przed ostatnim krokiem. Zabezpieczenia antybotowe skonfiguruj tak, żeby nie blokowały deklarowanych agentów zakupowych, bo zbyt agresywna weryfikacja wycina nie tylko transakcje, ale i widoczność w wyszukiwarce.
Sygnały zaufania, które agent bierze pod uwagę
Przy dwóch ofertach o zbliżonej cenie decyduje ryzyko. Agent szacuje je z sygnałów, które da się zweryfikować maszynowo, i w praktyce sprowadza się to do kilku grup. Osobno rozbieram opinie produktowe jako sygnał dla AI wraz z warunkami zwrotu, bo to najczęściej niedoszacowana część tej układanki.
- Spójność danych między źródłami. Cena i dostępność zgodne w feedzie, na stronie i w porównywarce. To najsilniejszy pojedynczy sygnał, bo najtrudniej go podrobić.
- Polityka zwrotów wyrażona w znacznikach. Konkretny okres, kto płaci za przesyłkę zwrotną, jaka jest procedura.
- Opinie z widoczną strukturą. Liczba ocen, rozkład, data. Agregat „4,9 na 5” bez liczby opinii obniża wiarygodność zamiast ją podnosić.
- Dane firmy. Pełna nazwa, NIP, adres, kanał kontaktu inny niż formularz. Dla zakupów o wyższej wartości to często warunek wstępny.
- Historia obecności. Domena i marka rozpoznawalne w innych źródłach, w tym w treściach niezależnych od sklepu.
Lista niemal pokrywa się z tym, czego oczekuje świadomy klient. Różnica jest w formie: człowiek przeczyta zdanie w stopce, agent potrzebuje pola w strukturze danych. Szerszy kierunek dobrze widać w kontekście przejścia Google w stronę trwałego, autonomicznego wyszukiwania, bo to ten sam mechanizm zastosowany do całego procesu, nie tylko do zakupów.
Pomiar sprzedaży z kanału AI
Najczęstszy błąd w raportowaniu: ruch z asystentów AI ląduje w koszyku „direct” albo „referral (other)” i znika z analizy. Zanim ocenisz, czy ten kanał się opłaca, musisz go w ogóle zobaczyć.
Minimalna konfiguracja pomiaru ma cztery elementy. Segment referrerów obejmujący domeny asystentów (chatgpt.com, perplexity.ai, gemini.google.com, copilot.microsoft.com) plus regułę łapiącą nowe domeny tego typu. Analizę logów serwera pod kątem crawlerów agentowych, bo wizyty bota poprzedzają ruch użytkownika: podejście opisaliśmy w tekście o analizie logów pod crawlery AI. Osobny raport konwersji dla tego segmentu, bo wartość koszyka i zwroty potrafią odbiegać od ruchu organicznego. I cytowalność, czyli okresowe sprawdzanie, czy twoje produkty pojawiają się w odpowiedziach asystentów na zapytania kategorii.
Realistyczne oczekiwanie na 2026 rok: pojedyncze procenty przychodu w większości sklepów, przy zauważalnie wyższej konwersji na sesję, bo agent przysyła użytkownika już po etapie porównywania. To argument za mierzeniem tego kanału osobno, a nie za przenoszeniem do niego budżetu z kanałów, które dziś zarabiają.
Plan wdrożenia na kwartał
Podział na cztery etapy, tak żeby po każdym z nich istniał mierzalny rezultat, a nie tylko postęp w zadaniu.
| Okres | Zakres | Rezultat |
|---|---|---|
| Tygodnie 1–2 | Audyt danych produktowych: pokrycie GTIN, warianty, kompletność znaczników, walidacja JSON-LD | Lista braków z liczbą dotkniętych SKU |
| Tygodnie 3–5 | Uzupełnienie pól krytycznych, rozbicie wariantów, wspólne źródło dla feedu i znaczników | Pełne pokrycie ceny, dostępności i dostawy na kartach o najwyższej sprzedaży |
| Tygodnie 6–8 | Częstotliwość odświeżania, zgodność cen między warstwami, uporządkowanie polityki zwrotów w strukturze danych | Rozbieżność feed kontra strona poniżej 1 procenta |
| Tygodnie 9–10 | Checkout: zakup jako gość, przegląd reguł antybotowych, utrzymanie kontekstu wariantu z linku | Skrócona ścieżka zakupowa, brak blokad dla deklarowanych agentów |
| Tygodnie 11–13 | Pomiar: segmenty referrerów, raport konwersji, pierwszy przegląd cytowalności w asystentach | Raport bazowy dla kanału AI |
Kolejność nie jest przypadkowa. Checkout dla agentów przy niekompletnych danych produktowych to inwestycja w etap, do którego agent nigdy nie dojdzie, bo odrzuci ofertę wcześniej. Pomiar wprowadzony przed uporządkowaniem danych pokaże tylko, że ruchu nie ma, bez informacji dlaczego.
Czego nie robić
Trzy praktyki szkodzą w tym kanale bardziej, niż się wydaje.
- Wypełnianie braków wartościami domyślnymi. Agent porówna je z innymi źródłami, a rozbieżność zaszkodzi bardziej niż puste pole.
- Ukrywanie kosztów dostawy do ostatniego kroku. Oferta wypada z porównania już na etapie normalizacji.
- Osobna wersja strony „dla botów AI”. To cloaking pod nową nazwą, tworzący drugi zestaw danych, który natychmiast rozjeżdża się z produkcyjnym.
Podsumowanie
Przygotowanie sklepu na agentic commerce nie wymaga nowej technologii ani osobnego budżetu na eksperymenty. Wymaga uporządkowania rzeczy, które w e-commerce i tak powinny działać: kompletnych danych produktowych z podziałem na warianty, jednego źródła prawdy dla ceny i dostępności, jasnej polityki zwrotów, prostego checkoutu i pomiaru, który odróżnia ten kanał od reszty ruchu.
Korzyść jest podwójna. Nawet jeśli udział zakupów realizowanych przez agentów pozostanie w 2026 roku niewielki, każdy z tych elementów poprawia jednocześnie widoczność w klasycznym wyszukiwaniu i konwersję ruchu ludzkiego. To rzadki przypadek, w którym przygotowanie na przyszły kanał zwraca się w kanale bieżącym.
FAQ
Czym agentic commerce różni się od zwykłej porównywarki cen?
Porównywarka zestawia oferty według z góry ustalonych kryteriów i pokazuje wynik człowiekowi. Agent interpretuje zapytanie w języku naturalnym, sam decyduje, które kryteria są istotne, weryfikuje dane bezpośrednio u sprzedawcy przed rekomendacją, a w części wdrożeń finalizuje transakcję bez udziału użytkownika.
Czy muszę wdrażać osobny protokół checkoutu dla agentów?
W większości przypadków nie. Zdecydowana większość ruchu z asystentów trafia dziś do sklepu jako zwykły użytkownik z linkiem, więc priorytetem jest utrzymanie kontekstu wariantu i uproszczenie standardowego checkoutu. Delegowany checkout to zwykle funkcja platformy e-commerce, a nie samodzielny projekt sklepu.
Jakie dane produktowe są absolutnie obowiązkowe?
Identyfikator (GTIN lub MPN), marka, cena z walutą, dostępność, koszt i termin dostawy oraz polityka zwrotów. Do tego parametry, po których klienci filtrują w danej kategorii, podane jako osobne pola, a nie w treści opisu. Warianty muszą mieć własną cenę i dostępność.
Jak sprawdzić, czy mój sklep jest widoczny dla agentów AI?
Trzy testy: zadaj kilku asystentom typowe zapytanie zakupowe z twojej kategorii; przejrzyj logi serwera pod kątem wizyt crawlerów agentowych na kartach produktów; zwaliduj znaczniki produktowe i porównaj ich zawartość z aktualnym feedem.
Czy blokowanie botów AI w robots.txt chroni sklep przed utratą marży?
Blokada odcina sklep od kanału, ale nie chroni przed porównaniem cen: agent i tak zbierze dane z porównywarek, marketplace’ów i feedów partnerskich. Efektem jest oferta porównywana bez twojego udziału, na danych, nad którymi nie masz kontroli.