Gotowość feedu na handel agentowy: czego naprawdę wymagają UCP, ACP i AI Mode

W ciągu ostatnich osiemnastu miesięcy w e-commerce po cichu zaszła zmiana strukturalna, a większość tekstów na ten temat jest albo przesadnie entuzjastyczna, albo mglista.

Oto konkretna wersja. Gdy kupujący prosi asystenta AI o znalezienie produktu, asystent nie odwiedza twojej strony głównej. Nie widzi twoich zdjęć, historii marki ani opisu produktu, nad którym męczył się twój copywriter. Odczytuje ustrukturyzowane dane produktowe – feed, blok schema, odpowiedź API – i na tej podstawie decyduje, czy polecić ciebie, czy kogoś innego.

Twój feed zawsze był danymi wejściowymi dla twoich reklam. Teraz jest danymi wejściowymi dla samej rekomendacji.

Obecnie o tym, jak to działa, decydują trzy systemy: Universal Commerce Protocol (UCP) Google, Agentic Commerce Protocol (ACP) OpenAI i Stripe oraz program dla sprzedawców Perplexity. Często pisze się o nich tak, jakby były tym samym w różnych logotypach. Tak nie jest. Korzystają z różnych danych, w różnych formatach, mają różne wymagania i działają w różnych krajach.

Ten przewodnik opisuje, czego każdy z nich faktycznie wymaga na poziomie pól, co naprawdę się pokrywa, a co nie, oraz – ponieważ większość czytelników tego bloga nie sprzedaje głównie w Stanach Zjednoczonych – co warto zrobić, jeśli agentowy proces zakupu (agentic checkout) nie dotarł jeszcze na twój rynek.

Krajobraz bez upiększeń

Dwie obserwacje, zanim przejdziemy dalej.

Po pierwsze: odkrywanie i finalizacja zakupu to osobne problemy. Bycie znajdowanym przez agenta AI to problem jakości danych, który dotyczy całego świata – już dziś. Możliwość dokonania transakcji wewnątrz interfejsu AI to problem integracji protokołu, obecnie ograniczony do kilku rynków. Mylenie tych dwóch kwestii to najczęstszy błąd w publikacjach na ten temat, który prowadzi sprzedawców spoza USA do wniosku, że nic z tego ich nie dotyczy. Jest dokładnie odwrotnie – warstwa odkrywania dotyczy wszystkich i to w niej leży obecnie niemal cała dostępna wartość.

Po drugie: protokoły zbiegają się w zakresie infrastruktury, a nie danych. UCP wprost współpracuje z A2A, AP2 i MCP. ACP opiera się na tej samej ogólnej idei. Ich schematy produktów pozostają jednak naprawdę różne, a feed zbudowany dla jednego nie zadziała po prostu w drugim. To problem zarządzania feedami, a nie strategii, i ma proste rozwiązanie: utrzymuj jedno wzbogacone wewnętrzne źródło prawdy i generuj z niego eksporty dla poszczególnych miejsc docelowych.

Warstwa 1: podstawa odkrywania (dotyczy wszystkich, już dziś)

Zanim zajmiesz się czymkolwiek specyficznym dla protokołów, istnieje zestaw wymagań wspólny dla wszystkich tych systemów. Jeśli z tego artykułu zrobisz tylko jedno, zrób tę warstwę. Nie wymaga żadnej pracy integracyjnej, a to właśnie ona faktycznie decyduje o tym, czy zostaniesz polecony.

Identyfikatory produktów

GTIN to klucz łączący cały ekosystem zakupów z AI. Każdy z tych systemów używa standardowych identyfikatorów, aby dopasować twój produkt do tego samego produktu w innych miejscach – by porównać ceny, zagregować recenzje i wiedzieć, że twoja oferta i oferta w serwisie z recenzjami opisują ten sam przedmiot.

Brakujące GTIN nie generują komunikatu o błędzie. Generują ciszę: twój produkt po prostu nie bierze udziału w porównaniu, które przeprowadza agent. Perplexity podobno ocenia kompletność identyfikatorów surowiej niż Google.

Zbadaj pokrycie GTIN jako odsetek aktywnych SKU. Jeśli jest poniżej 90%, ta liczba to twój pierwszy projekt.

Kompletność atrybutów

Tradycyjne reklamy produktowe działały na dość niewielkim zestawie wymaganych atrybutów. Agent analizuje wszystko, co mu dasz. Każde wypełnione pole to potencjalny powód, dla którego agent może cię polecić – materiał, wymiary, kompatybilność, instrukcje pielęgnacji, wymagania zasilania, warunki gwarancji.

Zmiana myślenia polega na tym: atrybut nie jest już wartością filtra. Jest argumentem. material: full-grain leather to nie aspekt wyszukiwania – to zdanie, którego agent użyje, gdy kupujący zapyta, która z dwóch toreb lepiej się zestarzeje.

Spójność na każdej powierzchni

To wymóg najczęściej pomijany i najbardziej narażający cię na straty.

Człowiek, który widzi ₺2,499 na stronie produktu i ₺2,399 w wyniku porównania, wzrusza ramionami i idzie dalej. Agent traktuje taką rozbieżność jako sygnał o wiarygodności twoich danych – a finalizacja zakupu, która się nie powiodła, bo zmieniła się cena, to dla operatora agenta znacznie gorszy wynik niż po prostu niepolecenie ciebie.

Sprawdź spójność między: stronami produktów, feedem w Merchant Center, danymi strukturalnymi na stronie i wszystkimi ofertami na marketplace’ach, które prowadzisz. Ceny, dostępność, warunki wysyłki i polityka zwrotów muszą się zgadzać. Zwłaszcza politykę zwrotów i wysyłki agenci coraz częściej odczytują i przytaczają kupującym.

Aktualność

<!-- İç link: /feed-update-frequency -->

Nocne odświeżanie feedu już nie wystarcza. Shopping Graph Google odświeża dane w skali liczonej w miliardach ofert na godzinę i preferuje dane na żywo; przyjmowanie feedów przez OpenAI dopuszcza odświeżanie nawet co 15 minut.

Powód nie jest kosmetyczny. Gdy agent jest w stanie sfinalizować transakcję, nieaktualne dane o stanach magazynowych nie kończą się lekko rozczarowanym kupującym – kończą się nieudaną transakcją. A systemy, w których transakcje się nie udają, tracą na wadze.

Praktyczny cel: ceny i dostępność propagowane w ciągu 15 minut dla szybko rotujących produktów i co najmniej co godzinę dla pozostałych. Dla większości sprzedawców oznacza to przejście od zaplanowanego pobierania plików do aktualizacji przez API lub w modelu push.

Dostęp dla crawlerów

Sprawdź swój plik robots.txt pod kątem crawlerów AI. Wielu sprzedawców odruchowo zablokowało je w latach 2024 i 2025 podczas debaty „czy pozwalać AI uczyć się na naszych treściach” i nigdy nie wróciło do tej decyzji. Zablokowanie crawlera, który zasila indeks zakupowy, to inna decyzja niż zablokowanie crawlera trenującego – i często podejmuje się ją przypadkiem, w zespole, który nigdy nie postrzegał jej jako decyzji handlowej.

Warstwa 2: Google – atrybuty konwersacyjne

To najbardziej konkretna, najrzadziej omawiana i najszybciej możliwa do wdrożenia część całego tematu – tę sekcję przeczytałbym dwa razy.

Razem z UCP Google dodał do specyfikacji danych produktowych Merchant Center zestaw atrybutów konwersacyjnych. Są opcjonalne, uzupełniają istniejące dane produktowe, a ich wyraźnym celem jest pomoc systemom AI i agentom konwersacyjnym w zrozumieniu szczegółowych niuansów twoich produktów. Google zaznacza, że ich dodanie nie wpływa na status zatwierdzenia istniejących produktów.

Ten ostatni punkt ma znaczenie: ryzyko jest zerowe. Dodajesz dane opisowe, nie zmieniasz niczego, co Google weryfikuje przy zatwierdzaniu.

Oto ten zestaw:

Przykład opracowany przez samo Google, dla jednego wariantu telefonu, łączy w jednym produkcie item_group_title, variant_option, question_and_answer, product_highlight, product_detail, related_product, popularity_rank i document_link obok standardowych atrybutów.

Dlaczego właśnie te sześć i do czego naprawdę służą

Zobacz, co każdy z nich daje agentowi:

• question_and_answer to scenariusz agenta. Kupujący pyta „czy to można myć w zmywarce?”, a agent albo ma twoją odpowiedź, albo nie. Jeśli nie ma, albo mówi, że nie wie – co oznacza utraconą sprzedaż – albo poleca konkurenta, który wypełnił to pole.
• document_link daje agentowi dokument, na podstawie którego może wnioskować. Instrukcja montażu odpowiada na pytanie „jak trudno to złożyć?”. Karty katalogowe odpowiadają na pytania o kompatybilność, których nie byłeś w stanie przewidzieć.
• related_product to sposób, w jaki cross-selling przetrwa zniknięcie twojej strony ze ścieżki zakupowej. Zwłaszcza required_part zapobiega najgorszemu scenariuszowi w handlu agentowym: kupujący kupuje coś, co samo w sobie nie działa.
• item_group_title i variant_option rozwiązują problem, który dręczy feedy z wariantami od zawsze – agent widzi osiem wierszy i nie rozumie, że to jeden produkt w ośmiu rozmiarach. To problem strukturyzowania wariantów w nowym kontekście.
• popularity_rank to twoja informacja dla agenta, które z twoich produktów naprawdę się sprzedają. Nikt inny nie może dać mu tego sygnału.

Wypełnianie ich na dużą skalę

Szczera przeszkoda: nikt nie ma kolumny question_and_answer w swoim PIM.

Większość sprzedawców ma jednak surowiec – tematy zgłoszeń do obsługi klienta, FAQ na stronach produktów, treść recenzji, przyczyny zwrotów. Najcenniejsze pary pytań i odpowiedzi zwykle widać w pytaniach, na które twój zespół wsparcia odpowiada najczęściej, oraz w powodach zwrotów. Zwrot z adnotacją „nie pasował do mojego urządzenia” to pytanie o kompatybilność, na które powinieneś odpowiadać w feedzie.

Google zaleca dodawanie tych atrybutów przez uzupełniające źródło danych zamiast przebudowy feedu głównego – i to operacyjnie słuszne podejście, ponieważ zespół odpowiedzialny za dane produktowe i zespół odpowiedzialny za treści wsparcia rzadko są tym samym zespołem.

W skali katalogu staje się to problemem reguł: wyprowadzaj item_group_title z nazwy produktu nadrzędnego, buduj variant_option z atrybutów, które już przechowujesz jako kolor i rozmiar, obliczaj popularity_rank jako percentyl z własnych danych sprzedażowych i mapuj document_link z istniejącej biblioteki instrukcji według wzorca SKU. W Feedance są to reguły feedu stosowane przy każdym odświeżeniu, a zwłaszcza popularity_rank może być automatycznie przeliczany z danych sprzedażowych zamiast utrzymywany ręcznie.

Zacznij od 200 SKU generujących największy przychód i trzech par pytań i odpowiedzi dla każdego. To tydzień pracy, który obejmuje większość twoich wyświetleń widocznych dla agentów.

Warstwa 3: ACP OpenAI – naprawdę inny kształt

Jeśli założysz, że feed dla ChatGPT to twój feed Google z innymi nazwami kolumn, zbudujesz coś niewłaściwego. Schemat feedu produktowego ACP jest strukturalnie inny, a te różnice wiele mówią o tym, czego chcą systemy agentowe.

Produkty zawierają warianty. Feed Google jest płaski: każdy wariant to osobny wiersz, powiązany z innymi przez item_group_id. ACP to odwraca – obiekt produktu jest rekordem kanonicznym i zawiera tablicę obiektów wariantów. Każdy wariant ma własny identyfikator, tytuł, cenę, dostępność, media i opcje.

To lepszy model dla agenta i warto zrozumieć dlaczego. Płaski feed zmusza agenta do odtworzenia faktu „to jeden but w dziewięciu rozmiarach” na podstawie wspólnego klucza grupującego. Feed zagnieżdżony podaje mu ten fakt wprost. Sprzedawcy z katalogami bogatymi w warianty – przede wszystkim z branży modowej – zyskują tu realną poprawę dokładności.

Ceny to liczby całkowite w jednostkach podrzędnych waluty. { "amount": 7999, "currency": "USD" } to 79,99 USD. Nie ciąg znaków z liczbą dziesiętną. Każdy pipeline wykonujący na cenach arytmetykę zmiennoprzecinkową trzeba sprawdzić, zanim po cichu wygeneruje coś błędnego.

Opisy to obiekty, a nie ciągi znaków. Obiekt description przyjmuje plain, html i markdown – możesz podać dowolną ich kombinację.

Linki do polityk sprzedawcy są elementem pierwszej kategorii. Obiekt seller zawiera links z typami privacy_policy, terms_of_service, refund_policy, shipping_policy lub faq. Przeczytaj tę listę jeszcze raz: agent chce twojej polityki zwrotów jako ustrukturyzowanego pola. W świecie, w którym kupujący nigdy nie widzi twojej strony, twoje zasady muszą podróżować razem z produktem.

Stan produktu to tablica. ["new"], przy czym może obowiązywać więcej niż jedna wartość – co uwzględnia rynek odsprzedaży i produktów odnowionych.

Minimalny kształt:

{
  "id": "SKU12345",
  "title": "Trail Running Shoe",
  "description": { "plain": "Waterproof trail shoe with cushioned sole." },
  "url": "https://example.com/products/SKU12345",
  "media": [
    { "type": "image", "url": "https://example.com/images/SKU12345.jpg",
      "alt_text": "Black trail running shoe", "width": 1200, "height": 1200 }
  ],
  "variants": [
    {
      "id": "SKU12345-BLK-10",
      "title": "Black / 10",
      "barcodes": [{ "type": "gtin", "value": "1234567890123" }],
      "price": { "amount": 7999, "currency": "USD" },
      "list_price": { "amount": 9999, "currency": "USD" },
      "availability": { "available": true, "status": "in_stock" },
      "variant_options": [
        { "name": "color", "value": "Black" },
        { "name": "size", "value": "10" }
      ],
      "categories": [
        { "value": "Apparel & Accessories > Shoes", "taxonomy": "merchant" }
      ],
      "condition": ["new"],
      "seller": {
        "name": "Example Store",
        "links": [
          { "type": "refund_policy", "title": "Returns policy",
            "url": "https://example.com/returns" }
        ]
      }
    }
  ]
}

Plikowi feedu towarzyszy nagłówek zawierający feed_id, account_id, target_merchant i target_country – zwróć uwagę, że kraj jest ustawiany na poziomie feedu, co oznacza, że sprzedawcy działający na wielu rynkach wysyłają jeden feed na rynek.

Zalecany przez OpenAI schemat dostarczania to pełny feed raz dziennie przez przesłanie pliku, z aktualizacjami w ciągu dnia wysyłanymi przez API. Małe katalogi mogą robić obie rzeczy przez API.

Jedna kwestia, którą warto ocenić trzeźwo: finalizacja zakupu w czacie OpenAI miała bardziej skomplikowany pierwszy rok, niż sugerowały zapowiedzi, a firma publicznie przyznała, że pierwsza implementacja Instant Checkout była mniej elastyczna, niż zamierzano, przesuwając nacisk na odkrywanie produktów z przekierowaniem do strony sprzedawcy w celu płatności. Jeśli ustalasz priorytety, traktuj odkrywanie w ACP jako szansę na najbliższy czas, a finalizację zakupu w ACP jako zakład długoterminowy.

Warstwa 4: Perplexity

Program dla sprzedawców Perplexity jest najsłabiej udokumentowany z tej trójki i właśnie dlatego najczęściej błędnie opisywany. Poradniki, które publikują szczegółową specyfikację pól Perplexity, ekstrapolują z Google – żadna oficjalna specyfikacja pól nie została opublikowana.

Co wiadomo:

• Program jest bezpłatny i oparty na zgłoszeniach; przyjmowanie sprzedawców było rozszerzane w latach 2025 i 2026.
• Feed jest dostarczany jako CSV lub XML, przez API, SFTP lub dedykowany bucket S3, w formacie Google Shopping.
• Kompletność danych produktowych działa jako czynnik rankingowy – pełniejsze dane dają systemowi więcej materiału do generowania porównań i podsumowań zalet i wad.
• Kompletność identyfikatorów, dane z recenzji i znaczniki Schema.org na stronach wydają się ważyć więcej niż w Google.
• Feed nie jest bezwzględnie wymagany, by zostać zacytowanym – katalog dostępny dla crawlerów z czystym schematem Product może się pojawić – ale feed zwiększa szanse na znalezienie się wśród polecanych produktów.
• Funkcje transakcyjne są ograniczone do USA. Poza USA możesz być cytowany i linkowany, ale nie sprzedawać przez platformę.

Praktyczny wniosek: w przypadku Perplexity praca polega na higienie Schema.org na stronach produktów oraz danych z recenzji, a nie na nowej integracji feedu. Jeśli twoje strony produktów już emitują prawidłowe znaczniki Product i Offer z GTIN, ceną, dostępnością i aggregateRating, większość pracy masz za sobą.

Warstwa 5: finalizacja zakupu – i uczciwa geografia

Tu publikacje zwykle się zapędzają, więc bądźmy precyzyjni co do tego, co faktycznie działa.

Finalizacja zakupu w UCP. Dostępna dla wybranych sprzedawców, z kwalifikacją produktów w Stanach Zjednoczonych, Kanadzie i Australii w chwili pisania. Pojawia się jako przycisk Kup przy kwalifikujących się ofertach w AI Mode i Gemini. Pozostajesz sprzedawcą (seller of record). Klienci płacą przez Google Pay danymi zapisanymi już w Portfelu Google. Udział wymaga spełnienia wymagań technicznych, przesłania formularza zgłoszenia zainteresowania i ukończenia wdrożenia – a co kluczowe, przycisk Kup pojawi się tylko przy ofertach z atrybutem produktu native_commerce(checkout_eligibility).

Ten ostatni szczegół to wniosek na poziomie feedu. Wszystko inne w finalizacji zakupu UCP to praca integracyjna po stronie backendu; sam sygnał kwalifikacji znajduje się w twoich danych produktowych.

W marcu 2026 r. Google ogłosił uproszczone dołączanie do UCP przez Merchant Center, razem z funkcjami koszyka, katalogu i łączenia tożsamości, i zasygnalizował globalną ekspansję w ciągu 2026 r.

Finalizacja zakupu w ACP. Wymaga wdrożenia trzech przepływów – feedu produktowego, API finalizacji zakupu i delegowanej płatności przez dostawcę usług płatniczych (PSP), takiego jak Stripe – i jest dostępna dla zatwierdzonych partnerów.

Perplexity Buy with Pro. Tylko w USA.

Jeśli sprzedajesz poza USA

Większość naszych klientów sprzedaje w Turcji, krajach Zatoki Perskiej i Europie. Oto uczciwa ocena tej sytuacji:

Agentowa finalizacja zakupu nie jest jeszcze dla ciebie dostępna. Agentowe odkrywanie jest – w pełni, już dziś.

Kupujący w Stambule, który prosi Gemini lub ChatGPT o porównanie produktów, już teraz otrzymuje odpowiedź zbudowaną z ustrukturyzowanych danych produktowych. To, czy ta odpowiedź obejmuje twoje produkty, zależy wyłącznie od opisanych wyżej warstw 1 i 2 – pokrycia identyfikatorów, kompletności atrybutów, atrybutów konwersacyjnych, aktualności i spójności. Nic z tego nie wymaga integracji protokołu, podmiotu w USA ani zgłoszenia do programu wczesnego dostępu.

Kolejność działań dla sprzedawcy spoza USA jest więc jasna:

1. Zrealizuj w pełni warstwę 1. To czysty zysk, który dodatkowo poprawia twoje obecne wyniki w Shopping i Performance Max.
2. Zrealizuj warstwę 2 już teraz. Atrybuty konwersacyjne są dostępne w standardowej specyfikacji Merchant Center, nie niosą ryzyka dla zatwierdzenia, a prawie nikt na twoim rynku ich nie wypełnił.
3. Obserwuj warstwę 5. Gdy finalizacja zakupu dotrze na twój rynek, sprzedawcy, którzy zrealizowali warstwy 1 i 2, zintegrują się w ciągu kilku tygodni. Ci, którzy tego nie zrobili, zaczną od niekompletnego katalogu.

Przewaga wczesnego działania nie polega na tym, że w tym kwartale będziesz sprzedawać w ChatGPT. Polega na tym, że naprawa jakości danych katalogowych zajmuje miesiące i nie da się jej kupić w pośpiechu, gdy otworzy się okno.

⚠️ Jeden termin, który nie jest opcjonalny

Niezależnie od wszystkiego powyżej, i znacznie pilniej: Content API for Shopping Google zostaje wycofane 18 sierpnia 2026 r. Po tej dacie wywołania starszych endpointów v2.1 przestaną działać.

Dotyczy to wyłącznie integracji programowych – ręczne przesyłanie, zaplanowane pobieranie i feedy z Arkuszy Google nie są objęte zmianą. Sprzedawcami korzystającymi z oficjalnych integracji platform (kanał Google & YouTube w Shopify, Google Listings & Ads w WooCommerce) zajmuje się platforma. Integracje niestandardowe i część narzędzi zewnętrznych wymagają ręcznej migracji do Merchant API v1.

Dwie rzeczy do sprawdzenia już dziś: w Merchant Center przejdź do Settings → Data Sources i spójrz na kolumnę Source. Jeśli widnieje w niej „Content API”, masz zadanie do wykonania. Pamiętaj też, że etykiety feedu nie są przenoszone automatycznie – jeśli struktura twoich kampanii Google Ads zależy od etykiet feedu, nieostrożnie przeprowadzona migracja może wstrzymać wyświetlanie kampanii.

Jeśli twój feed trafia do Merchant Center przez Feedance, tę migrację obsługujemy po naszej stronie, a konfiguracja twojego eksportu się nie zmienia.

Co oznacza „gotowość na agentów” pole po polu

Zbierając warstwy w jeden operacyjny widok:

Przydatne ćwiczenie to czytanie tej tabeli w poprzek: zwróć uwagę, jak wiele zachowań z prawej strony zależy od pól opcjonalnych, które większość katalogów zostawia pustymi.

Lista kontrolna gotowości

Podstawy – zrób je najpierw, dotyczą każdej powierzchni

• [ ] Pokrycie GTIN powyżej 90% aktywnych SKU
• [ ] Ceny i dostępność propagowane w ciągu od 15 minut do godziny, a nie przez noc
• [ ] Ceny, dostępność, wysyłka i zwroty spójne między stroną, feedem i marketplace’ami
• [ ] Wszystkie zdjęcia o wymiarach co najmniej 500×500 (wymagane też przez Google od 31 stycznia 2027 r.)
• [ ] Prawidłowe znaczniki Schema.org Product i Offer na każdej stronie produktu, z aggregateRating tam, gdzie masz recenzje
• [ ] Crawlery AI nie są przypadkiem zablokowane w robots.txt
• [ ] google_product_category zmapowane poprawnie, a nie pozostawione do automatycznego wnioskowania
• [ ] Potwierdzone zakończenie migracji z Content API

Przewaga konkurencyjna – większość twojego rynku tego nie zrobiła

• [ ] question_and_answer wypełnione dla 200 SKU o najwyższym przychodzie, po 3+ pary
• [ ] item_group_title i variant_option w każdej rodzinie wariantów
• [ ] popularity_rank obliczany z własnych danych sprzedażowych
• [ ] document_link zmapowany z istniejącej biblioteki instrukcji i kart katalogowych
• [ ] related_product dla akcesoriów i wymaganych części
• [ ] video_link przy produktach flagowych
• [ ] Kompletność atrybutów powyżej 95% w górnym decylu przychodowym

Pionierskie – dla sprzedawców na kwalifikujących się rynkach

• [ ] Feed ACP wygenerowany i dostarczany: codziennie pełny plus aktualizacje API w ciągu dnia
• [ ] Złożone zgłoszenie do programu dla sprzedawców Perplexity
• [ ] Przesłany formularz zainteresowania UCP, kwalifikacja native_commerce zasygnalizowana przy kwalifikujących się ofertach
• [ ] Ruch i zamówienia pochodzące od agentów oznaczane osobno w analityce

Ostatni punkt warto podkreślić. Zamówienia generowane przez agentów nie będą przypisywane tak jak wyszukiwanie czy płatne media społecznościowe, a jeśli nie oznaczysz ich na etapie integracji, nie będziesz w stanie udowodnić, że cokolwiek z tego zadziałało. Skonfiguruj pomiar, zanim będzie ci potrzebny.

Czy warto się tym zajmować?

Wyważona odpowiedź, bo ten temat przyciąga więcej pewności, niż uzasadniają dowody.

Powody do sceptycyzmu. Adopcja finalizacji zakupu jest wolniejsza, niż sugerowały zapowiedzi. OpenAI publicznie zmieniło podejście po pierwszej próbie z Instant Checkout. Większość funkcji transakcyjnych jest ograniczona geograficznie. Opublikowane dane o przyroście przychodów są skąpe, a imponująco brzmiące mnożniki wzrostu zwykle startują z bardzo niskiej bazy.

Powody, by mimo to działać. Prawie wszystko z warstw 1 i 2 poprawia twoje obecne wyniki płatne niezależnie od tego, czy handel agentowy spełni prognozy. Kompletne atrybuty, dokładne identyfikatory i aktualne dane o stanach magazynowych sprawiają, że Performance Max działa lepiej już dziś. Atrybuty konwersacyjne nie niosą ryzyka dla zatwierdzenia. A jakość danych katalogowych to projekt na wiele miesięcy bez dróg na skróty – sprzedawcy, którzy zaczną, gdy szansa stanie się oczywista, zaczną z opóźnieniem.

Proponujemy takie ujęcie: nie buduj pod handel agentowy, zbuduj katalog, który jest kompletny i poprawny. Gotowość na agentów to po prostu to, jak w 2026 r. wygląda kompletny i poprawny katalog. Praca nad protokołami to cienka warstwa na wierzchu i to ta część, którą można szybko wykonać, gdy dane pod spodem są w porządku.

Jeśli chcesz poznać punkt wyjścia, zanim się na cokolwiek zdecydujesz, nasze bezpłatne narzędzie do audytu feedu produktowego ocenia każdy feed pod kątem kompletności danych, jakości danych i kondycji technicznej – co jest rozsądnym przybliżeniem tego, ile z powyższego już masz.

Źródła

• Google Merchant Center Help — About the Universal Commerce Protocol (UCP): https://support.google.com/merchants/answer/16837055
• Google Merchant Center Help — How to use conversational attributes: https://support.google.com/merchants/answer/17085370
• Google Merchant Center Help — Product data specification: https://support.google.com/merchants/answer/7052112
• Google Developers Blog — Under the Hood: Universal Commerce Protocol: https://developers.googleblog.com/under-the-hood-universal-commerce-protocol-ucp/
• Google for Developers — Migrate from Content API for Shopping to Merchant API: https://developers.google.com/merchant/api/guides/compatibility/overview
• OpenAI Developers — Product Feed Spec (Agentic Commerce): https://developers.openai.com/commerce/specs/spec
• OpenAI Developers — Agentic Commerce key concepts: https://developers.openai.com/commerce/guides/key-concepts
• Agentic Commerce Protocol: https://www.agenticcommerce.dev/
• Universal Commerce Protocol: https://ucp.dev