Product Feed para sa AI Agent: Ang mga Field na Talagang Binabasa Nila

Mas matagal pa ang buhay ng product feed para sa agentic commerce kaysa sa checkout button na siyang dahilan kung bakit ito ginawa. Inilabas ng OpenAI at Stripe ang Agentic Commerce Protocol noong huling bahagi ng Setyembre 2025, kasama ang in-chat purchasing; noong Marso 2026, pinatay ng OpenAI ang in-chat checkout pero pinanatili ang feed. Hindi ito maliit na detalye. Ibig sabihin, ang parteng natitira pang mahalaga sa iyo ay ang pinakaboring na parte — ang mga column ng structured product data na binabasa ng AI assistant bago nito desisyunan kung babanggitin ka ba nito o hindi.

Kung furniture, fittings, o building materials ang binebenta mo, may isang linya sa spec na iyon na katumbas ng buong artikulo: ang mga field na sumasagot sa "kasya ba ito?" ay optional lang.

Apat na hakbang na nagdala sa atin dito

Kailan	Ano ang nangyari	Ano ang ibig sabihin para sa seller
Huling bahagi ng Setyembre 2025	Inilathala ng Stripe at OpenAI ang Agentic Commerce Protocol at inilunsad ang Instant Checkout sa ChatGPT, simula sa mga US Etsy seller at Shopify merchant	Dalawang trabaho ang dumating nang sabay: magpadala ng product feed, at ikabit ang agent-initiated checkout
Huling bahagi ng 2025 hanggang simula ng 2026	Manipis pa rin ang paggamit ng in-chat purchasing habang patuloy na nagre-research ang mga shopper sa assistant tapos bumibili sa sariling site ng merchant	Ang discovery na parte ang gumagana; ang checkout na parte, hindi
Marso 2026	Tinapos ng OpenAI ang Instant Checkout at lumipat sa product discovery at retailer integrations sa loob ng ChatGPT	Hindi na urgent ang checkout integration
Ngayon	Ang Product Feed Specification ang natitirang tulay sa pagitan ng catalog mo at ng assistant	Ang kalidad ng feed ang buong laro

Simple lang at matibay ang aral: ang integration work na nag-expire ay ang payment plumbing. Ang trabahong nag-ipon ng halaga ay ang data.

Ano ang product feed para sa AI agent

Ang product feed para sa AI agent ay isang regular na ina-update, machine-readable na file ng catalog mo — identifiers, titles, descriptions, presyo, availability, media, fulfilment at physical attributes — na kinukuha ng AI assistant para mailabas, ma-filter, at maikumpara ang mga produkto mo sa loob ng usapan. Hindi ito crawl ng site mo at hindi ito ang HTML ng storefront mo. Flat file ito na ikaw mismo ang nag-aabot, isang row bawat produkto o bawat variant.

Sa teknikal na parte, ayon sa kasalukuyang spec, ang file na iyon ay UTF-8 delimited text — .txt, .tsv, o .csv, tab o comma separated, puwedeng naka-gzip — na may lowercase, underscore-separated na header row. Bawat URL doon ay dapat mag-return ng HTTP 200. Nagpapadala muna ang merchant ng sample feed para ma-validate, tapos araw-araw nang snapshot, at tumatanggap ang sistema ng update kasingdalas ng bawat 15 minuto.

Ang HTTP 200 na requirement na iyan ay dapat pag-isipang mabuti. Ang patay na image URL ay hindi lang nagpapababa ng ranking ng row na iyon; pinapawalang-bisa nito ang buong row. Ang sirang CDN link ang pinakatahimik na paraan para mawala ka sa sagot ng isang assistant.

Ang mga field, nakagrupo ayon sa gastos kapag binalewala

Ito ang kasalukuyang hugis ng spec. Hindi ang listahan ang mahalaga — kundi kung saang tier nakaupo ang bawat field.

Tier	Mga field	Tala
Required	`item_id`, `title`, `description`, `url`, `brand`, `image_url`, `price`, `availability`, `seller_name`, `seller_url`, `target_countries`, `store_country`, plus ang `is_eligible_search` / `is_eligible_checkout` / `is_ads_eligible` na flags	Ang `title` ay hanggang 150 characters, ang `description` ay 5,000, ang `brand` at `seller_name` ay 70
Conditionally required	`gtin` o `mpn` maliban kung naka-set sa no ang `identifier_exists`; `availability_date` para sa pre-order at backorder; `return_policy`; privacy policy at terms ng seller kapag naka-enable ang checkout	Ang kulang na identifier ang klasikong silent-suppression bug na minana mula sa lahat ng ibang feed standard
Recommended	`group_id`, `listing_has_variations`, `variant_dict`, `size`, `size_system`, `q_and_a`, `reviews`, `related_product_id` kasama ang `relationship_type`	Tumatanggap ang `relationship_type` ng values tulad ng `part_of_set`, `required_part`, `often_bought_with`, `substitute`, `accessory`
Optional	`dimensions`, `length`, `width`, `height`, `dimensions_unit`, `weight`, `item_weight_unit`, `material`, `condition`, `product_category`, `additional_image_urls`, `video_url`, `model_3d_url`, `return_rate`, `popularity_score`, `warning`, `age_restriction`	Lahat ng pisikal na katangian ng produkto mo ay nakatira sa tier na ito

Tingnan mo ulit ang pinakailalim na row. Required ang image_url. Optional ang length, width, height at dimensions_unit. Ang tanong na halos pinakamadalas itanong ng mga shopper sa assistant — kasya ba ito sa espasyo ko, sa sasakyan ko, sa existing na frame ko — ay nakasalalay sa mga field na madalas iwang blangko ng karamihan ng feed.

Ang butas sa sukat, at bakit ito oportunidad

Ang optional ay hindi ibig sabihing binabalewala. Ibig sabihin lang, hindi ito ipinipilit — at sa ekonomiya ng feed, iyon ang pinaka-interesanteng estado na puwedeng abutin ng isang field: pinapayagan ang lahat ng kakumpitensya na laktawan ito, at karamihan ay nilalaktawan nga, kasi ang paglagay ng length / width / height / dimensions_unit sa ilang libong SKU ay totoong trabaho na kahit kailan ay hindi naman inirereklamo ng error log ng checkout ninuman.

Ang assistant na tinanong ng "bookshelf na wala pang 80 cm ang lapad para sa alcove" ay puwede lang mag-shortlist ng mga row kung saan may width at nababasa ito. Ang row na may nakakabighaning litrato pero walang laman ang width ay hindi binababaan ng ranking para sa query na iyon — hindi talaga ito kandidato. Hindi fallback ang litrato. Walang assistant na sumusukat sa JPEG mo.

May tatlong praktikal na resulta:

Punuan muna ang physical fields bago mo i-optimize ang kahit ano pa. Tumatanggap ang dimensions ng maikling string tulad ng 12x8x5 in; ang length, width at height ay kumukuha ng hiwa-hiwalay na values kung saan ang dimensions_unit ang nagdadala ng in o cm. Punuan ang composite at ang hiwalay na fields kung kaya ng data mo — magkaiba ang binabasa ng magkaibang consumer.
Ilagay nang malinaw ang dimensions_unit, bawat row. Ang 80 na walang label ay hindi sukat. Ito rin ang parehong pagkakamali na lumalabas sa mismong listing, na tinalakay sa structured data ng dimensyon ng produkto.
Ituring ang material, weight at item_weight_unit na iisang bloke. Ang material ang paraan ng buyer para mag-filter ng "solid oak, hindi veneer." Ang weight ang paraan ng shopper na nag-iisip ng logistics para malaman kung kaya ba itong buhatin paakyat ng isang tao lang.

May dala ring optional na return_rate field ang spec, nakalagay bilang porsyento. Anuman ang gawin ng isang assistant sa signal na iyon, ang mismong pagkakaroon nito sa schema ay dapat pag-isipan: structured at maikukumparang product attribute na ngayon ang performance ng returns, hindi na pribadong internal metric. Kung hindi ka pa nakapaglagay ng numero sa halaga ng returns bawat SKU, ang return rate calculator ang pinakamabilis na paraan para makakuha ng isa.

Ang hindi kayang solusyunan ng feed

Ang feed data ang naglalagay sa iyo sa shortlist. Hindi nito isinasara ang benta, dahil sa page mo pa rin dumadapo ang buyer.

Doon sa turnover na iyon tahimik na tumatagas ang maraming maganda sanang feed work. Sinasabi ng assistant sa shopper na 78 cm ang lapad ng shelf; pagpindot ng shopper, mapupunta siya sa listing kung saan puro naka-styling na kuwarto ang litrato at walang kahit isang sukat. Walang kumukumpirma sa sinabi sa kanya. Dalawa ang pinakakaraniwang kalalabasan: pre-sale message na kailangan mong sagutin nang isa-isa, o binili nang basta na lang umaasa at bumalik bilang size return.

Visual na trabaho ang pagsara ng loop na iyon, hindi data work. Ibig sabihin, may dala ang product page na larawan kung saan ang totoo at nasukat na dimensyon ay nakaguhit mismo sa produkto — mga numerong pareho sa idineklara ng feed, ipinapakita sa mismong tinitingnan na ng buyer. Mahalaga rito ang deterministikong pagsukat sa paraang hindi pa nangyayari dati: ang numero sa feed mo at ang numero sa larawan mo ay puwede nang i-cross-check ng makina, at ang AI-generated na larawan na gumagawa-gawa ng mukhang kapani-paniwalang sukat ay lalabag sa sarili mong structured data sa harap ng publiko.

Susunod na hakbang, sa pagkakasunod na kumikita

Piliin ang pinakamataas na tier na kaya mo talagang tapusin sa quarter na ito. Mas mabuti ang isang natapos nang buo kaysa sa lahat na sinimulan.

Audit muna ang invalid na rows. Anumang url o image_url na hindi nagre-return ng HTTP 200 ay nagpapabagsak ng buong row. Isang hapon lang na script ito at kadalasan ito ang pinakamalaking iisang recovery.
Ayusin ang identifiers. Punuan ang gtin o mpn, o i-set nang tapat ang identifier_exists. Mas masahol ang silent suppression kaysa sa error na nakikita mo.
Punuan ang physical block. length, width, height, dimensions_unit, weight, item_weight_unit, material — unahin ang pinakamabentang SKU, tapos bumaba ayon sa kita hanggang sa buntot.
Ayusin nang tama ang variants. Ang group_id, listing_has_variations at variant_dict ang paraan para maintindihan ng assistant na iisa lang ang produkto ng 60 cm at 80 cm na bersyon, para maialok nito ang kasya.
Pagtugmain ang numero sa feed at ang larawan sa page. Gawin man ito sa in-house na design workflow, sa agency, o sa software na nagla-lock ng nasukat na dimensyon sa litrato at nag-e-export sa image size ng bawat platform, iisa ang layunin: ang numerong binabanggit ng assistant ay nakikita sa page na pinagpapadalhan nito sa buyer. Kung pareho ang catalog na binebenta mo sa maraming channel, kapit din dito ang payo sa pagkakasunod-sunod sa pagbebenta sa maraming platform.
Saka mo lang intindihin ang reviews, q_and_a, popularity_score at ang natitirang enrichment tier.

FAQ

Kailangan ko pa ba ng product feed ngayong wala na ang Instant Checkout?

Oo — mas kailangan pa nga kaysa dati, dahil ang feed na mismo ang buong integration ngayon, hindi na kalahati lang. Itinigil ang in-chat purchasing noong Marso 2026; ang product discovery, hindi. Ang feed ang paraan para malaman ng assistant na may catalog ka, at sa sarili mong site pa rin nangyayari ang checkout.

Ano ang Agentic Commerce Protocol?

Ang Agentic Commerce Protocol ay bukas na spec na magkatuwang na binuo ng OpenAI at Stripe, inilathala noong huling bahagi ng Setyembre 2025, na nagtatakda kung paano nagpapalitan ang mga merchant ng product data, cart at order information kasama ang AI agents. Ang Product Feed Specification nito ang parteng namamahala kung paano inilalarawan ang catalog mo.

Anong feed fields ang nagpapa-filter sa AI shopping agent base sa sukat?

length, width, height kasama ang dimensions_unit, plus ang composite na dimensions string, at ang weight kasama ang item_weight_unit. Nasa optional tier lahat sila ng spec, kaya nga hindi ma-filter sa fit ang karamihan ng catalog — at kaya rin isa ang pagpuno sa kanila sa iilang natitirang murang bentahe sa feed work.

Gaano kadalas dapat i-refresh ang product feed para sa AI agent?

Nagsusumite muna ang merchant ng sample feed para ma-validate, tapos araw-araw nang snapshot, at tinatanggap ang update kasingdalas ng bawat 15 minuto. Araw-araw ang panggawang baseline; ang 15-minutong hangganan ay para sa pabago-bagong presyo at inventory, hindi para ulit-ulitin ang catalog na wala namang nagbago.

Nakakapalit ba ang magandang product photo sa kulang na dimension fields?

Hindi, at ito ang unang assumption na dapat itapon. Ang mga litrato ay para sa tao; ang filtering na nagdedesisyon kung mapapasama ka sa shortlist ay nangyayari sa text fields. Hindi kayang sukatin ng sistemang nag-uugnay ang isang litrato — kaya lang nitong kumpirmahin, para sa tao, ang inangkin na ng mga field.