Universal Commerce Protocol i zakupy agentów AI: jak przygotować dane produktu, aby maszyna wybrała ofertę?

Agent zakupowy nie ogląda karty produktu tak jak człowiek. Nie zachwyca się zdjęciem lifestyle’owym, nie domyśla się, że „wersja premium” oznacza większą baterię, i nie zadzwoni do sklepu, aby upewnić się, czy dostawa nastąpi przed piątkiem. Porównuje dane, sprawdza warunki transakcji i odrzuca ofertę, jeśli nie potrafi jednoznacznie ustalić, co dokładnie kupuje, za ile, od kogo i na jakich zasadach.

To zasadnicza zmiana dla e-commerce. Dotychczas niepełny parametr można było ukryć w opisie, a nieaktualny stan magazynowy poprawić dopiero po złożeniu zamówienia. W handlu obsługiwanym przez agentów AI takie niedociągnięcia przestają być problemem kosmetycznym. Stają się powodem, dla którego maszyna wybiera konkurenta.

Universal Commerce Protocol, czyli UCP, ma ujednolicić komunikację między platformą wykorzystującą AI, systemem sprzedawcy, dostawcą płatności i innymi uczestnikami transakcji. Nie jest jednak magicznym przyciskiem, który naprawi słaby katalog. Protokół pozwala systemom się porozumieć, ale nadal operuje na danych dostarczonych przez sklep. Jeśli cena, wariant, dostępność albo koszt dostawy są niejednoznaczne, UCP jedynie szybciej ujawni bałagan.

UCP nie zastępuje feedu produktowego — porządkuje drogę od wyboru do zakupu

Universal Commerce Protocol został publicznie ogłoszony 11 stycznia 2026 roku jako otwarty standard rozwijany przez Google wspólnie między innymi z Shopify, Etsy, Walmartem, Targetem i Wayfair. Jego założenie jest proste: zamiast budować osobne połączenie sklepu z każdym agentem AI, sprzedawca może udostępnić wspólny zestaw usług i funkcji, które agent potrafi automatycznie wykryć.

UCP obejmuje szerszy proces niż samo znalezienie produktu. Architektura protokołu ma obsługiwać kolejne etapy handlu:

• rozpoznanie sprzedawcy i dostępnych usług,
• ustalenie obsługiwanych funkcji,
• utworzenie i aktualizację koszyka,
• obliczenie ceny, podatków i kosztów realizacji,
• wybór sposobu dostawy,
• bezpieczną autoryzację płatności,
• złożenie zamówienia,
• obsługę statusów, zwrotów i innych procesów posprzedażowych.

Sprzedawca publikuje profil UCP pod standardową ścieżką /.well-known/ucp. Profil informuje platformę, którą wersję protokołu obsługuje firma, jakie usługi oferuje i z jakich funkcji można skorzystać. Zamiast zakładać, że każdy sklep działa identycznie, agent porównuje możliwości obu stron. Następnie serwer sprzedawcy wybiera wspólny zakres obsługiwanych funkcji.

To ważne w praktyce. Sklep może obsługiwać standardowy checkout, ale nie oferować płatności odroczonych. Może pozwalać na odbiór w punkcie, lecz nie na dostawę w określonym przedziale godzinowym. UCP nie zmusza firmy do udostępniania wszystkiego. Wymaga natomiast, aby deklaracje były jednoznaczne, aktualne i możliwe do zweryfikowania.

Specyfikacja ustala również podstawowe reguły techniczne. Daty i godziny zapisuje się zgodnie z RFC 3339, a kwoty pieniężne podaje w najmniejszych jednostkach waluty. Dla złotego cena 129,99 zł jest więc przekazywana jako 12 999 groszy, a nie jako liczba zmiennoprzecinkowa 129,99. Takie podejście ogranicza błędy zaokrągleń, które przy większej liczbie operacji mogą prowadzić do różnic między koszykiem, płatnością i fakturą.

UCP przewiduje kilka metod uwierzytelniania, między innymi klucze API, OAuth 2.0, wzajemne TLS oraz podpisy wiadomości HTTP. Komunikaty wysyłane przez sklep do platformy w formie webhooków muszą być podpisane. Dla autonomicznych transakcji dostępne są również rozszerzenia pozwalające przedstawić kryptograficzny dowód zgody użytkownika.

Dla właściciela polskiego sklepu najważniejsze ograniczenie jest dziś inne: publikacja standardu nie oznacza automatycznego dostępu do wszystkich kanałów sprzedaży agentowej. Google rozwija zakupy bezpośrednie w AI Mode i Gemini, ale integracja pozostaje uzależniona od kwalifikacji sprzedawcy, rynku oraz wdrożonego modelu checkoutu. W sierpniu 2026 roku nie należy budować prognoz sprzedażowych dla Polski tak, jakby agentowy checkout był już powszechnie dostępny dla każdego sklepu.

Nie oznacza to, że można odłożyć porządkowanie danych. Ten sam katalog zasila dziś Google Merchant Center, porównywarki, marketplace’y, kampanie produktowe i wewnętrzne systemy rekomendacji. Prace wykonane pod handel agentowy rozwiązują więc również obecne problemy z odrzucanymi produktami, błędnymi wariantami i reklamacjami.

Maszyna wybiera wariant, a nie marketingową obietnicę

Najczęstszy błąd sklepów polega na traktowaniu opisu jako miejsca, w którym można nadrobić braki w strukturze danych. Człowiek przeczyta, że laptop ma „wydajny procesor, dużo pamięci i pojemny dysk”. Agent potrzebuje konkretnych wartości: modelu procesora, wielkości RAM, rodzaju pamięci, pojemności dysku, układu klawiatury, systemu operacyjnego oraz numeru identyfikującego dokładną konfigurację.

Dane produktu powinny odpowiadać na sześć pytań:

1. Co to dokładnie jest?
2. Który wariant jest przedmiotem oferty?
3. Ile wynosi pełna cena transakcji?
4. Czy produkt rzeczywiście jest dostępny?
5. Kiedy i jak można go otrzymać?
6. Jakie ograniczenia lub obowiązki wiążą się z zakupem?

Podstawą jest stabilny identyfikator. Dla produktów markowych najczęściej będzie to GTIN, uzupełniony o markę i numer katalogowy producenta, czyli MPN. W branżach bez GTIN — na przykład przy rękodziele, produktach wykonywanych na zamówienie lub niektórych częściach przemysłowych — sklep musi utrzymywać własny, niezmienny identyfikator oraz wyraźnie opisać producenta i model.

Nie wolno przypisywać jednego GTIN kilku wariantom. Czerwona kurtka w rozmiarze M i czarna kurtka w rozmiarze L to dwa różne produkty handlowe, nawet gdy korzystają z tej samej strony nadrzędnej. Agent powinien móc wybrać właściwą kombinację bez analizowania zdań w opisie.

Minimalny użyteczny rekord wariantu powinien zawierać:

• indywidualny identyfikator SKU,
• GTIN albo uzasadnioną informację o jego braku,
• markę i model,
• cechy odróżniające wariant,
• cenę brutto w odpowiedniej walucie,
• status dostępności,
• liczbę dostępnych sztuk, jeśli sklep może ją bezpiecznie ujawniać,
• masę i wymiary potrzebne do obliczenia dostawy,
• termin przygotowania zamówienia,
• zasady zwrotu,
• wymagane ostrzeżenia oraz informacje o bezpieczeństwie.

Tytuł produktu powinien identyfikować ofertę, a nie imitować reklamę. Dobra nazwa to na przykład „Bosch Serie 6 WGG244Z0PL, pralka 9 kg, 1400 obr./min, biała”. Słaba nazwa brzmi: „Superoszczędna pralka klasy premium — hit sezonu”. Pierwsza wersja pozwala porównać model. Druga dostarcza wyłącznie deklaracji marketingowej.

Podobna zasada dotyczy parametrów. Wartość „duży” jest bezużyteczna bez skali. „Pojemność 9 kg”, „szerokość 59,8 cm” albo „czas pracy do 18 godzin według procedury producenta” daje agentowi podstawę do sprawdzenia ograniczeń użytkownika.

Trzeba też odróżniać parametry deklarowane przez producenta od warunków rzeczywistych. Jeżeli czas pracy urządzenia zależy od jasności ekranu, połączenia LTE albo temperatury, informacja o metodzie pomiaru ogranicza ryzyko błędnego porównania. Nie gwarantuje wyboru oferty, ale zmniejsza prawdopodobieństwo, że agent uzna parametr za niewiarygodny lub nieporównywalny.

Szczególnie trudne są produkty wymagające sprawdzenia kompatybilności. Sprzedawca części samochodowych nie powinien poprzestać na haśle „pasuje do Volkswagen Golf”. Potrzebny jest co najmniej model, generacja, rocznik, wersja silnikowa oraz — tam, gdzie ma to znaczenie — kod silnika, numer części OE albo zakres numerów VIN.

W elektronice agent musi rozróżnić złącze fizyczne od obsługiwanego standardu. Kabel z końcówką USB-C nie musi obsługiwać obrazu, szybkiego ładowania ani transferu 40 Gb/s. Brak tej informacji prowadzi do złej rekomendacji, nawet jeśli zdjęcie i opis wyglądają bez zarzutu.

Niedogodność? Utrzymywanie takiej szczegółowości jest drogie. Katalog liczący 20 tys. wariantów może wymagać tygodni pracy, zwłaszcza gdy dane pochodzą od wielu dostawców. Automatyczne generowanie parametrów na podstawie opisów przyspiesza proces, lecz tworzy kolejny problem: model językowy potrafi uzupełnić brakującą wartość czymś prawdopodobnym, ale nieprawdziwym. Dlatego dane krytyczne — kompatybilność, materiał, pojemność, skład, ostrzeżenia, napięcie czy certyfikacja — muszą mieć wskazane źródło i właściciela odpowiedzialnego za ich zatwierdzenie.

Cena, dostępność i dostawa muszą opisywać tę samą transakcję

Agent nie powinien wybierać oferty na podstawie ceny, której nie da się uzyskać przy składaniu zamówienia. To obecnie jeden z najbardziej kosztownych błędów w feedach produktowych: katalog podaje 299 zł, karta produktu pokazuje 329 zł, a koszyk dolicza obowiązkowe 19,99 zł za dostawę.

Dla maszyny są to trzy sprzeczne odpowiedzi na jedno pytanie.

Cena podstawowa musi być ceną brutto właściwego wariantu. Jeżeli produkt kosztuje 299 zł wyłącznie po zalogowaniu, zapisaniu się do programu albo zakupie dwóch sztuk, warunek trzeba przekazać osobno. Nie należy publikować wartości warunkowej jako zwykłej ceny dostępnej dla każdego.

Przy promocji w Polsce i pozostałych państwach UE trzeba uwzględnić obowiązek podawania wcześniejszej ceny, rozumianej co do zasady jako najniższa cena stosowana w okresie co najmniej 30 dni przed obniżką. Agent powinien dostać nie tylko cenę promocyjną, ale również czas obowiązywania promocji, wymagania dotyczące kodu, minimalnej wartości koszyka i grupy uprawnionych klientów.

Przykład kompletnej promocji:

• cena regularna: 449 zł,
• cena promocyjna: 379 zł,
• najniższa cena z 30 dni przed obniżką: 399 zł,
• ważność: od 6 sierpnia 2026 roku, godz. 00:00, do 11 sierpnia 2026 roku, godz. 23:59 czasu polskiego,
• warunek: brak kodu, jedna sztuka wystarczy,
• ograniczenie: maksymalnie dwie sztuki na klienta.

Tak opisanej oferty nie trzeba interpretować. Można ją policzyć.

Dostępność nie może być ręcznie wpisanym statusem aktualizowanym raz dziennie, jeśli w magazynie zostały trzy sztuki produktu sprzedawanego równolegle na Allegro, Amazonie i we własnym sklepie. Przy szybko rotującym asortymencie synchronizacja co 24 godziny jest praktycznie zaproszeniem do anulowania zamówień.

Częstotliwość aktualizacji należy dobrać do ryzyka:

• produkty o dużym zapasie i małej rotacji: aktualizacja co kilka godzin może wystarczyć,
• popularna elektronika i moda w promocji: najlepiej aktualizować stan w ciągu kilku minut,
• ostatnie sztuki, bilety, rezerwacje i produkty kolekcjonerskie: potrzebna jest rezerwacja zapasu podczas checkoutu,
• towary wykonywane na zamówienie: zamiast fikcyjnego statusu „dostępny” trzeba podać czas produkcji.

Samo pole „in stock” jest zbyt ubogie. Agent powinien znać również przewidywaną datę wysyłki, możliwość odbioru osobistego, ograniczenia geograficzne i moment, w którym zapas zostaje zarezerwowany.

Równie dokładnie trzeba opisać dostawę. „Wysyłka w 24 godziny” może oznaczać nadanie paczki następnego dnia roboczego, a nie doręczenie jej klientowi. Jeśli użytkownik prosi: „Znajdź prezent, który dotrze do Krakowa przed sobotą”, agent potrzebuje przewidywanej daty dostawy dla konkretnego kodu pocztowego, metody przewozu i godziny złożenia zamówienia.

Dane logistyczne powinny uwzględniać:

• czas przygotowania przesyłki,
• dni pracy magazynu,
• godzinę graniczną przyjęcia zamówienia,
• czas przewozu dla danej metody,
• kod pocztowy albo strefę dostawy,
• święta i dni bez obsługi,
• gabaryt oraz masę,
• koszt dostawy,
• próg darmowej wysyłki,
• wykluczenia dla produktów niebezpiecznych, chłodzonych lub ponadgabarytowych.

W polskich realiach szczególnie łatwo popełnić błąd przy automatach paczkowych. Produkt może mieścić się w limicie wagowym przewoźnika, ale przekraczać wymiar skrytki. Jeżeli system sprawdza wyłącznie masę, agent zaoferuje metodę, która zniknie dopiero w koszyku.

Sklep musi również przygotować dane prawne i bezpieczeństwa produktu. W przypadku towarów objętych unijnym rozporządzeniem GPSR oferta internetowa powinna umożliwiać identyfikację produktu, producenta, a w odpowiednich przypadkach także osoby odpowiedzialnej w UE. Potrzebne są również ostrzeżenia lub informacje dotyczące bezpiecznego użytkowania. Ukrycie ich w instrukcji PDF dostępnej dopiero po zakupie nie wystarcza do rzetelnej kwalifikacji oferty.

Agent może pominąć produkt, gdy nie potrafi sprawdzić:

• kto jest producentem,
• kto odpowiada za produkt na rynku UE,
• czy wyrób ma wymagane oznaczenia,
• jakie ograniczenia wiekowe lub użytkowe obowiązują,
• czy produkt zawiera substancje lub elementy wymagające ostrzeżenia,
• jakie są warunki odstąpienia od umowy i reklamacji.

Dane nie mogą jednak rozjeżdżać się między kanałami. Jeżeli feed zawiera termin zwrotu 30 dni, regulamin sklepu mówi o 14 dniach, a karta produktu obiecuje 100 dni, agent nie ma podstawy, aby zdecydować, która wartość jest wiążąca. Powinno istnieć jedno nadrzędne źródło reguł handlowych, z którego korzystają sklep, marketplace’y, system obsługi klienta i integracja UCP.

W obszarze widoczności produktów i automatyzacji sprzedaży przydają się również praktyczne analizy publikowane przez branżowe serwisy. Więcej informacji na: https://marketing-buzz.pl.

FAQ: przygotowanie sklepu do zakupów wykonywanych przez agentów AI

Czy wdrożenie UCP sprawi, że agent zawsze wybierze mój produkt?
Nie. UCP ułatwia agentowi odczytanie możliwości sklepu i przeprowadzenie transakcji, ale nie gwarantuje rekomendacji. O wyborze mogą decydować między innymi cena całkowita, zgodność z wymaganiami użytkownika, termin dostawy, zasady zwrotu, wiarygodność sprzedawcy i jakość danych.

Czy wystarczy poprawny feed w Google Merchant Center?
Nie, chociaż jest to dobry punkt startowy. Feed odpowiada przede wszystkim za informacje produktowe i widoczność oferty. Pełny handel agentowy wymaga również danych pobieranych w czasie rzeczywistym: aktualnego zapasu, ostatecznej ceny koszyka, dostępnych metod realizacji, reguł promocji, płatności i obsługi zamówienia.

Czy mały sklep powinien już budować własną integrację UCP?
Zwykle nie jako pierwszy projekt. Najpierw trzeba uporządkować katalog, stany magazynowe, promocje i dostawę. Własna integracja ma sens, gdy sklep ma dojrzałe API, dużą skalę albo niestandardowy checkout. Mniejsze firmy prawdopodobnie skorzystają z obsługi dostarczonej przez platformę e-commerce, integratora lub system typu SaaS.

Jak często aktualizować ceny i dostępność?
Tak często, aby liczba anulowanych zamówień wynikających z rozbieżności była akceptowalna. Przy zwykłym asortymencie aktualizacja co kilka godzin może wystarczyć. Przy promocjach, ostatnich sztukach i szybkiej rotacji potrzebna jest synchronizacja liczona w minutach oraz rezerwacja zapasu podczas checkoutu.

Czy opisy generowane przez AI można automatycznie publikować w danych produktu?
Tak, ale nie w przypadku parametrów krytycznych bez walidacji. AI może porządkować tekst, klasyfikować cechy i sugerować brakujące pola. Nie powinno samodzielnie zatwierdzać składu, kompatybilności, certyfikatów, wymiarów, ostrzeżeń ani warunków gwarancji.

Co z produktami bez kodu GTIN?
Nie należy tworzyć fikcyjnego kodu. Trzeba użyć trwałego identyfikatora własnego, poprawnie oznaczyć brak GTIN i uzupełnić markę, producenta, model oraz pozostałe cechy. Fałszywy identyfikator może połączyć produkt z niewłaściwą kartą katalogową.

Czy najniższa cena z 30 dni powinna być przekazywana agentowi?
Tak, gdy oferta jest komunikowana jako obniżka ceny i podlega tym przepisom. Pole powinno być oddzielone od ceny regularnej i promocyjnej. Trzeba również przekazać okres promocji oraz wszystkie warunki uzyskania rabatu.

Jaki błąd usunąć jako pierwszy?
Najpierw sprawdź 100 najlepiej sprzedających się wariantów i porównaj dla każdego z nich cenę, dostępność oraz koszt dostawy w systemie magazynowym, feedzie, na karcie produktu i w koszyku. Jeżeli wartości się różnią, nie zaczynaj jeszcze integracji UCP. Pierwszą decyzją powinno być wyznaczenie jednego nadrzędnego źródła tych trzech danych i zablokowanie publikacji oferty, gdy którykolwiek kanał pokazuje inną wartość.