Agentic commerce na marketplace: kto właściwie sprzedaje, gdy kupuje agent

Jeżeli prowadzisz marketplace, przygotowanie na agentic commerce to nie to samo zadanie, co w sklepie. Sklep odpowiada za swoją ofertę i swoje dane. Marketplace odpowiada za cudze dane, na których zarabia, i musi jeszcze powiedzieć modelowi, że oferta nie jest jego.

O tym, co zrobić w pojedynczym sklepie, pisaliśmy w tekście o przygotowaniu sklepu na agentic commerce. Ten artykuł jest jego odpowiednikiem dla platform wielosprzedawcowych i zaczyna się od pola, które istnieje wyłącznie dla nich, bo w sklepie jednomarkowym nie ma czego rozdzielać: sprzedawca, właściciel katalogu i strona przyjmująca płatność to ten sam podmiot, więc pytanie „kto właściwie sprzedaje" w ogóle nie powstaje.

Specyfikacja już rozróżnia sprzedawcę i miejsce zakupu

W specyfikacji feedu produktowego OpenAI dziewięć pól jest wymaganych przy każdej ofercie. Jedno z nich, seller_name, opisuje sprzedawcę dostarczającego tę konkretną ofertę, a specyfikacja żąda w nim prawdziwej nazwy marki i sprzedawcy, nie zaślepki.

Przy ofercie od sprzedawcy zewnętrznego dochodzi drugie pole. marketplace_seller wskazuje marketplace, na którym odbywa się zakup, i musi pozostać różne od seller_name. Trzecie pole, seller_url, ma przy ofercie marketplace’owej prowadzić do strony konkretnego sprzedawcy, a nie do strony głównej platformy.

Specyfikacja feedu produktowego OpenAI, sprawdzona u źródła 30 września 2026.

Jedno pole, a cała różnica konstrukcyjna.

Pola gtin i mpn są opcjonalne, ale w marketplace pełnią funkcję, której nie mają w sklepie jednomarkowym. Gdy dziesięciu sprzedawców wystawia tę samą rzecz, identyfikator producenta jest jedynym sygnałem, że to jedna oferta w dziesięciu wariantach ceny, a nie dziesięć różnych produktów.

Najsłabszy sprzedawca ustawia poziom całej kategorii

W sklepie jednomarkowym jakość danych jest funkcją jednego zespołu. W marketplace jest funkcją najgorszego dostawcy, który wpadł do tej samej kategorii co Twoi najlepsi.

Agent czyta ofertę, a nie kategorię. Porównuje kilka konkretnych pozycji i odrzuca te, o których nie umie powiedzieć czegoś pewnego. Oferta z pustą dostępnością, z nazwą sprzedawcy w stylu „Sklep 4521" i bez identyfikatora producenta nie jest gorszą ofertą. Jest ofertą nieczytelną, więc wypada z porównania.

• Pusta albo nieaktualna dostępność. Specyfikacja dopuszcza pięć stanów, w tym „unknown". Ten stan działa jak deklaracja „nie wiem, czy to mam", a agent, który ma wybrać jedną rzecz, nie wybiera tej.
• Zaślepka zamiast nazwy sprzedawcy. Specyfikacja żąda prawdziwej nazwy wprost. Identyfikator wewnętrzny platformy w tym polu to złamanie wymogu, a nie drobiazg kosmetyczny.
• Brak identyfikatora producenta przy duplikatach. Dziesięć ofert tego samego bez gtin wygląda jak dziesięć różnych produktów o podejrzanie zbliżonych opisach.
• Polityka zwrotów wpisana tylko w regulamin. Pola accepts_returns i return_deadline_in_days są opcjonalne, ale to one przenoszą informację, która u kupującego rozstrzyga ryzyko zakupu bez oglądania.

Wniosek operacyjny jest niewygodny: standard danych przestaje być zaleceniem dla sprzedawcy, a staje się warunkiem obecności w katalogu. Marketplace, który tego nie egzekwuje, subsydiuje najsłabszych kosztem widoczności najlepszych.

Kwalifikację można stracić po cichu

Widoczność i możliwość zakupu to w specyfikacji dwa osobne przełączniki, a zależność między nimi jest jednokierunkowa.

Specyfikacja feedu produktowego OpenAI, sprawdzona 30 września 2026.

W marketplace te dwie flagi są ustawiane maszynowo, często przez logikę importu, której nikt nie przegląda po wdrożeniu. Wyłączenie widoczności na całej grupie ofert nie wywoła żadnego alertu w Twoim panelu, bo z perspektywy platformy nic się nie zepsuło: zamówienia dalej wpadają, sprzedawcy dalej wystawiają, raporty sprzedaży wyglądają normalnie. Zniknie tylko kanał, którego nie mierzysz, a im dłużej go nie mierzysz, tym trudniej zauważyć, że kiedykolwiek istniał.

Take rate pod agentem broni się inaczej

Klasyczne uzasadnienie prowizji w marketplace brzmi: dajemy sprzedawcy dostęp do uwagi kupujących. Kupujący przychodzi, przegląda, porównuje i kupuje, a platforma bierze procent za to, że go tu przyprowadziła.

Agent psuje tę opowieść w jednym miejscu. Nie przegląda. Pyta, dostaje kilka ofert i wybiera. Nie buduje przywiązania do interfejsu, nie wraca z sentymentu i nie płaci za wygodę przeglądania, bo z niej nie korzystał.

To nie znaczy, że prowizja przestaje mieć sens. Znaczy, że musi być powiązana z czymś, co nadal działa, gdy kupujący nie ogląda strony: rozliczeniem, obsługą zwrotu, gwarancją wykonania zamówienia, weryfikacją sprzedawcy. Jak układać tę stawkę, rozkładamy w tekście o wysokości take rate.

Prowizja za ruch przestaje się bronić, bo ruchu nie było.

Drugi efekt jest subtelniejszy. Jeżeli agent porównuje oferty po cenie i dostępności, a Twoja platforma dolicza prowizję widoczną w cenie końcowej, to przegrywasz z kanałem, w którym ten sam sprzedawca sprzedaje bezpośrednio. To stary problem dysproporcji cenowej, tylko rozstrzygany teraz w ułamku sekundy i bez litości dla marki.

Co zrobić w tym kwartale

Kolejność ma znaczenie, bo pierwsze dwa punkty są warunkiem sensowności pozostałych.

• Rozdziel sprzedawcę od platformy w danych. Sprawdź, czy seller_name niesie prawdziwą nazwę sprzedawcy, a marketplace_seller Twoją. Jeśli w obu polach stoi to samo, model nie wie, u kogo kupuje.
• Zrób próg wejścia z jakości danych. Dostępność, prawdziwa nazwa, identyfikator producenta i polityka zwrotów jako warunek publikacji oferty, nie jako prośba w mailu powitalnym.
• Otocz kwalifikację pomiarem. Raport dzienny „ile ofert straciło widoczność" i alert przy skokowej zmianie. To pięć linijek zapytania, a wyłapuje awarie, których nie widać z panelu.
• Sprawdź, czy modele w ogóle pobierają Twój katalog. Bez tego reszta jest teorią. Jak to zmierzyć na własnych logach, opisaliśmy w tekście o mierzeniu ruchu crawlerów AI.
• Policz prowizję jeszcze raz, przy założeniu braku przeglądania. Jeśli uzasadnieniem stawki jest ruch, a nie rozliczenie i gwarancja, stawka wymaga nowej historii.

Warstwę techniczną, czyli dane strukturalne i to, co model faktycznie widzi na stronie oferty, zebraliśmy osobno w tekstach o danych strukturalnych pod AI i o tym, co widzi agent AI w Twoim sklepie.

Gdzie w tym jesteśmy my

Budujemy platformy marketplace w ramach frameworka BEAM: Blueprint rozstrzyga model biznesowy i standard danych, zanim powstanie kod. Przy marketplace prawie zawsze zaczynamy od tego samego pytania, od którego zaczyna się ten artykuł: kto jest sprzedawcą i czy Twoje dane potrafią to powiedzieć. Zakres tej pracy opisujemy przy platformach marketplace.

Uczciwe zastrzeżenie, bo temat sprzyja obietnicom: nikt nie wie, jaki udział zakupów przejdzie przez agentów ani kiedy. Nie znamy tej liczby i nie będziemy jej zgadywać. Wszystko powyżej opiera się na tym, czego specyfikacja wymaga dzisiaj, a nie na prognozie.

Jeżeli Twoje przychody idą dziś głównie z Amazona albo Allegro, a nie z własnej platformy, to rozmowa dotyczy innego problemu i innej firmy. Tym zajmuje się nasza marka siostrzana, Amazonway. Jeśli budujesz katalog od zera, przydatniejszy będzie tekst o zimnym starcie marketplace’u.