Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
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ł.
Warto oddzielić trzy poziomy dojrzałości, bo w komunikacji prasowej wszystkie występują pod jednym hasłem.
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.
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.
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.
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.
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ł.
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ń.
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ś.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |