Jak dostosować strategię e-commerce pod zakupy dokonywane bezpośrednio przez agentów sztucznej inteligencji.

Przygotowanie sklepu na klienta bez oczu

Baner wejsciowyParallax

Jak dostosować strategię e-commerce pod zakupy dokonywane bezpośrednio przez agentów sztucznej inteligencji.

Przygotowanie sklepu na klienta bez oczu

Autor nie posiada zdjęcia
Tomasz Piasecki
31 grudnia 2025

W ciągu ostatnich kilku miesięcy dostałem to pytanie od trzech różnych klientów w niemal identycznym brzmieniu: czy musimy już coś zrobić, żeby nas nie ominęły zakupy robione przez sztuczną inteligencję. Odpowiedź jest niewygodna, bo składa się z dwóch części, które brzmią sprzecznie.

Część pierwsza: nie, nic nie musisz robić w panice, bo na koniec 2025 roku żaden z tych mechanizmów nie działa w polskim sklepie. Część druga: tak, warto zająć się kilkoma rzeczami, ale nie ze względu na agenty — te same poprawki podnoszą sprzedaż w kanałach, które już masz.

Poniżej rozdzielam to, co faktycznie istnieje, od tego, co jest specyfikacją albo zapowiedzią, i pokazuję, w jakiej kolejności bym się za to zabierał.

Co realnie istnieje na koniec 2025 roku

Warto oddzielić trzy poziomy dojrzałości, bo w komunikacji prasowej wszystkie występują pod jednym hasłem.

  • Działające, ale wąsko — w listopadzie Google udostępniło w wyszukiwarce zakup realizowany za użytkownika po spełnieniu warunku cenowego. Wybrani sprzedawcy w Stanach Zjednoczonych, wcześniej podgląd pokazany na konferencji w maju. We wrześniu OpenAI uruchomiło zakupy w oknie czatu — również Stany Zjednoczone, na start sprzedawcy z jednej platformy, kolejni zapowiedziani.
  • Specyfikacje bez masowego użycia — otwarty protokół płatności inicjowanych przez agenty ogłoszony przez Google w połowie września, z ponad sześćdziesięcioma partnerami z branży płatniczej, oraz protokół zakupowy współtworzony przez OpenAI ze Stripe. To dokumenty i biblioteki, nie kanał sprzedaży z ruchem.
  • Agenty ogólnego przeznaczenia — przeglądarki i asystenci, które klikają po stronach za użytkownika. Istnieją, są dostępne, ale poruszają się po zwykłym sklepie tak jak człowiek: przez interfejs, formularze i koszyk.

Z perspektywy polskiego sklepu praktyczne znaczenie ma dziś głównie trzeci punkt. I to jest dobra wiadomość, bo przygotowanie się na niego nie wymaga żadnej integracji — wymaga porządku, którego brak i tak kosztuje.

Dane produktowe jako interfejs dla maszyny

Jeśli mam wskazać jedną rzecz, która decyduje o tym, czy produkt zostanie w ogóle rozważony przez jakikolwiek system automatyczny, to są to dane produktowe.

Człowiek na karcie produktu domyśli się z fotografii, że sukienka jest granatowa, a z opisu, że rozmiarówka jest wąska. System czyta atrybuty. Jeśli nie ma osobnego pola z kolorem, materiałem, rozmiarem, płcią i grupą wiekową, produkt nie zostanie dopasowany do zapytania, w którym te cechy występują.

Praktycznie oznacza to trzy rzeczy. Pierwsza: pełne wypełnienie atrybutów opcjonalnych, nie tylko wymaganych — te opcjonalne są dokładnie tym, po czym system filtruje. Druga: identyfikatory. Kod producenta i globalny numer handlowy pozwalają połączyć Twoją ofertę z tym samym produktem u innych sprzedawców, a bez nich produkt jest samotnym bytem. Trzecia: aktualność stanów i cen — rozbieżność między ofertą w danych a ceną na stronie kończy się odrzuceniem oferty, a w scenariuszu z zakupem realizowanym automatycznie po prostu przerwaniem transakcji.

Do zarządzania tym po stronie technicznej od sierpnia 2025 roku dostępny jest w wersji ogólnej nowy interfejs programistyczny Merchant API, następca dotychczasowego. Jeśli integracja jest pisana teraz, warto celować w nowszy interfejs, bo starszy ma już zapowiedzianą datę wygaszenia.

Znaczniki na stronie, czyli druga kopia tych samych faktów

Dane w pliku ofertowym widzi Google. Agent, który wchodzi na stronę z zewnątrz, widzi HTML. Dlatego te same informacje muszą być czytelne również tam.

Minimalny zestaw dla sklepu to znacznik produktu z ceną, dostępnością i walutą, znacznik oferty przy każdym wariancie oraz opinie, jeśli są prawdziwe i pochodzą od klientów. Do tego dochodzą dwie rzeczy, które wprowadzono stosunkowo niedawno i które w sklepach wciąż bywają pomijane: polityka zwrotów w znaczniku produktu oraz możliwość opisania jej raz dla całej organizacji, zamiast powtarzania przy każdej pozycji.

Zwroty i dostawa mają tu szczególne znaczenie. To informacje, których system nie zgadnie i nie wywnioskuje z tekstu regulaminu napisanego prawniczym językiem na osobnej podstronie. Jeśli mają wpływać na decyzję, muszą być zapisane w formie, którą maszyna odczyta jednoznacznie.

Sprawdzenie tego jest tanie: wystarczy przepuścić kilka kart produktu przez walidator danych strukturalnych i porównać, czy to, co widzi maszyna, zgadza się z tym, co widzi klient.

Czy w ogóle wpuszczać roboty modeli językowych

To decyzja, której nie da się uniknąć, a która w wielu sklepach została podjęta przez przypadek — czyli nie została podjęta wcale.

Roboty dzielą się na trzy grupy o zupełnie różnych konsekwencjach. Pierwsza to roboty zbierające treści do trenowania modeli; blokada nie wpływa na widoczność w wyszukiwarce, ale zmniejsza szansę, że model będzie „znał” markę z pamięci. Druga to roboty obsługujące wyszukiwanie wewnątrz asystenta — ich zablokowanie oznacza brak obecności w odpowiedziach, w których pojawiają się odnośniki do sklepów. Trzecia to pobrania inicjowane w danym momencie przez użytkownika, gdy ktoś wkleja adres do czatu.

Dla sklepu z asortymentem masowym zwykle rekomenduję wpuszczenie robotów obsługujących wyszukiwanie i świadomą decyzję co do trenowania. Dla firm, których jedynym aktywem są autorskie treści — na przykład szczegółowe poradniki produktowe — sprawa wygląda inaczej i rozumiem argumenty za blokadą.

Warunek wstępny jest jeden: trzeba wiedzieć, kto faktycznie wchodzi. Bez zaglądania do logów serwera ta rozmowa jest zgadywaniem. Widzę to na większości kont, które przejmuję — nikt nie sprawdził, jaka część zapytań do serwera pochodzi dziś od automatów.

Ścieżka zakupowa, która nie wywraca się bez człowieka

Agent przeglądający stronę jest klientem, który nie widzi, nie domyśla się i nie ma cierpliwości. To bardzo dobry tester jakości sklepu.

Trzy rzeczy wywalają taki proces najczęściej. Pierwsza: koszyk wymagający rejestracji przed poznaniem kosztu dostawy. Druga: koszty i terminy pojawiające się dopiero na ostatnim kroku, po podaniu danych. Trzecia: elementy interfejsu bez opisów dostępnościowych — przyciski będące grafikami bez tekstu, pola formularza bez etykiet, komunikaty błędów przekazywane wyłącznie kolorem obramowania.

Ostatni punkt zasługuje na osobne zdanie, bo jest w tym pewna ironia. Wszystko, co robi się dla dostępności strony dla osób korzystających z czytników ekranu, jednocześnie ułatwia pracę automatowi. Sklep dobrze zrobiony pod kątem dostępności jest z definicji lepiej przygotowany na klienta programowego, i to bez ani jednej linijki kodu napisanej „pod AI”.

Dochodzi do tego kwestia zabezpieczeń. Wszelkie mechanizmy odsiewające boty potraktują agenta jak bota, bo agent nim jest. Nie mam na to dobrej odpowiedzi — na koniec 2025 roku nie ma standardu, który pozwalałby odróżnić automat działający na zlecenie klienta od automatu zbierającego ceny. To realne, nierozwiązane napięcie i warto o tym wiedzieć, zanim ktoś obieca zarządowi gotowość na nowy kanał.

Pomiar: skąd wiadomo, czy to się dzieje

Bez pomiaru cała ta dyskusja jest wróżeniem. Trzy warstwy, które warto ustawić, zanim temat stanie się pilny.

Warstwa serwera: wydzielenie w analizie logów zapytań od znanych robotów asystentów i modeli, z rozbiciem na te grupy. To najbardziej wiarygodne źródło, bo nie zależy od skryptów w przeglądarce.

Warstwa analityki: sprawdzenie, jak w raportach kwalifikuje się ruch przychodzący z asystentów. Odesłania z domen asystentów pojawiają się jako zwykłe źródło odsyłające i łatwo je przeoczyć, jeśli nikt nie stworzył dla nich osobnej grupy kanałów. Odsyłacze bywają też oznaczane parametrami, których nie ma na liście domyślnej.

Warstwa jakościowa: raz w miesiącu zadanie kilku asystentom tych samych pytań zakupowych z Twojej kategorii i zapisanie, kto zostaje wymieniony. To pomiar prymitywny i nieporównywalny między miesiącami, ale lepszy od braku jakiegokolwiek punktu odniesienia. Zawsze zapisuję datę i użyte pytanie, bo odpowiedzi zmieniają się z tygodnia na tydzień.

Kolejność prac i czego bym nie robił

Gdybym miał ułożyć to jako plan na pierwszy kwartał, wyglądałby tak.

Najpierw kompletność i higiena danych produktowych, bo to fundament dla wszystkich kanałów naraz — od kampanii produktowych po jakiekolwiek przyszłe integracje. Potem znaczniki na stronie, w tym zwroty i dostawa. Potem decyzja o dostępie robotów i wdrożenie pomiaru z poprzedniej sekcji. Na końcu przejście ścieżki zakupowej pod kątem dostępności i jasności kosztów.

Czego bym nie robił. Nie budowałbym integracji z protokołami płatniczymi, dopóki nie ma kanału, który by z nich korzystał w Europie — to inwestycja w specyfikację, która jeszcze będzie się zmieniać. Nie tworzyłbym osobnej wersji sklepu „dla AI”, bo utrzymanie dwóch wersji treści zawsze kończy się rozjazdem. I nie przenosiłbym budżetu z kanałów, które policzalnie sprzedają, na obszar, w którym nie mamy jeszcze czego liczyć.

Jedno zdanie na koniec, bo łatwo je zgubić w entuzjazmie: wszystkie prace z tej listy zwracają się nawet w scenariuszu, w którym zakupy agentowe utkną na etapie eksperymentu w Stanach Zjednoczonych. To rzadka sytuacja, w której przygotowanie na niepewną przyszłość jest po prostu dobrą robotą na dziś.

Podziel się tym artykułem z innymi!

Twitter Facebook Linke.din
Autor nie posiada zdjęcia
Tomasz Piasecki
Specjalista Google Ads / SEM
Zajmuję się kampaniami Google Ads i widocznością stron w wyszukiwarce. Na blogu UDI Group piszę o tym, jak ustawienia kampanii i decyzje techniczne przekładają się na realne wyniki. Staram się tłumaczyć mechanizmy, a nie tylko podawać gotowe przepisy.