Produkt został polecony, ale Twój sklep nie. Jak ChatGPT wybiera sprzedawcę dla tego samego GTIN?

Widoczność produktu w ChatGPT i widoczność konkretnego sprzedawcy tego produktu to dwa oddzielne problemy. System może uznać model produktu za trafny dla zapytania użytkownika, a następnie wybrać inną ofertę niż Twoja (o fundamentach widoczności produktu w AI pisaliśmy osobno) – na podstawie ceny, dostępności, jakości danych w feedzie, relacji sprzedawcy z produktem i sygnałów merchant-level. Przesłanie poprawnego feedu z GTIN nie gwarantuje, że to właśnie Twój sklep zostanie wskazany jako sprzedawca. Architektura Agentic Commerce Protocol rozdziela identyfikację produktu od selekcji oferty, a pola takie jak seller_name, store_star_rating, popularity_score i return_rate działają na poziomie sprzedawcy, nie produktu.

Ten artykuł analizuje mechanizm rozdzielenia rankingu produktu od rankingu ofert tego samego produktu. Pokazuje, jakie dane feedowe wpływają na wybór sprzedawcy, jak zaprojektować kontrolowane badanie tego procesu i co sklep może zrobić, żeby zwiększyć szanse na pierwszą pozycję wśród sprzedawców danego GTIN.

Czy ChatGPT najpierw wybiera produkt, a dopiero potem ofertę?

Dokumentacja Agentic Commerce Protocol nie opisuje wprost dwuetapowego procesu selekcji. Nie istnieje publiczny dokument OpenAI, który mówi: „najpierw wybieramy produkt, potem sprzedawcę”. Ale architektura feedu silnie sugeruje taką separację.

Specyfikacja produktowa ACP definiuje pole gtin (8-14 cyfr, bez spacji i myślników) jako uniwersalny identyfikator produktu. Jednocześnie pole offer_id opisane jest jako „Offer ID (SKU+seller+price)” – kompozyt identyfikujący konkretną ofertę, nie sam produkt. To rozróżnienie nie jest przypadkowe: system potrzebuje jednego klucza do dopasowania modelu produktu do zapytania (GTIN) i drugiego do identyfikacji konkretnej oferty sprzedawcy (offer_id).

Najważniejsze pola feedowe (których relację z kartą produktu opisujemy w artykule o feedzie a danych strukturalnych) działające na poziomie produktu to title, description, brand, gtin, mpn i product_category. Najważniejsze pola działające na poziomie sprzedawcy i oferty to seller_name, seller_url, price, availability, shipping, store_star_rating, store_review_count, popularity_score, return_rate, accepts_returns i return_deadline_in_days.

Dokumentacja zawiera jeszcze jeden istotny szczegół. Dla feedów kompatybilnych z formatem Google: „Register a merchant display name that contains at least one non-whitespace character and is not a placeholder such as unknown, null, or n/a. OpenAI trims and uses that registered name as the seller identity on every row. An uploaded seller_name cannot override it” (OpenAI Commerce Products Spec, weryfikacja: 17.08.2026). To oznacza, że tożsamość sprzedawcy jest ustalana na poziomie rejestracji feedu, nie na poziomie wiersza produktu.

Pola merchant-level w specyfikacji ACP

Pole	Typ	Poziom	Wpływ na selekcję
seller_name	String (max 70)	Sprzedawca	Identyfikacja – nadpisywane przez zarejestrowaną nazwę
seller_url	URL	Sprzedawca	Cel przekierowania po wyborze oferty
store_star_rating	String (0-5)	Sprzedawca	Sygnał reputacji sklepu (merchant trust score)
store_review_count	Integer	Sprzedawca	Skala zaufania do oceny
popularity_score	Number (0-5)	Produkt/Sprzedawca	Wskaźnik popularności
return_rate	Number (0-100%)	Sprzedawca	Odsetek zwrotów
return_deadline_in_days	Integer	Oferta	Okno na zwrot
accepts_returns	Boolean	Oferta	Czy sklep przyjmuje zwroty
shipping	String	Oferta	Kraj, region, metoda, cena, czas obsługi i dostawy
marketplace_seller	String (max 70)	Oferta	Sprzedawca realizujący na marketplace

Osobno istnieją pola review_count i star_rating (bez prefiksu „store”), które opisują produkt, nie sprzedawcę. Jeśli trzy sklepy sprzedają ten sam odkurzacz robotyczny, każdy może mieć inny store_star_rating, ale star_rating produktu powinien być identyczny – bo dotyczy tego samego modelu.

Czego dokumentacja nie potwierdza o wyborze sprzedawcy

Dokumentacja ACP nie opisuje algorytmu rankingu ofert. Nie wiadomo, jaką wagę mają poszczególne pola merchant-level w procesie selekcji. Nie wiadomo, czy store_star_rating jest ważniejszy od price, ani czy popularity_score wpływa na pozycję oferty.

Nie istnieje publiczny opis procesu deduplikacji ofert tego samego GTIN. Jeśli pięciu sprzedawców przesyła feed z tym samym gtin i różnymi cenami, dokumentacja nie mówi, jak system decyduje, którego sprzedawcę pokazać jako pierwszego, ani ile ofert wyświetla.

Nie wiadomo również, jak często system aktualizuje dane o cenach i dostępności. Pole availability jest wymagane (a problem rekomendacji produktów niedostępnych dotyczy też ChatGPT) (in_stock, out_of_stock, pre_order, backorder), ale częstotliwość synchronizacji nie jest udokumentowana. Sklep może zmienić cenę o 15:00, a ChatGPT może pokazywać starą cenę jeszcze przez godziny – lub minuty. Tego nie wiemy.

• Brak publicznego algorytmu rankingu ofert tego samego produktu.
• Brak informacji o wadze pól merchant-level w selekcji.
• Brak dokumentacji częstotliwości synchronizacji cen i dostępności.
• Brak opisu procesu deduplikacji wielu ofert tego samego GTIN.
• Brak informacji, czy producent lub „primary seller” ma przewagę nad resellerem.
• Brak danych o wpływie marketplace_seller na pozycję oferty.

Jakie są problemy, dwa rankingi – dlaczego rozdzielenie ma znaczenie?

Kiedy użytkownik pyta ChatGPT „jaki odkurzacz robotyczny do mieszkania 60 m²?”, system musi rozwiązać dwa odrębne zadania. Pierwsze: wybrać modele produktów, które pasują do zapytania. Drugie: dla każdego wybranego modelu wybrać konkretną ofertę sprzedawcy.

Te dwa zadania wymagają różnych danych. Wybór produktu opiera się na jakości content marketingu produktowego – atrybutach produktowych: tytule, opisie, kategorii, specyfikacji technicznej (w tym atrybutach konwersacyjnych), opiniach i sentymencie klientów. Wybór sprzedawcy opiera się na atrybutach oferty: cenie, dostępności, kosztach dostawy, reputacji sklepu, polityce zwrotów.

Dla sklepu, który sprzedaje popularne marki (nie produkuje własnych produktów), ta separacja jest kluczowa. Sklep nie kontroluje, czy dany model odkurzacza jest „trafny” dla zapytania użytkownika – to wynika z atrybutów produktu, które są wspólne dla wszystkich sprzedawców tego GTIN. Sklep kontroluje natomiast swoją ofertę: cenę, dostępność, koszt dostawy, czas realizacji, politykę zwrotów i jakość danych w feedzie. Pozycjonowanie w AI wymaga osobnej strategii dla każdego z tych wymiarów.

Analogia: w Google Shopping ten sam mechanizm działa od lat. Product Listing Ads grupują oferty tego samego produktu i wyświetlają je w karuzeli z cenami różnych sprzedawców. Użytkownik widzi produkt, a potem wybiera sklep. ChatGPT robi coś podobnego, ale w formie tekstowej rekomendacji, gdzie wybór sprzedawcy może być mniej widoczny dla użytkownika.

Patent US9141674B2 opisuje mechanizm łączenia trafności dokumentu z niezależnymi od zapytania sygnałami jakości. W kontekście selekcji ofert: trafność produktu (odpowiedź na zapytanie) i jakość sprzedawcy (sygnał niezależny od zapytania) mogą być łączone w oddzielnych etapach rankingu. Patent nie dowodzi, że ChatGPT stosuje ten konkretny mechanizm, ale opisuje architekturę, w której separacja tych dwóch wymiarów jest technicznie uzasadniona.

Jak zaprojektować kontrolowane badanie wyboru sprzedawcy

Poniższy design testu został przygotowany zgodnie z metodologią Semgence dla badań AI commerce. Wyniki zostaną opublikowane po zebraniu pełnej próby. Miejsca oznaczone zostaną zaktualizowane po przeprowadzeniu pomiarów.

Próba

• 20 produktów z poprawnym GTIN, weryfikowalnym w bazie GS1.
• Minimum 3 niezależnych sprzedawców na produkt (feedujących do ACP).
• Minimum 60 ofert łącznie.
• 3 kategorie: odkurzacze robotyczne (wysoka wartość, porównywalne parametry), smartwatche (silne marki, wiele wariantów), perfumy (identyczny produkt, duża rozpiętość cenowa).
• 3 powtórzenia zapytania w różnych dniach, osobne sesje bez pamięci.

Dane zbierane dla każdej oferty

Grupa danych	Pola	Źródło
Identyfikacja produktu	GTIN, MPN, marka, model	Feed + strona produktu
Cena	Cena regularna, promocyjna, waluta	Feed + strona produktu
Dostępność	Status, data availability_date	Feed + strona produktu
Dostawa	Koszt, czas, metoda, cut-off	Feed + strona produktu
Polityka zwrotów	Akceptacja, deadline, URL	Feed + strona produktu
Reputacja sklepu	store_star_rating, store_review_count	Feed
Typ sprzedawcy	Producent, autoryzowany dystrybutor, reseller	Strona + dane publiczne
Spójność danych	Zgodność feed – strona – schema	Porównanie automatyczne
Pozycja w odpowiedzi	Kolejność sprzedawców, etykiety AI	Odpowiedź ChatGPT
Pomiar	Data, godzina, sesja, prompt	Log badawczy

Scenariusze promptów

1. Neutralny: „Szukam [model produktu]” – bez preferencji cenowej ani dostawczej.
2. Najniższa cena: „Gdzie najtaniej kupię [model produktu]?” – jawna preferencja cenowa.
3. Najszybsza dostawa: „Potrzebuję [model produktu] na jutro” – priorytet czasu.
4. Najbezpieczniejszy sprzedawca: „Jaki sklep jest najbardziej godny zaufania dla [model produktu]?” – priorytet reputacji.
5. Budżet + producent: „Chcę kupić [model produktu] do 500 zł, najlepiej od producenta” – dwa ograniczenia.

Metryki

Metryka	Definicja	Interpretacja
Product selection rate	Odsetek zapytań, w których dany GTIN pojawia się w odpowiedzi	Mierzy widoczność produktu
Merchant selection rate	Odsetek odpowiedzi z danym GTIN, w których dany sklep jest wskazany	Mierzy widoczność sprzedawcy
Cheapest-first share	Odsetek odpowiedzi, w których najtańszy sprzedawca jest na pierwszej pozycji	Testuje hipotezę „najniższa cena wygrywa”
Producer-first share	Odsetek odpowiedzi, w których producent lub primary seller jest pierwszy	Testuje hipotezę uprzywilejowania producenta
Price discrepancy	Różnica między ceną w odpowiedzi ChatGPT a ceną na stronie sklepu	Mierzy opóźnienie synchronizacji
Availability discrepancy	Odsetek odpowiedzi z rozbieżnością dostępności feed vs strona	Mierzy spójność danych
Merchant switching rate	Odsetek GTIN, dla których pierwszy sprzedawca zmienia się między pomiarami	Mierzy stabilność rankingu ofert

Wyniki pomiarów zostaną opublikowane po zakończeniu pilotażu. Na tym etapie prezentujemy metodologię i wstępne hipotezy oparte na analizie specyfikacji ACP. Sklepy, które chcą wcześniej zweryfikować gotowość swoich feedów, mogą skorzystać z konsultacji SEO obejmujących diagnostykę pól ofertowych.

Jakie są wstępne obserwacje z pilotażu?

Poniższe hipotezy opierają się na analizie specyfikacji feedu ACP i obserwacjach z testowych zapytań do ChatGPT. Pełne wyniki ilościowe opublikujemy po zakończeniu fazy pomiarowej.

Na tym etapie możemy sformułować hipotezy robocze na podstawie architektury feedu i doświadczeń z analogicznymi systemami:

1. Hipoteza 1: Najniższa cena nie jest jedynym czynnikiem decydującym o pierwszej pozycji sprzedawcy. Pola takie jak store_star_rating, shipping i return_rate prawdopodobnie wpływają na ranking ofert.
2. Hipoteza 2: Producent lub autoryzowany dystrybutor może mieć przewagę nad resellerem, nawet przy wyższej cenie – jeśli system rozpoznaje relację marki z produktem.
3. Hipoteza 3: Opóźnienie aktualizacji ceny w feedzie może powodować, że ChatGPT pokazuje nieaktualną ofertę, która była najtańsza w momencie ostatniej synchronizacji.
4. Hipoteza 4: Sklepy z kompletnym zestawem pól merchant-level (store_star_rating + shipping + return_policy + accepts_returns) mają wyższy merchant selection rate niż sklepy z samymi wymaganymi polami.

Kiedy najtańsza oferta nie wygrywa

Konkretne przykłady z pomiarów zostaną dodane po zakończeniu pilotażu. Poniższe scenariusze ilustrują mechanizm na podstawie architektury feedu.

Na podstawie architektury feedu i analogii z Google Shopping możemy wskazać scenariusze, w których najtańsza oferta prawdopodobnie nie będzie pierwsza:

Scenariusz 1: Brak dostępności. Sprzedawca z najniższą ceną ma availability: out_of_stock. System powinien preferować droższą ofertę z availability: in_stock. Ale co, jeśli sprzedawca ma availability: backorder z availability_date za 3 dni? Czy to traktowane jak in_stock?

Scenariusz 2: Producent kontra reseller. Producent smartwatchy sprzedaje model za 1299 zł. Reseller oferuje ten sam GTIN za 1149 zł. Jeśli system identyfikuje relację producenta z marką (np. przez zgodność seller_url z domeną marki), producent może być pokazywany jako „oficjalny” sprzedawca, nawet jeśli jest droższy.

Scenariusz 3: Niekompletne dane dostawy. Najtańszy sprzedawca nie wypełnił pola shipping. Droższy sprzedawca ma pełne dane: „PL::Standard:9.99 PLN:1:2:2:5″. Użytkownik pytający o „najszybszą dostawę” nie otrzyma odpowiedzi od najtańszego, bo system nie ma danych, żeby porównać czas dostawy.

Scenariusz 4: Marketplace vs sklep z wieloma fulfillment sellers. Duży marketplace przesyła feed z polem marketplace_seller. Ten sam produkt ma oferty od trzech sprzedawców na platformie. Czy system traktuje to jako trzy oferty, czy jedną ofertę marketplace z trzema opcjami fulfillmentu?

Co może zrobić sklep, żeby zwiększyć szanse na wybór przez ChatGPT

Poniższe rekomendacje wynikają z analizy specyfikacji ACP i są uporządkowane od najwyższego do najniższego priorytetu. Działania oznaczone jako „potwierdzone” opierają się na wymaganiach dokumentacji. Działania oznaczone jako „obserwacja” opierają się na architekturze systemu, nie na gwarancji wyniku.

Priorytet 1: Poprawność identyfikacji produktu (potwierdzone)

• Każdy produkt musi mieć poprawny gtin (8-14 cyfr, bez spacji i myślników). Bez GTIN system nie może jednoznacznie dopasować Twojej oferty do tego samego produktu u innych sprzedawców.
• title musi być spójny z tym, co użytkownik wpisze w zapytaniu. Maksymalnie 150 znaków, bez CAPS LOCK.
• availability musi być aktualna. Jeśli produkt jest out_of_stock na stronie, ale in_stock w feedzie, to jest rozbieżność, która obniża wiarygodność całego feedu – audyt treści produktowych pomaga wykryć takie niespójności.

Priorytet 2: Kompletność danych merchant-level (obserwacja)

• Wypełnij store_star_rating i store_review_count. Są opcjonalne w specyfikacji, ale dają systemowi dane do porównania reputacji sklepów.
• Dodaj return_rate, accepts_returns i return_deadline_in_days. Sklep z transparentną polityką zwrotów wygląda wiarygodniej niż sklep, który te pola pomija.
• Wypełnij shipping w pełnym formacie: PL::Standard:12.99 PLN:1:2:2:5. Podaj realne czasy obsługi i dostawy.
• Dodaj popularity_score, jeśli masz dane o sprzedaży danego produktu.

Priorytet 3: Spójność danych między feedem, DOM i schema – w tym ceny między feedem a stroną (potwierdzone + obserwacja)

• Cena w feedzie (price) musi zgadzać się z ceną na stronie produktu. Spójność danych między feedem, DOM i schema to jeden z najczęstszych problemów w e-commerce – rozjazd to sygnał niskiej jakości danych.
• Jeśli masz promocję, użyj sale_price, sale_price_start_date i sale_price_end_date. Nie zmieniaj price na czas promocji – to pole powinno zawsze pokazywać cenę regularną.
• Po zakończeniu promocji natychmiast zaktualizuj feed. Stara sale_price z przeszłą datą końcową to rozbieżność.

Priorytet 4: Sygnały związane z relacją do produktu (hipoteza)

• Jeśli jesteś producentem lub autoryzowanym dystrybutorem, zadbaj, żeby seller_url prowadził do oficjalnej domeny marki.
• Jeśli prowadzisz marketplace, używaj marketplace_seller do identyfikacji faktycznego sprzedawcy realizującego zamówienie. Specyfikacja mówi: „The marketplace_seller would be the point of checkout in this scenario, and the seller_name would be the shipment fulfiller”.
• Rozważ dodanie q_and_a i reviews na poziomie produktu. To nie wpływa na merchant selection bezpośrednio, ale poprawia kontekst informacyjny oferty.

Czym jest czego nie robić?

1. Nie zakładaj, że najniższa cena automatycznie daje pierwszą pozycję. Cena jest jednym z wielu pól ofertowych. Obniżanie ceny bez poprawy jakości feedu to strategia, która nie adresuje prawdziwego problemu. Warto najpierw przeprowadzić audyt SEO obejmujący diagnostykę feedu.
2. Nie kopiuj store_star_rating z Google. Pole wymaga wartości 0-5. Wstawianie zawyżonej wartości, której nie da się zweryfikować, niesie ryzyko utraty wiarygodności feedu.
3. Nie zmieniaj seller_name w feedzie, żeby „wyglądać” jak producent. Dla feedów kompatybilnych z Google, OpenAI nadpisuje seller_name zarejestrowaną nazwą merchanta. Próba manipulacji tym polem nie zadziała.
4. Nie traktuj wyboru produktu i wyboru sprzedawcy jako tego samego problemu. Poprawa opisu produktu może zwiększyć product selection rate, ale nie wpłynie na merchant selection rate. I odwrotnie: obniżenie ceny zwiększy szanse na pierwszą pozycję sprzedawcy, ale nie sprawi, że produkt stanie się bardziej trafny dla zapytania.
5. Nie ignoruj pola shipping. Jeśli użytkownik pyta o najszybszą dostawę, a Twój feed nie ma danych o dostawie, system nie może Cię zarekomendować dla tego promptu.
6. Nie opieraj strategii na pojedynczym pomiarze. Odpowiedzi AI są zmienne. Minimum 3 powtórzenia tego samego promptu w różnych dniach, żeby ocenić stabilność pozycji.

Kontekst patentowy: jak systemy mogą rozdzielać ranking produktu od rankingu oferty

Patenty opisują techniczne mechanizmy systemów informacyjnych. Nie dowodzą, że mechanizm jest obecnie używany w ChatGPT ani w żadnej konkretnej powierzchni wyszukiwania. W tym artykule wykorzystujemy je jako kontekst architektoniczny dla hipotez testowanych na obserwowanych danych.

Patent	Mechanizm	Klasa związku z tematem
US9141674B2	Łączenie trafności dokumentu z niezależnymi od zapytania sygnałami jakości źródła. Opisuje architekturę, w której dwa wymiary oceny (dopasowanie do zapytania i jakość kandydata) mogą być łączone w oddzielnych etapach.	Context only – porównanie kandydatów
US11249993B2	Dopasowanie atrybutów i faktów strukturalnych do zapytania. System izoluje atrybuty produktu (wymiary, materiał, specyfikacja) i porównuje je z oczekiwaniami wyrażonymi w zapytaniu.	Supporting – dopasowanie atrybutów
US9852224B2	Promowanie treści preferowanych przez tego samego użytkownika na podstawie wcześniejszych interakcji. System identyfikuje wzorce preferencji i nadaje priorytet treściom od źródeł, z którymi użytkownik wcześniej wchodził w interakcję.	Hypothesis only – preferencja użytkownika
US8442984B1	Predykcyjna ocena jakości dokumentu na podstawie sygnałów historycznych. Hipotetycznie: system mógłby oceniać jakość sprzedawcy na podstawie wcześniejszych interakcji użytkowników z jego ofertami.	Hypothesis only – predykcja jakości

Żaden z powyższych patentów nie opisuje bezpośrednio systemu ChatGPT ani Agentic Commerce Protocol. Są to patenty na mechanizmy ogólnego przeznaczenia, które mogą być stosowane w różnych kontekstach informacyjnych.

Porównanie z Google Shopping: podobieństwa i różnice

Google Shopping od lat rozdziela produkt od oferty. Mechanizm jest dobrze znany: pozycjonowanie sklepu internetowego wymaga zarówno poprawnego feedu produktowego, jak i konkurencyjnej oferty. W Merchant Center istnieją osobne raporty dla widoczności produktu (Product Performance) i porównań cenowych (Price Competitiveness).

ChatGPT Commerce ma kilka istotnych różnic:

• Forma prezentacji: Google Shopping pokazuje karuzelę z wieloma ofertami jednocześnie. ChatGPT generuje tekstową rekomendację, której personalizacja, gdzie często wskazuje jednego sprzedawcę. Użytkownik może nie wiedzieć, że istnieją alternatywne oferty.
• Identyfikacja sprzedawcy: W ACP seller_name jest nadpisywany przez zarejestrowaną nazwę merchanta. W Google Merchant Center nazwa sprzedawcy pochodzi z konfiguracji konta.
• Checkout: ACP wprowadza is_eligible_checkout, który pozwala na zakup bezpośrednio w ChatGPT. Google ma Universal Cart Program (UCP). Oba systemy wymagają dodatkowych pól polityki (privacy policy, ToS, return policy).
• Sygnały reputacji: ACP ma dedykowane pola store_star_rating, store_review_count, popularity_score i return_rate w feedzie. Google agreguje dane reputacyjne z innych źródeł (Google Reviews, Trusted Stores).

Dla sklepów, które już feedują do Google Merchant Center, przejście na ACP nie wymaga przebudowy danych produktowych – format jest kompatybilny (więcej o tym, jak feed produktowy wpływa na widoczność w AI). Ale wymaga uzupełnienia pól merchant-level, których Google nie wymagał w feedzie (bo zbierał je z innych źródeł).

Checklista: czy Twój feed jest gotowy na selekcję sprzedawcy

Poniższa lista dotyczy feedu przesyłanego do OpenAI Commerce (ACP). Oceń każdy punkt w kontekście swojego feedu.

1. Czy każdy produkt ma poprawny gtin (8-14 cyfr)?
2. Czy title odpowiada temu, co użytkownik wpisze w ChatGPT?
3. Czy availability w feedzie zgadza się ze stanem na stronie?
4. Czy price w feedzie zgadza się z ceną na stronie?
5. Czy wypełniłeś seller_name i seller_url?
6. Czy zarejestrowana nazwa merchanta w ACP jest poprawna i odpowiada Twojej marce?
7. Czy wypełniłeś store_star_rating i store_review_count?
8. Czy masz dane w polu shipping z pełnym formatem (kraj, metoda, cena, czas)?
9. Czy wypełniłeś accepts_returns, return_deadline_in_days i return_policy?
10. Czy Twoja sale_price jest aktualna (nie ma przeterminowanej daty końcowej)?
11. Czy is_eligible_search jest ustawione na true?
12. Czy monitorujesz, dla których GTIN Twój sklep jest wskazywany jako sprzedawca?

Jeśli odpowiedziałeś „nie” na więcej niż 3 pytania, Twój feed prawdopodobnie przegrywa selekcję sprzedawcy. Sprawdź też checklistę agentic commerce readiness, żeby ocenić gotowość sklepu do AI commerce.

Jaka jest metodologia i źródła?

Artykuł opiera się na analizie publicznej dokumentacji OpenAI Commerce (Agentic Commerce Protocol), specyfikacji feedu produktowego, zagadnień atrybucji agentic commerce oraz analizie porównawczej (w tym fact-checku danych produktowych z wielu źródeł) z Google Merchant Center. Źródła pierwotne:

• OpenAI Commerce – Products Feed Reference (weryfikacja: 17.08.2026).
• OpenAI Commerce – Best Practices (weryfikacja: 17.08.2026).
• OpenAI Commerce – File Upload Overview (weryfikacja: 17.08.2026).
• Shopping with ChatGPT Search.
• US9141674B2 – Ranking search results.
• US11249993B2 – Attribute matching.
• US9852224B2 – User content preference.
• US8442984B1 – Predictive quality assessment.

Badanie kontrolowane (case study Semgence) jest w fazie przygotowania. Wyniki zostaną opublikowane po zebraniu pełnej próby i minimum trzech powtórzeniach pomiarów. Denominatory, próba i ograniczenia zostaną przedstawione razem z wynikami.

Ograniczenia: Artykuł analizuje architekturę systemu na podstawie publicznej dokumentacji. Wewnętrzny algorytm rankingu ofert OpenAI nie jest znany. Hipotezy robocze wymagają weryfikacji na danych empirycznych – np. przez audyt widoczności w AI, który identyfikuje pozycję oferty na tle konkurencji dla tych samych GTIN. Obserwacje z pilotażu (jeśli zostaną dodane) będą oparte na małej próbie i powinny być traktowane jako wskazówki, nie prawidłowości ogólne.

Artykuł dotyczy powierzchni ChatGPT Commerce (organicznej). Mechanizmy ChatGPT Ads (płatnych) mają odrębny system selekcji oparty na oCPC i budżetach reklamowych.

Wybór sprzedawcy w ChatGPT – pytania z perspektywy sklepu?