1. Po co w ogóle jest potrzebny Product Feed
Porównując z klasycznym e‑commerce, Product Feed to coś pomiędzy:
- „witryną” produktów (katalog z cenami, dostępnością, linkami i mediami);
- oraz technicznym kontraktem, który opisuje, które dokładnie SKU merchant jest gotów pokazać i/lub sprzedać przez ChatGPT.
OpenAI w swojej specyfikacji wprost mówi, że feed — to jedyne źródło prawdy o produktach, na którym opierają się wyszukiwanie, rekomendacje i przygotowanie danych do checkoutu.
W zwykłym sklepie internetowym użytkownik sam przechodzi po stronach, przegląda kategorie, filtruje itd. W AI‑commerce jest odwrotnie: użytkownik po prostu mówi modelowi „dobierz mi cyfrowy prezent do 30 dolarów dla kolegi‑programisty, który lubi planszówki” — a ChatGPT już sam decyduje, które SKU z waszego Product Feed pasują, w jakiej kolejności je pokazać i jak to wszystko sformatować w postaci kart oraz późniejszego Instant Checkout.
Dlatego Product Feed rozwiązuje od razu kilka zadań.
Po pierwsze, daje ChatGPT ustrukturyzowane dane do wyszukiwania. Model opiera się nie tylko na opisie i nazwie produktu, ale także na kategoriach, tagach, cenie, dostępności, lokalizacji, ograniczeniach geograficznych.
Po drugie, jest źródłem danych dla checkoutu. Gdy ChatGPT zaczyna przygotowywać checkout_session, to właśnie z feedu pobierane są identyfikatory SKU, cena, waluta, seller URL i inne informacje handlowe.
I wreszcie, Product Feed — to sformalizowany kontrakt między wami a platformą. Wprost mówicie: „oto lista SKU, oto które z nich można tylko wyszukiwać (discovery), a które można też obsługiwać przez Instant Checkout”.
Aby to zobaczyć, wygodnie jest narysować prosty schemat.
flowchart TD A[GiftGenius DB] --> B[Feed Builder] B --> C["Product Feed (CSV/JSON/...)"] C --> D[OpenAI Ingestion] D --> E[Indeks wyszukiwania + ranking] E --> F[ChatGPT/Agent dobiera prezenty] F --> G["Instant Checkout (ACP)"]
Po lewej — wasza wewnętrzna baza, gdzie już żyje „prawdziwy” katalog. Po prawej — ChatGPT, który pokazuje się użytkownikowi. Pośrodku — Product Feed i mechanizmy jego przyjmowania oraz indeksowania. Wszystko, co robimy w tym wykładzie, znajduje się dokładnie między A i D.
2. Format i „fizyka” Product Feed
Specyfikacja OpenAI dość elastycznie podchodzi do formatu plików: wspierane są TSV, CSV, XML i JSON. Zrobiono to celowo, aby większość istniejących systemów (od własnych monolitów po Shopify) mogła eksportować feed bez magii.
W typowym wariancie:
- umieszczacie plik lub endpoint z Product Feed na swoim serwerze HTTPS;
- ten adres rejestrujecie w portalu ChatGPT Merchants;
- OpenAI okresowo pobiera ten feed, waliduje i indeksuje produkty.
Dokumentacja podkreśla, że feed należy aktualizować regularnie (można nawet co 10–15 minut), aby użytkownicy widzieli aktualne ceny i dostępność, zwłaszcza podczas wyprzedaży i szczytów ruchu.
W przykładzie edukacyjnym z GiftGenius będziemy pracować z formatem JSON, ponieważ jest wygodny dla programistów TypeScript. Ważne jednak, że na poziomie specyfikacji OpenAI nie jest przywiązane do JSON — po prostu dla nas to wygodniejsze.
Najprostszy feed JSON mógłby wyglądać tak:
[
{
"id": "gg-coffee-sub-1m-usd",
"title": "Subskrypcja kawy na 1 miesiąc",
"description": "Comiesięczne pudełko kawy ziarnistej dla programisty.",
"price": 2900,
"currency": "usd",
"availability": "in_stock",
"link": "https://giftgenius.app/gifts/coffee-subscription-1m",
"image_link": "https://cdn.giftgenius.app/images/coffee-1m.png",
"enable_search": true,
"enable_checkout": true
}
]W rzeczywistości pól będzie więcej i część z nich jest obowiązkowa, a inne — rekomendowane lub opcjonalne. Jak to jest zorganizowane — rozważymy dalej.
3. Produkt vs wariant (SKU): jak to modelować
Jedno z najczęstszych pytań: „Jak w Product Feed odzwierciedlić rozmiary, pakiety, długości subskrypcji i inne warianty jednego produktu?”
Specyfikacja Product Feed operuje wierszami/rekordami, z których każdy opisuje jedną sprzedawaną konfigurację. Wzorzec architektoniczny zalecany przez branżę (i dobrze dopasowany do feedu OpenAI) wygląda tak: każda osobna konfiguracja (rozmiar, wariant subskrypcji, taryfa, region) — to osobny rekord feedu, czyli oddzielne SKU.
Bazowy produkt żyje w waszym wewnętrznym modelu, a w feedzie pracujecie na poziomie SKU.
Na przykład macie usługę i subskrypcje na 1, 3, 6 miesięcy. Z punktu widzenia product feed to wszystkie różne SKU. Jeśli jedną usługę można kupić na 20 różnych warunkach, to w product feed powinniście mieć 20 SKU.
W TypeScript można to wyrazić mniej więcej tak:
// Wewnętrzny model GiftGenius
export interface GiftProduct {
id: string; // product_123
name: string;
description: string;
baseImageUrl: string;
}
// SKU, który trafi do Product Feed
export interface GiftSkuFeedItem {
id: string; // product_123_usd_1m
productId: string; // odnośnik do GiftProduct.id
title: string;
description: string;
price: number; // w najmniejszych jednostkach (centy)
currency: string; // "usd"
}
Wewnątrz GiftGenius możecie mieć relację jeden‑do‑wielu między GiftProduct i GiftSkuFeedItem. A w feedzie zwracacie już „płaską” listę SKU.
Aby ChatGPT mógł rozumieć, które SKU należą do jednego bazowego produktu (np. subskrypcja na 1, 3 i 12 miesięcy), często używa się pola grupującego typu item_group_id. To jednak wzorzec architektoniczny, a nie twardy wymóg standardu.
Na przykład:
{
"id": "gg-coffee-sub-1m-usd", // SKU subskrypcji na 1 miesiąc
"item_group_id": "gg-coffee-sub", // Wasz produkt
"title": "Subskrypcja kawy — 1 miesiąc",
"price": 2900,
"currency": "usd",
"enable_search": true,
"enable_checkout": true
}A dla subskrypcji 3‑miesięcznej:
{
"id": "gg-coffee-sub-3m-usd", // SKU subskrypcji na 3 miesiące
"item_group_id": "gg-coffee-sub", // Ten sam id produktu
"title": "Subskrypcja kawy — 3 miesiące",
"price": 7900,
"currency": "usd",
"enable_search": true,
"enable_checkout": true
}Takie podejście ułatwia i życie modelowi, i życie waszego backendu przy tworzeniu zamówień: ID SKU staje się unikalnym kluczem, dzięki któremu zawsze możecie znaleźć dokładną konfigurację, którą kupił użytkownik.
4. Pola obowiązkowe Product Feed i ich wpływ na UX
W specyfikacji Product Feed OpenAI dzieli pola mniej więcej na trzy grupy: obowiązkowe (required), rekomendowane (recommended) i opcjonalne (optional).
Konkretne nazwy i listy zawsze należy sprawdzać w aktualnej dokumentacji, ale do celów dydaktycznych można oprzeć się na takim „minimalnym” zestawie.
| Pole | Po co jest potrzebne | Co się stanie, jeśli go nie będzie |
|---|---|---|
|
Unikalny identyfikator SKU w ramach merchanta | Nie można jednoznacznie zidentyfikować towaru |
|
Krótka nazwa do karty | Modelowi trudniej zrozumieć, co to za produkt |
|
Rozszerzony opis | Odpowiedzi będą bardziej ogólne, gorsza personalizacja |
|
Cena w najmniejszych jednostkach | Nie da się przygotować checkoutu |
|
Kod waluty ISO 4217, zwykle małymi literami | Platforma nie będzie wiedziała, w jakiej walucie liczyć |
|
URL strony produktu u merchanta | Użytkownik nie będzie mógł przejść na waszą stronę |
|
Status dostępności (in_stock, out_of_stock itp.) | Mogą być pokazywane niedostępne produkty |
|
Czy można używać produktu w wyszukiwaniu | Bez true produkt nie trafi do wyników |
|
Czy można kupować przez Instant Checkout | Będzie tylko discovery/link‑out |
Ważna uwaga: enable_search i enable_checkout logicznie rozdzielają tryby pracy.
Jeśli enable_search = true, a enable_checkout = false, produkt może uczestniczyć w wynikach, ale przy próbie zakupu użytkownik przejdzie po waszym linku (link) na waszą stronę, a nie do Instant Checkout w środku ChatGPT (gdzie karta jest już podpięta).
Jeśli natomiast enable_checkout = true, to przy spełnieniu pozostałych warunków (obsługiwany region, waluta, prawidłowy backend ACP) produkt może zostać kupiony bezpośrednio w ChatGPT jednym–dwoma kliknięciami (co znacząco zwiększa konwersję).
Przykład „minimalnie użytecznego” obiektu GiftGenius do checkoutu:
{
"id": "gg-dev-notebook-plain-usd",
"title": "Minimalistyczny notes dla programisty",
"description": "Czarny, bez linii, 120 stron. Dla tych, którzy piszą specyfikacje ręcznie.",
"price": 1500,
"currency": "usd",
"availability": "in_stock",
"link": "https://giftgenius.app/gifts/dev-notebook",
"image_link": "https://cdn.giftgenius.app/images/dev-notebook.png",
"enable_search": true,
"enable_checkout": true
}Zwróćcie uwagę: nawet w przykładzie dodajemy obrazek (image_link) — formalnie może to być pole rekomendowane, a nie obowiązkowe, ale bez niego UX będzie znacznie gorszy.
5. Pola rekomendowane i opcjonalne: jak zrobić feed „atrakcyjniejszym”
Pola obowiązkowe — to „żeby w ogóle działało”. Jeśli jednak zatrzymacie się tylko na nich, otrzymacie coś na kształt minimalnie poprawnego CSV dla księgowości, a nie świetną witrynę AI.
Pola rekomendowane zwykle obejmują:
- główny i dodatkowe URL‑e obrazów;
- kategorię produktu (często na podstawie taksonomii, np. „gifts > experiences > online courses”);
- markę/nazwę merchanta;
- atrybuty takie jak kolor, rozmiar, materiał;
- flagi treści dla dorosłych, ograniczenia wiekowe itd.
Im bogatszy opis produktu, tym bardziej sensowne odpowiedzi będzie w stanie generować model. Na przykład, jeśli jasno zaznaczycie, że notes jest wykonany z papieru z recyklingu i „wspiera programistów, którzy troszczą się o planetę”, ChatGPT może świadomie rekomendować go użytkownikowi proszącemu o eko‑przyjazne prezenty.
W GiftGenius moglibyśmy rozszerzyć opis takiego SKU:
{
"id": "gg-dev-notebook-plain-usd",
"title": "Eko‑notes dla programisty",
"description": "Minimalistyczny notes bez linii, 120 stron z papieru z recyklingu.",
"price": 1500,
"currency": "usd",
"availability": "in_stock",
"link": "https://giftgenius.app/gifts/eco-dev-notebook",
"image_link": "https://cdn.giftgenius.app/images/eco-dev-notebook.png",
"category": "gifts > office > notebooks",
"brand": "GiftGenius Originals",
"enable_search": true,
"enable_checkout": true
}Dodatkowe atrybuty, takie jak category i brand, nie tylko poprawiają wyniki, ale i pomagają w analityce: możecie sprawdzać, które kategorie lepiej konwertują przez ChatGPT, a które gorzej.
Pola opcjonalne często związane są z bardzo specyficznymi scenariuszami (np. geoparametry ceny, o których porozmawiamy osobno, albo własne metadane). Warto dodawać je w miarę dojrzewania projektu, a nie „dla odhaczenia”.
6. Flagi komercyjne i tryb discovery‑only
Jeszcze raz jasno ustalmy logikę enable_search i enable_checkout, ponieważ to krytyczny most do kolejnych wykładów o ACP i Instant Checkout.
Załóżmy, że dopiero zaczynacie jako merchant ChatGPT. Macie katalog prezentów, ale ACP‑backend i Delegated Payment są jeszcze w trakcie prac. Chcecie już teraz, aby ChatGPT mógł znajdować wasze SKU i odsyłać użytkowników na waszą stronę do płatności.
W takim przypadku:
- publikujecie Product Feed z enable_search = true dla potrzebnych SKU;
- pozostawiacie enable_checkout = false do czasu, aż wdrożycie i certyfikujecie integrację ACP.
Wtedy ChatGPT będzie mógł włączać wasze prezenty do odpowiedzi dla użytkowników, pokazywać karty i proponować link „Przejdź na stronę GiftGenius”, ale nie będzie budował wewnętrznego UI Instant Checkout.
Gdy wdrożycie Agentic Checkout i Delegated Payment, wybrane produkty można przełączyć w tryb „gotowe do Instant Checkout” — po prostu ustawiając enable_checkout = true i dodatkowo spełniając wszystkie wymagania dotyczące danych (obecność ceny, waluty, seller URL itd.).
Na poziomie specyfikacji to właśnie pola z Product Feed będą używane do wypełniania pól line_items i sumy w checkout_session.
W ten sposób feed staje się dźwignią precyzyjnej konfiguracji: które dokładnie SKU i w jakiej formie ChatGPT w ogóle ma prawo sprzedawać w waszym imieniu.
7. Locale, waluty, regiony i ceny multi‑regionalne
Pewnie wiecie, że świat nie ogranicza się do en-US i dolarów. W modułach o lokalizacji omawialiśmy już, jak locale i userLocation wpływają na logikę biznesową. Tutaj to wychodzi na pierwszy plan: produkty w Niemczech mogą kosztować inaczej niż w USA, a niektórych prezentów nie można sprzedawać w wybranych krajach.
Specyfikacja Product Feed uwzględnia to przez kilka mechanizmów.
Po pierwsze, waluta: currency musi być prawidłowym kodem ISO 4217 (np. usd, eur, gbp).
Po drugie, można używać pól opisujących cenę i dostępność zależną od geolokalizacji. W dokumentacji podaje się przykład atrybutów w rodzaju geo_price i powiązanych z nim kodów regionalnych opartych na ISO 3166.
Są dwa podstawowe podejścia architektoniczne.
Podejście pierwsze: jeden feed na jeden region.
- product-feed-us-en.json dla USA;
- product-feed-de-de.json dla Niemiec;
- product-feed-br-pt.json dla Brazylii.
W każdym feedzie wszystkie SKU są już przeliczone do właściwej waluty i locale. To prostsze dla ChatGPT, ale więcej pracy dla was przy utrzymaniu wielu feedów.
Podejście drugie: jednolity feed z polami geo.
W każdej pozycji przechowujecie albo tablicę cen, albo dodatkowe atrybuty:
{
"id": "gg-dev-notebook-multi",
"title": "Eko‑notes dla programisty",
"description": "Wspiera waszą miłość do czystego kodu i do planety.",
"prices": [
{ "region": "US", "currency": "usd", "price": 1500 },
{ "region": "DE", "currency": "eur", "price": 1400 }
],
"availability_by_region": [
{ "region": "US", "availability": "in_stock" },
{ "region": "DE", "availability": "out_of_stock" }
],
"enable_search": true,
"enable_checkout": true
}Konkretna struktura pól multi‑regionalnych zależy od wersji specyfikacji, ale idea jest jedna: feed musi pozwolić platformie zrozumieć, w jakich krajach istnieje dane SKU i ile tam kosztuje.
Z punktu widzenia GiftGenius ważne jest przemyślenie mapowania między:
- locale i userLocation, które zna ChatGPT;
- a tą częścią feedu, z której należy brać ceny i teksty.
Najczęściej w scenariuszach komercyjnych nie zwracacie jednej pozycji „na cały świat”, tylko tworzycie różne SKU na różne kraje, aby łatwiej było przestrzegać podatków, polityk i ograniczeń produktowych.
8. Jakość danych i polityka: bez tego Instant Checkout nie wypali
Product Feed — to nie tylko format, ale i jakość danych oraz zgodność z polityką OpenAI.
W części jakości OpenAI wyraźnie wymaga:
- poprawnych, stabilnych identyfikatorów;
- prawidłowych URL z HTTPS i kodem odpowiedzi 200;
- spójności ceny i waluty;
- aktualnej dostępności (nie powinno być in_stock produktów, których faktycznie już nie ma).
W specyfikacji są także wymagania dotyczące długości tekstów: na przykład title nie powinien być zbyt długi (setki znaków), a description ma rozsądny limit (tysiące znaków), aby karty wyglądały schludnie i nie zamieniały się w powieść w trzech tomach.
Oddzielny blok — Prohibited Products Policy. To lista kategorii produktów i usług, których nie wolno sprzedawać przez Instant Checkout i/lub ChatGPT w ogóle: oczywiste rzeczy, jak nielegalne towary, broń, niektóre usługi medyczne itd. Konkretne informacje zawsze należy sprawdzać w aktualnej polityce, ale dla nas ważne jest zrozumienie: Product Feed będzie sprawdzany nie tylko pod kątem formatu, lecz także dopuszczalności treści.
Jeśli wasz katalog zawiera niejednoznaczne kategorie (np. alkohol, hazard lub coś związanego z dziećmi), należy podchodzić do tych sekcji ze szczególną uwagą. Często łatwiej pozostawić je w trybie enable_checkout = false i sprzedawać wyłącznie przez własną stronę z pełną obsługą prawną.
9. Praktyka: składamy minimalny Product Feed dla GiftGenius
Zastosujmy teraz wszystko w praktyce i złóżmy prosty feed dla trzech SKU GiftGenius. Załóżmy, że mamy:
- Eko‑notes dla programisty.
- Subskrypcję kawy na 1 miesiąc.
- Bon podarunkowy na kurs „TypeScript dla dorosłych”.
Najpierw opiszemy typ TypeScript, którego użyjemy do generowania feedu:
export interface GiftGeniusFeedItem {
id: string;
title: string;
description: string;
price: number; // w centach
currency: "usd" | "eur";
availability: "in_stock" | "out_of_stock";
link: string;
image_link?: string;
enable_search: boolean;
enable_checkout: boolean;
}Teraz utworzymy w kodzie tablicę z kilkoma elementami, a następnie zserializujemy ją do JSON:
export const giftGeniusFeed: GiftGeniusFeedItem[] = [
{
id: "gg-eco-notebook-usd",
title: "Eko‑notes dla programisty",
description: "Minimalistyczny notes bez linii z papieru z recyklingu.",
price: 1500,
currency: "usd",
availability: "in_stock",
link: "https://giftgenius.app/gifts/eco-dev-notebook",
image_link: "https://cdn.giftgenius.app/images/eco-dev-notebook.png",
enable_search: true,
enable_checkout: true
},
{
id: "gg-coffee-sub-1m-usd",
title: "Subskrypcja kawy dla programisty — 1 miesiąc",
description: "Comiesięczne pudełko kawy ziarnistej. Kompatybilne z deadline’ami.",
price: 2900,
currency: "usd",
availability: "in_stock",
link: "https://giftgenius.app/gifts/coffee-subscription-1m",
image_link: "https://cdn.giftgenius.app/images/coffee-1m.png",
enable_search: true,
enable_checkout: true
},
{
id: "gg-ts-course-gift-usd",
title: "Bon podarunkowy na kurs TypeScript",
description: "Kurs online dla programistów, którzy wreszcie chcą zrozumieć generics.",
price: 9900,
currency: "usd",
availability: "in_stock",
link: "https://giftgenius.app/gifts/ts-course",
image_link: "https://cdn.giftgenius.app/images/ts-course.png",
enable_search: true,
enable_checkout: false // na razie tylko discovery
}
];Dalej można przygotować proste narzędzie, które co N minut będzie generowało plik product-feed.json z tej struktury i umieszczało go na waszym serwerze HTTPS.
import { writeFile } from "node:fs/promises";
import { giftGeniusFeed } from "./feed-data";
// Najprostszy generator feedu JSON
async function buildProductFeed() {
const json = JSON.stringify(giftGeniusFeed, null, 2);
await writeFile("public/product-feed.json", json, "utf8");
}
buildProductFeed().catch(console.error);Jasne, że w realnym projekcie nie będziecie trzymać całego feedu w kodzie; zamiast tego dane będą pobierane z bazy. Ale na początek warto złożyć choć taki przykład, aby przetestować pipeline: generowanie → publikacja → walidacja.
10. Antyprzykład: jak wygląda „zły” Product Feed
Aby lepiej poczuć wymagania specyfikacji i UX, warto spojrzeć na przykład feedu, który formalnie prawie działa, ale w praktyce prowadzi do problemów:
{
"id": "1",
"title": "Prezent",
"description": "Fajny prezent",
"price": 12.333333,
"currency": "usdollars",
"availability": "yes",
"link": "http://giftgenius.local/gift/1",
"enable_search": "true",
"enable_checkout": "maybe"
}Tutaj można naliczyć od razu kilka problemów.
Po pierwsze, id = "1" — to niestabilny i mało znaczący identyfikator. Jeśli kiedykolwiek zmigrujecie bazę lub wprowadzicie sharding, takie identyfikatory stają się kruche. Lepiej używać sensownych i wystarczająco długich ID, unikalnych w ramach merchanta.
Po drugie, price podano jako liczbę dziesiętną z potencjalnie nieskończonym ogonem. Specyfikacje i systemy płatności zazwyczaj oczekują ceny w najmniejszych jednostkach (centy, grosze) jako liczby całkowitej, aby uniknąć problemów z liczbami zmiennoprzecinkowymi i zaokrąglaniem.
Po trzecie, currency = "usdollars" oraz availability = "yes" nie odpowiadają oczekiwanym formatom (ISO 4217 i lista dopuszczalnych statusów).
Po czwarte, link prowadzi na http i domenę lokalną — ani jedno, ani drugie nie jest akceptowalne w prawdziwym produkcie; specyfikacja wprost wymaga HTTPS i publicznej dostępności.
Po piąte, flagi enable_search i enable_checkout powinny być typu boolean, a nie stringami. W przeciwnym razie parser OpenAI albo nie przyjmie feedu, albo sprowadzi je do wartości domyślnej, która może was niemile zaskoczyć.
Takie problemy mogą prowadzić zarówno do twardego błędu walidacji (feed odrzucony), jak i do bardziej nieprzyjemnej sytuacji: feed formalnie przyjęty, ale część SKU jest ignorowana lub działa inaczej, niż oczekujecie. Dlatego warto inwestować w wewnętrzną walidację po waszej stronie.
11. Typowe błędy przy pracy z Product Feed
Błąd nr 1: myślenie o feedzie jak o „jednorazowym CSV” do importu.
Zdarza się, że zespoły traktują Product Feed jak plik, który raz wygenerują „do integracji” i zapomną. W AI‑commerce to tak nie działa: feed — żywe źródło prawdy, które musi być regularnie aktualizowane. Jeśli zmieniacie ceny, zdejmujecie produkty ze sprzedaży, uruchamiacie promocje — wszystko to powinno na czas trafiać do feedu. W przeciwnym razie ChatGPT będzie rekomendował to, czego już nie ma, lub po starej cenie, a użytkownicy słusznie będą niezadowoleni.
Błąd nr 2: mieszanie modelu produktu i SKU.
Popularny antywzorzec — próba odzwierciedlenia jednego bazowego produktu z masą opcji w jednym rekordzie feedu z wieloma polami „size1/size2/size3” czy „duration1/duration2”. W efekcie model nie rozumie, co właściwie jest sprzedawane, a wasz ACP‑backend cierpi przy rozpakowywaniu tych pól w momencie checkoutu. O wiele prościej i pewniej: jedno SKU — jeden rekord feedu, nawet jeśli to wariant w ramach jednego produktu.
Błąd nr 3: ignorowanie locale i regionów.
Twórcy pierwszego MVP często ustawiają currency = "usd" i enable_checkout = true dla wszystkiego, nie zastanawiając się, że Instant Checkout w ich regionie może być niedostępny albo niektórych produktów nie wolno sprzedawać w poszczególnych krajach z uwagi na politykę lub prawo. Potem, przy wejściu na nowy rynek, wszystko zaczyna się sypać: ceny się nie zgadzają, podatki są pominięte. Lepiej od początku wiązać SKU z regionami i walutami, nawet jeśli na razie macie tylko jeden rynek.
Błąd nr 4: traktowanie opisów jak SEO‑tekstów z przeszłości.
Część zespołów kopiuje do Product Feed stare opisy ze swoich stron, pisane pod „słowa kluczowe” i roboty. Dla ChatGPT to bardziej szkodliwe niż pomocne: model i tak umie pisać tekst, a ważniejsze są ustrukturyzowane, rzetelne i dokładne fakty. Lepiej opisywać krótko i rzeczowo, niż zalewać description marketingowym wodolejstwem na pół ekranu.
Błąd nr 5: brak samodzielnej walidacji feedu.
Poleganie tylko na walidacji po stronie OpenAI to przepis na nieprzespane noce przed deadlinami. Warto zrobić prosty walidator po swojej stronie (backend lub CI), który sprawdzi schematy pól, dozwolone wartości, formaty URL i walut. Da się to zrobić nawet w TypeScript, używając np. Zod lub własnych sprawdzeń. Wtedy będziecie wyłapywać problemy zanim wrzucicie feed na produkcję.
Błąd nr 6: wrzucanie do Product Feed „wszystkiego jak leci”.
Czasem kusi, by dorzucić do feedu tysiące SKU, „bo może się przydadzą”. W praktyce utrudnia to i debugowanie, i analitykę, i kontrolę jakości. Znacznie rozsądniej zacząć od ograniczonego podzbioru: tylko te kategorie i SKU, nad którymi panujecie i które naprawdę chcecie sprzedawać przez ChatGPT. Resztę można trzymać w trybie discovery lub w ogóle pominąć integrację.
Błąd nr 7: brak synchronizacji między Product Feed a ACP‑backendem.
Feed i ACP‑API — dwie strony tej samej monety. Jeśli w feedzie pojawi się nowe SKU, a wasz backend jeszcze nie umie go sprzedawać (albo odwrotnie, SKU usunięto z feedu, ale backend wciąż wierzy, że istnieje), doprowadzi to do rozjazdów, trudnych bugów i trudnych zgłoszeń do supportu. Dobrą praktyką jest posiadanie jednolitego modelu domenowego katalogu i używanie go zarówno do generowania feedu, jak i do obsługi checkoutu.
GO TO FULL VERSION