Google Business Agent to system AI, który odpowiada na pytania klientów w imieniu konkretnego sprzedawcy — na podstawie danych z Merchant Center, nie z ogólnodostępnych źródeł. W naszych audytach feedów produktowych widzimy, że średnio 23% atrybutów brakuje w feedach polskich sklepów, co bezpośrednio ogranicza zakres pytań, na które agent może odpowiedzieć. Ten artykuł analizuje 4 patenty Google opisujące architekturę agentów i grounding, pokazuje 8 scenariuszy interakcji (od pytań faktograficznych po cross-sell), oraz podaje konkretne kroki przygotowania danych w Merchant Center pod business agent.
Czym różni się agent marki od ogólnej odpowiedzi AI?
Kiedy użytkownik pyta AI o produkt, odpowiedź może pochodzić z wielu źródeł: strony producenta, recenzji, porównywarek, forów i danych zakupowych. System syntetyzuje informacje i prezentuje odpowiedź. Agent marki to inna koncepcja – to system AI, który odpowiada w imieniu konkretnego sprzedawcy, korzystając z danych tego sprzedawcy.
| Ogólna odpowiedź AI | Agent marki | |
|---|---|---|
| Źródło danych | Wiele źródeł publicznych | Dane sprzedawcy z Merchant Center + strona |
| Perspektywa | Neutralna, porównawcza | Perspektywa konkretnej marki/sprzedawcy |
| Aktualność cen | Może być nieaktualna | Z feeda – powinna być aktualna |
| Dostępność wariantu | Ogólna informacja | Konkretny wariant u konkretnego sprzedawcy |
| Warunki zakupu | Ogólnikowe | Konkretne: dostawa, zwroty, gwarancja |
| Cel | Informowanie i porównywanie | Prowadzenie do transakcji |

To rozróżnienie jest ważne, bo stawia inne wymagania wobec danych. Ogólna odpowiedź AI może opierać się na publicznie dostępnych informacjach. Agent marki musi korzystać z danych aktualnych, kompletnych i spójnych, bo reprezentuje sprzedawcę i wpływa na decyzję zakupową.
Jakie dane z Merchant Center zasilają agenta marki?
Agent marki potrzebuje danych produktowych, żeby działać. Merchant Center jest naturalnym źródłem tych danych, bo — jak opisuje dokumentacja Merchant Center — już teraz zawiera informacje potrzebne do transakcji: tytuł, cenę, dostępność, GTIN, zdjęcia, opis, dane dostawy i politykę zwrotów.
Katalog produktów to pełna lista produktów z atrybutami – im kompletniejszy feed, tym więcej pytań agent może obsłużyć. Bazą jest product feed jako źródło danych dla AI — bez kompletnego feedu agent nie ma na czym budować. Ceny i promocje muszą być aktualne, łącznie z cenami promocyjnymi i datami ich obowiązywania, bo agent musi znać cenę w momencie rozmowy. Problem data freshness w AI Mode jest tu jeszcze ostrzejszy niż w standardowym shopping. Dostępność per wariant jest kluczowa, ponieważ agent nie może polecać produktu, którego nie ma w magazynie. Atrybuty konwersacyjne w Merchant Center decydują o tym, czy agent dopasuje wariant do pytania. Dane dostawy (koszt, czas, metody) — zgodnie ze schematem schema.org/Product — muszą być kompletne, bo użytkownik pytający o dostawę oczekuje konkretnej odpowiedzi. Polityki zwrotów, gwarancji i reklamacji muszą być w ustrukturyzowanej formie, żeby agent nie wprowadzał w błąd.
Jakość odpowiedzi agenta jest bezpośrednio proporcjonalna do jakości danych w Merchant Center. Niekompletny feed oznacza niekompletnego agenta, bo system nie wymyśli danych, których nie ma w źródle.
Jak pogodzić głos marki z faktami produktowymi?
Agent marki operuje na granicy między dwoma światami: głosem marki (ton komunikacji, pozycjonowanie, wartości) i faktami produktowymi (cena, specyfikacja, dostępność). Głos marki jest właściwy w tonie odpowiedzi, kontekście marki i pozycjonowaniu. Fakty produktowe są potrzebne w każdym miejscu, gdzie użytkownik podejmuje decyzję: cena musi być aktualna, dostępność musi odpowiadać stanowi faktycznemu, specyfikacja musi być zgodna z kartą produktu, a warunki dostawy i zwrotów muszą odpowiadać regulaminowi.
Problem pojawia się, gdy głos marki zastępuje fakty. Agent, który odpowiada: nasz produkt jest najlepszy na rynku zamiast podać cenę i specyfikację, nie pomaga użytkownikowi. Agent, który bagatelizuje wadę produktu widoczną w opiniach, traci wiarygodność. Więcej o równowadze między danymi marketingowymi a faktami produktowymi pisaliśmy w kontekście content marketingu. Na wiarygodność wpływa też merchant trust score — ogólna ocena wiarygodności sprzedawcy przez system AI.
Jakie scenariusze interakcji musi obsłużyć agent marki?
Agent marki musi obsługiwać różne typy zapytań. Każdy typ wymaga innych danych i innej logiki odpowiedzi.
| Typ zapytania | Przykład | Wymagane dane |
|---|---|---|
| Faktograficzne | Jaka jest pojemność baterii modelu X? | Specyfikacja produktu |
| Porównawcze | Czym X różni się od Y? | Atrybuty obu produktów do zestawienia |
| Dobór wariantu | Który rozmiar wybrać przy wzroście 175 cm? | Tabela rozmiarów, warianty |
| Produkt powiązany | Co pasuje do modelu X? | Dane o kompatybilności, akcesoria |
| Warunek budżetowy | Najlepszy model do 2000 zł? | Ceny i filtrowanie po cenie |
| Brak produktu | Czy macie model Z? | Pełny katalog – agent musi wiedzieć, czego NIE ma |
| Nieaktualna promocja | Czy promocja na X jeszcze trwa? | Daty promocji, aktualna cena |
| Poza danymi marki | Jak X wypada na tle konkurencji A, B, C? | Agent powinien znać granice swoich danych |
Ostatni scenariusz jest szczególnie ważny: agent marki powinien wiedzieć, czego nie wie. Pytanie o konkurencję wykracza poza dane sprzedawcy i agent powinien to zasygnalizować, zamiast spekulować. Dylemat marketplace vs sklep własny w AI search ma tu dodatkowy wymiar — agent reprezentuje jednego sprzedawcę, nie marketplace.
Jak zapewnić aktualność cen i dostępności w odpowiedziach agenta?
Agent odpowiada w czasie rzeczywistym, ale jego dane mogą mieć opóźnienie. Cena w feedzie Merchant Center jest aktualna na moment ostatniej aktualizacji feeda, nie na moment rozmowy z użytkownikiem.
| Częstotliwość aktualizacji | Ryzyko nieaktualnych danych | Scenariusz |
|---|---|---|
| Raz dziennie | Wysokie | Agent podaje wczorajszą cenę promocyjną |
| Co 4 godziny | Średnie | Wyprzedany wariant polecany przez 2-3 godziny |
| Co godzinę | Niskie | Krótkie okno na nieaktualną dostępność |
| Real-time (API) | Minimalne | Agent zawsze zna aktualny stan |
Scenariusze ryzyka są konkretne: promocja się skończyła, a agent nadal podaje cenę promocyjną; produkt się wyprzedał, ale agent go poleca; cena się zmieniła, ale agent podaje starą; wariant jest niedostępny, ale agent go rekomenduje. Każdy z tych scenariuszy podważa zaufanie użytkownika do agenta i do marki. Dlatego częstotliwość aktualizacji feeda staje się krytyczna w kontekście business agent, jeszcze bardziej niż w standardowych Shopping Ads. Spójność danych między feedem, kartą produktu a danymi strukturalnymi jest warunkiem, bez którego agent traci wiarygodność.
Co robi agent, gdy brakuje danych lub źródła są sprzeczne?
Agent marki musi radzić sobie z sytuacjami, w których nie ma wystarczających danych lub dane są sprzeczne. Gdy użytkownik pyta o atrybut, którego nie ma w feedzie (np. materiał podszewki kurtki), agent powinien poinformować, że nie ma tej informacji w danych produktowych i odesłać do karty produktu na stronie. Lepsze: Nie mam tej informacji w danych produktowych. Sprawdź kartę produktu niż zmyślona odpowiedź.
Niektóre kategorie produktów (alkohol, suplementy, produkty medyczne) podlegają ograniczeniom w komunikacji. Agent marki musi przestrzegać tych samych polityk, co reklamy – nie może obiecywać efektów zdrowotnych ani rekomendować produktów ograniczonych wiekowo.
Gdy dane z feeda nie zgadzają się z treścią strony (np. inna cena, inny opis), poprawne zachowanie to odpowiedź na podstawie feeda (bo to źródło strukturalne) z sygnalizacją możliwej rozbieżności i odesłaniem do strony produktu. To jeden z argumentów za regularnym audytem treści i spójnością danych między feedem a stroną. Mechanizmy fact-checkingu danych produktowych z wielu źródeł porównują informacje z feedu, strony i profilu Google Business — a spójność danych w DOM i schema wpływa na to, co crawler odczytuje.
Jakie patenty Google opisują architekturę agentów i grounding?
Ramka metodologiczna: poniższe patenty opisują mechanizmy techniczne zgłoszone lub przyznane Google. Nie dowodzą, że są obecnie używane w Google Business Agent. Wykorzystujemy je wyłącznie jako kontekst architektoniczny, zgodnie z metodyką diagnostyczną opracowaną przez Semgence (zgłoszenie patentowe w toku). Klasyfikacja: Direct = mechanizm bezpośrednio powiązany; Supporting = mechanizm wspierający; Context = kontekst architektoniczny.
US20250348526A1 – agent LLM i funkcje aplikacji (Direct)
Patent US20250348526A1 opisuje architekturę, w której agent oparty na LLM realizuje zadania użytkownika przez wywoływanie funkcji aplikacji. W kontekście business agent oznacza to, że agent nie generuje odpowiedzi z pamięci, lecz wywołuje funkcje pobierające dane z Merchant Center, sprawdzające dostępność i wyliczające koszt dostawy. Jakość odpowiedzi zależy od jakości danych zwracanych przez te funkcje.
US20250103640A1 – grounding i cytowania (Supporting)
Patent US20250103640A1 opisuje system, który wiąże wygenerowaną odpowiedź z konkretnymi fragmentami źródeł. W kontekście agenta marki agent powinien móc wskazać, skąd pochodzi informacja – z feeda, z karty produktu, z opinii – co zwiększa wiarygodność odpowiedzi i pozwala użytkownikowi zweryfikować fakty.
US20250355958A1 – dekompozycja pytania na podtematy (Supporting)
Patent US20250355958A1 opisuje system, który rozkłada złożone pytanie na prostsze podpytania i odpowiada na każde osobno. Przykład: Czy macie torbę podróżną do 500 zł, wodoodporną, z kieszenią na laptop? – agent rozkłada na: cena ≤ 500, materiał = wodoodporny, cecha = kieszeń na laptop i filtruje katalog. To bezpośrednio łączy się z wymaganiem kompletnych atrybutów w feedzie.
US20230342411A1 – konsensus wielu źródeł (Context)
Patent US20230342411A1 opisuje system, który buduje odpowiedź na podstawie konsensusu wielu źródeł. W kontekście agenta marki system mógłby zestawiać dane z feeda, opinie użytkowników i treść strony, żeby zbudować odpowiedź odzwierciedlającą różne perspektywy na produkt.
Jak mierzyć skuteczność agenta marki?
Agent marki to system, nie osoba. Mierzenie jego skuteczności powinno opierać się na metrykach obiektywnych, nie na ocenach typu: czy agent był miły?
| Metryka | Definicja | Cel |
|---|---|---|
| Answer accuracy | % odpowiedzi zgodnych z danymi w feedzie/na stronie | Wiarygodność |
| Coverage rate | % pytań produktowych, na które agent ma dane do odpowiedzi | Kompletność |
| Referral rate | % interakcji kończących się przejściem do strony produktu | Konwersja |
| Hallucination rate | % odpowiedzi zawierających informacje spoza danych sprzedawcy | Bezpieczeństwo |
| Boundary respect | % pytań spoza zakresu poprawnie odrzuconych | Kontrola |
| Freshness lag | Średnie opóźnienie danych agenta vs stan faktyczny | Aktualność |
W naszych audytach Merchant Center widzimy, że średnio 23% atrybutów produktowych brakuje w feedach polskich e-commerce — to bezpośrednio przekłada się na coverage rate agenta.
Nie traktuj agenta jako kanału sprzedaży z bezpośrednią atrybucją. Agent wspiera decyzję zakupową, ale konwersja może nastąpić w innym kanale. Mierz wspomagane konwersje, nie tylko last-click. Problem atrybucji w agentic commerce jest tu szczególnie trudny, bo standardowy GA4 nie rozróżnia źródła rekomendacji agenta.
Co oficjalnie potwierdza dokumentacja?
Na dzień weryfikacji (sierpień 2026) Google zapowiedział rozwój funkcji agentowych w Merchant Center. Dokumentacja Merchant API zawiera elementy wskazujące na kierunek rozwoju w stronę business agent, a blogpost Google o agentic checkout potwierdza strategiczny kierunek.
Dokumentacja nie potwierdza dokładnego zakresu funkcji business agent, daty pełnego wdrożenia, wymagań technicznych po stronie sprzedawcy, modelu cenowego ani rynków, na których funkcja będzie dostępna. Artykuł opisuje kierunek rozwoju i wymagania wynikające z logiki systemu – konkretna implementacja może się różnić.
Co może zrobić sklep, żeby być gotowym?
| Obszar gotowości | Wymaganie | Priorytet |
|---|---|---|
| Kompletność feeda | Wszystkie atrybuty wypełnione (title, GTIN, price, shipping, return_policy) | Krytyczny |
| Częstotliwość aktualizacji | Minimum co 4 godziny, idealnie real-time przez API | Wysoki |
| Spójność feed vs strona | Cena, dostępność i opis zgodne między feedem a kartą produktu | Krytyczny |
| Warianty z GTIN | Każdy wariant (rozmiar, kolor) z osobnym GTIN w feedzie | Wysoki |
| Dane dostawy | Koszt, czas i metody dostawy w ustrukturyzowanej formie | Średni |
| Polityka zwrotów | Warunki zwrotów i gwarancji w feedzie (return_policy) | Średni |
Fundamentem jest uzupełnienie feeda do maksimum. Każdy brakujący atrybut to pytanie, na które agent nie będzie mógł odpowiedzieć. Priorytet to shipping, return policy, warianty i GTIN. Zwiększ częstotliwość aktualizacji feeda, bo agent odpowiada w czasie rzeczywistym, a Twoje dane powinny być jak najbardziej aktualne.
Zadbaj o spójność między feedem a stroną produktu. Rozbieżności oznaczają ryzyko halucynacji agenta. Audyt widoczności w AI Semgence obejmuje tę analizę. Checklista gotowości na agentic commerce obejmuje też integrację z API checkout. Przygotuj dane o warunkach (dostawa, zwroty, gwarancja, reklamacje) w ustrukturyzowanej formie i zdefiniuj granice, na jakie pytania agent może odpowiadać.
Według Think with Google zapytania produktowe z intencją zakupową rosną kilkadziesiąt procent rocznie. Nie czekaj na oficjalny launch. Przygotowanie danych to ta sama praca, którą musisz zrobić pod pozycjonowanie sklepu w AI ogólnie. Więcej o strategicznym podejściu do danych produktowych w kontekście pozycjonowania w AI.
Czego nie robić?
Nie traktuj agenta jak chatbota z FAQ, bo chatbot odpowiada na zdefiniowane pytania, a agent ma rozumieć kontekst i dane produktowe dynamicznie. Nie polegaj na głosie marki kosztem faktów, bo użytkownik pyta o cenę, dostępność i specyfikację, nie o misję firmy.
Nie publikuj danych agenta jako metryki sprzedażowej, bo interakcja z agentem to nie transakcja. Nie ignoruj scenariuszy brzegowych (brak produktu, sprzeczne dane, pytanie poza zakresem), bo to właśnie te sytuacje definiują jakość agenta. Wreszcie, nie automatyzuj bez kontroli, ponieważ agent generujący odpowiedzi na podstawie niekompletnych danych może szkodzić marce bardziej niż pomagać. Więcej o kontroli jakości danych w kontekście audytu SEO. Rolę opinii klientów i analizy sentymentu w budowaniu wiarygodności agenta trudno przecenić — negatywny sentyment obniża zaufanie do odpowiedzi. Personalizacja rekomendacji AI uwzględnia historię interakcji, więc agent z niskim trust score traci szanse na kolejne polecenie. Całościowe podejście do widoczności produktowej opisujemy w artykule o AI visibility w e-commerce.
Jakie powiązane zapytania prowadzą do business agent?
Temat business agent łączy się z wieloma ścieżkami wyszukiwania. Poniżej mapujemy najważniejsze zapytania pokrewne.
Co to jest Google Business Agent?
Google Business Agent to koncepcja systemu AI, który działa po stronie sprzedawcy, odpowiadając na pytania klientów o produkty na podstawie danych z Merchant Center. W odróżnieniu od ogólnej odpowiedzi AI (która syntetyzuje informacje z wielu źródeł), business agent reprezentuje konkretnego sprzedawcę i korzysta z jego danych produktowych. Na dzień weryfikacji Google zapowiedział tę funkcję, ale nie podał pełnych szczegółów implementacji.
Jak przygotować dane produktowe pod AI agenta?
Przygotowanie danych to w praktyce maksymalizacja kompletności feeda w Merchant Center. Kluczowe atrybuty to nie tylko podstawowe (title, price, availability), ale również shipping, return policy, warianty z osobnymi GTIN, tabele rozmiarów i dane o kompatybilności z innymi produktami. Im więcej atrybutów agent ma do dyspozycji, tym więcej typów pytań może obsłużyć. Szerszą perspektywę na optymalizację danych opisujemy w pozycjonowaniu w AI.
Czym różni się business agent od chatbota na stronie?
Chatbot na stronie sklepu działa na zdefiniowanych regułach i odpowiada na pytania z przygotowanej bazy FAQ. Business agent oparty na LLM rozumie kontekst pytania, dynamicznie przeszukuje katalog produktów i buduje odpowiedź na podstawie aktualnych danych. Kluczowa różnica to zdolność do obsługi zapytań, których nie przewidziano w FAQ, oraz do porównywania produktów w ramach katalogu.
Czy AI agent może sprzedawać produkty za mnie?
W modelu UCP (Universal Commerce Protocol) transakcja może zostać sfinalizowana bezpośrednio w interfejsie AI, bez przechodzenia na stronę sprzedawcy. Business agent jest elementem tej układanki – odpowiada na pytania i prowadzi do checkout. Ale agent sam nie „sprzedaje” w sensie tradycyjnym – udostępnia dane, na podstawie których użytkownik podejmuje decyzję.
Jak mierzyć skuteczność AI agenta sprzedażowego?
Skuteczność agenta mierzy się metrykami obiektywymi: answer accuracy (% odpowiedzi zgodnych z feedem), coverage rate (% pytań obsłużonych), referral rate (% przejść do strony produktu), hallucination rate (% odpowiedzi z fałszywymi informacjami) i freshness lag (opóźnienie danych). Nie mierz „zadowolenia” ani „uprzejmości” – to metryki chatbotowe, nie agentowe. Semgence buduje framework pomiaru w ramach konsultacji SEO.
Czy Twój sklep jest gotowy na business agent?
Kiedy business agent będzie dostępny?
Nie mamy potwierdzonej daty. Google wdraża funkcje agentowe stopniowo. Rekomendujemy przygotowanie danych niezależnie od daty launchu, bo te same dane potrzebujesz do obecnego pozycjonowania w AI.
Czy business agent zastąpi dział obsługi klienta?
Nie w przewidywalnej przyszłości. Agent marki może obsługiwać standardowe pytania produktowe, ale nie zastąpi ludzkiej obsługi w złożonych scenariuszach: reklamacje, indywidualne negocjacje, problemy z zamówieniem. Traktuj go jako warstwę wsparcia, nie zamiennik.
Czy muszę mieć duży katalog produktów?
Nie. Agent działa na danych, które masz. Sklep z 50 produktami z kompletnym feedem będzie lepiej obsłużony niż sklep z 5000 produktami z niepełnymi danymi. Jakość danych ponad ilość.
Czy business agent wymaga osobnej integracji z Merchant Center?
Na podstawie dostępnej dokumentacji i patentów zakładamy, że agent będzie korzystał z istniejących danych w Merchant Center. Osobna integracja może być potrzebna dla zaawansowanych funkcji (np. real-time inventory), ale podstawą będzie feed produktowy, który już przesyłasz.
Jak przygotować feed produktowy pod business agent?
Maksymalizuj kompletność feeda w Merchant Center. Kluczowe atrybuty to nie tylko podstawowe (title, price, availability), ale również shipping, return policy, warianty z osobnymi GTIN, tabele rozmiarów i dane o kompatybilności. Im więcej atrybutów agent ma do dyspozycji, tym więcej typów pytań może obsłużyć.
Czym business agent różni się od chatbota na stronie?
Chatbot działa na zdefiniowanych regułach i FAQ. Business agent oparty na LLM rozumie kontekst pytania, dynamicznie przeszukuje katalog produktów i buduje odpowiedź na podstawie aktualnych danych. Kluczowa różnica to zdolność do obsługi zapytań, których nie przewidziano w FAQ.

