Czym jest agent zakupowy, a czym nie jest

Słowo „agent” zrobiło się workiem, do którego wrzuca się trzy zupełnie różne rzeczy. Rozdzielam je, bo mają różne konsekwencje dla sklepu.

• Model, który tylko odpowiada — pyta się go o polecenie odkurzacza, dostaje się akapit z kilkoma nazwami i linkami. To nie agent, to wyszukiwanie z warstwą tekstu. Wpływ na sklep jest taki jak wpływ każdego pośrednika treści: albo cię cytuje, albo nie.

• Model, który sam otwiera strony — klika, przewija, wypełnia pola, porównuje warianty w kilku sklepach. Tu zaczyna się agent w sensie właściwym i tu Twoja strona jest testowana na wytrzymałość.

• Model, który domyka transakcję i płaci — to najgłośniejszy scenariusz i jednocześnie najmniej dostępny. Poza wąskimi eksperymentami w Stanach nie jest to dziś rzeczywistość.

Warto też zauważyć, czego w tym opisie nie ma. Agent nie ma własnego indeksu i nie zna Twojego sklepu z pamięci. Korzysta z tego, co poda mu wyszukiwarka, feed produktowy albo sama strona w momencie odwiedzenia. Jest więc raczej niecierpliwym gościem niż nowym kanałem — i jak każdy niecierpliwy gość rezygnuje, gdy coś się nie klika.

Co z tego faktycznie działa dziś

Robię ten przegląd, bo różnica między „pokazane na scenie” a „dostępne w Polsce” jest tu wyjątkowo duża.

OpenAI udostępniło w styczniu Operatora jako podgląd badawczy, początkowo w najdroższym planie i tylko w Stanach; w wakacje ta funkcja przestała być osobnym narzędziem i wróciła jako tryb agenta w głównym interfejsie. Perplexity od lipca oferuje przeglądarkę Comet z wbudowanym agentem, ale w planie za dwieście dolarów miesięcznie i na zaproszenia. Google na majowej konferencji dla twórców pokazało zakupy domykane przez asystenta z opcją zakupu w imieniu użytkownika — jako podgląd w Stanach, nie jako funkcję w panelu.

Dwa tygodnie temu doszedł element, który uważam za ciekawszy od samych demonstracji: Google Cloud ogłosiło Agent Payments Protocol, otwartą specyfikację płatności zlecanych przez agenta, z ponad sześćdziesięcioma partnerami — od Mastercard i PayPal po Adyen i Etsy. To nie produkt, tylko próba ustalenia, jak agent ma udowodnić, że ma zgodę człowieka na wydanie pieniędzy. Sam fakt, że takie ustalenia się zaczęły, mówi więcej o kierunku niż każdy filmik z konferencji.

Na naszym rynku dochodzi jeszcze jedno ograniczenie. Generatywne podsumowania Google widzimy w polskich wynikach od marca, ale osobny tryb konwersacyjny wyszukiwarki po polsku wciąż nie działa. Rozmawiając więc o agentach w Polsce, rozmawiamy w dużej mierze o cudzych zrzutach ekranu.

Skąd agent bierze dane o Twojej ofercie

To pytanie ma odpowiedź bardzo przyziemną i dlatego pocieszającą.

Pierwsze źródło to feed produktowy. Jeśli sklep jest w Merchant Center, dane o cenie, dostępności, identyfikatorach i wysyłce już istnieją w formie maszynowej i to je najczęściej widzi warstwa zakupowa wyszukiwarki. Nie znam sytuacji, w której zaniedbany feed pomagałby czemukolwiek — a przy agentach zaniedbanie robi się kosztowniejsze, bo nikt nie kliknie w kartę produktu, żeby sprawdzić, czy naprawdę jest na stanie.

Drugie źródło to dane strukturalne na stronie produktu: typ Product razem z Offer, ceną, walutą, dostępnością, identyfikatorem, a od niedawna też informacjami o wysyłce i zwrotach. Jeśli te wartości są w kodzie, program nie musi zgadywać.

Trzecie źródło to sam HTML. I tu robi się różnica, którą łatwo przeoczyć: model pobierający stronę zwykłym żądaniem widzi surowy kod, a agent działający w przeglądarce widzi to, co przeglądarka wyrenderuje. Sklep, w którym cena dolatuje skryptem po dwóch sekundach, dla jednego z nich będzie sklepem bez ceny.

Czwarte źródło to wszystko, co o produkcie mówią inni: opinie, porównywarki, wątki na forach. Nie masz nad tym kontroli, ale wpływasz na to jakością obsługi i realną polityką zwrotów.

Gdzie agent się wykłada

Zebrałem to z prób robionych na własnych i klienckich sklepach, bez pretensji do statystyki — traktuj jako listę miejsc do sprawdzenia.

Cena umieszczona wyłącznie w grafice jest dla programu nieczytelna. Dostępność, którą da się poznać dopiero po dodaniu do koszyka, jest niedostępna. Koszt dostawy ujawniany w trzecim kroku zamówienia sprawia, że porównanie ofert wypada na Twoją niekorzyść, bo agent porówna kwoty, których jeszcze nie zna. Wariant produktu wybierany skryptem, bez zmiany adresu, oznacza, że nie ma jak wskazać konkretnego rozmiaru.

Osobna kategoria to przeszkody proceduralne: baner zgód zasłaniający treść, wymuszone logowanie przed zobaczeniem ceny, mechanizmy odsiewające boty. Agent nie jest wtedy złośliwy — po prostu odpada albo, co gorsze, wypełnia luki tym, co uzna za prawdopodobne.

Największym problemem uważam jednak rozbieżności. Cena w feedzie inna niż na stronie, dostępność inna w obu miejscach, promocja widoczna tylko w koszyku. Człowiek to wybaczy albo zapyta na czacie. Program wybierze ofertę, którą rozumie.

Co bym poprawił w sklepie w tej kolejności

Nie przebudowuję niczego pod agentów. Robię rzeczy, które i tak są potrzebne, tylko układam je w kolejności według stosunku efektu do pracy.

• Zgodność feedu ze stroną — cena, dostępność i warianty muszą się zgadzać w obu miejscach. To fundament również dla kampanii produktowych, więc praca nie idzie w jedno zastosowanie.

• Cena i dostępność w treści, nie tylko w skrypcie — obecne w kodzie strony i powtórzone w danych strukturalnych.

• Warunki dostawy i zwrotów opisane maszynowo — pola wysyłkowe w feedzie i znaczniki polityki zwrotów. To dokładnie te dwie rzeczy, o które porównanie ofert się rozbija.

• Osobny adres dla każdego wariantu albo przynajmniej przewidywalny parametr w adresie.

• Parametry techniczne jako tekst, nie jako obrazek z tabelą. Ta zmiana pomaga też wyszukiwarce i użytkownikom telefonów.

• Świadoma decyzja w robots.txt — czy wpuszczasz roboty modeli językowych i te obsługujące odpowiedzi z cytowaniem. To decyzja biznesowa: blokada chroni treść, ale wyklucza z odpowiedzi, w których mógłbyś być wymieniony.

Jak to mierzyć, zanim pojawią się gotowe raporty

Tu muszę być uczciwy: dziś nie ma narzędzia, które pokaże Ci sprzedaż z rekomendacji agenta.

W analityce takie wejścia najczęściej wyglądają na bezpośrednie, bo nie przenoszą informacji o źródle. Rosnący udział ruchu bez źródła jest więc poszlaką, nie dowodem, i sam z siebie nie uzasadnia żadnej decyzji budżetowej.

Sensowniej patrzeć niżej — w logi serwera. Nazwy robotów są jawne, dają się filtrować i pokazują, kto naprawdę przychodzi po Twoje karty produktów oraz czy nie dostaje przy tym błędów. Przy okazji zwykle wychodzą rzeczy niezwiązane z tematem: przeciążone podstrony filtrów, przekierowania w pętli, wolne odpowiedzi w godzinach szczytu.

Jeśli ktoś obiecuje Ci dziś raport „sprzedaży z AI”, to albo liczy wejścia bezpośrednie, albo zgaduje. Wolę powiedzieć klientowi, że tego nie wiem, niż podać mu liczbę, której nie umiem obronić.

Czego bym w tej sprawie nie robił

Nie kupowałbym usługi „optymalizacji pod agentów AI”. W tym, co dziś wiemy, nie ma nic, czego nie da się opisać jako porządnego feedu, poprawnych danych strukturalnych, uczciwych informacji o dostawie i koszyka bez przeszkód.

Nie przenosiłbym też budżetu z kampanii, które sprzedają, do przygotowań na kanał, którego jeszcze nie ma. Agenci zakupowi mogą w ciągu kilku lat zmienić sposób, w jaki część klientów porównuje oferty. Nie zmienią tego, że oferta musi być jasna, cena prawdziwa, a zamówienie łatwe do złożenia.

Co bym robił: pilnował spójności danych, czytał logi raz w miesiącu i śledził, co dokładnie uruchamia Google — bo różnica między zapowiedzią z maja a funkcją dostępną w Polsce bywa liczona w kwartałach. Kiedy ta funkcja tu dotrze, sklep z uporządkowanym feedem nie będzie miał do zrobienia prawie nic.