Product Feed ChatGPT Ads: Apa yang Harus Disiapkan Merchant

Begitu shopping dan ads masuk ChatGPT, banyak merchant punya reaksi yang sangat familiar.

“Kita sudah punya feed Google Merchant Center. Tinggal kirim aja, kan?”

Mungkin sebagian bisa digunakan.

Tetapi jangan asumsikan zero work.

OpenAI sekarang mendokumentasikan product feeds melalui Agentic Commerce Protocol. Product feed membantu ChatGPT mengindeks product, memahami core attributes, dan menampilkan informasi seperti title, description, image, price, serta availability dengan lebih akurat.

Untuk Ads, OpenAI menggunakan base product schema yang sama dengan tambahan eligibility requirement. Salah satu field penting adalah:

`is_ads_eligible=true`

untuk product yang ingin diproses untuk ChatGPT Ads.

Kalau merchant sudah punya Google-compatible feed, OpenAI juga menyediakan compatibility path untuk format tertentu setelah feed terdaftar/confirmed.

Tetapi feed readiness bukan cuma format.

Yang lebih sulit adalah data quality.

ID.

Title.

Price.

Stock.

Variant.

Image.

URL.

Brand.

Semua harus stabil dan current.

Mulai dari merchant identity

Sebelum product row, merchant identity harus jelas.

OpenAI product feed docs menyebut merchant display name digunakan sebagai seller identity.

Jangan placeholder.

“unknown.”

“N/A.”

“seller123.”

Gunakan nama yang benar.

Ini penting untuk buyer trust.

Product identity tidak bisa dipisahkan dari seller.

Kalau company punya multiple storefront atau brand, governance harus jelas.

Brand field adalah product brand.

Merchant identity adalah seller.

Jangan campur.

Marketplace especially harus distinguish product brand vs seller name.

Stable product ID adalah foundation

Setiap product atau variant membutuhkan stable ID.

Jangan generate ID berdasarkan row number yang berubah setiap upload.

SKU stable.

Variant ID stable.

OpenAI product schema menggunakan item ID sebagai canonical record reference.

Jika ID berubah, system bisa melihat product baru.

History terpecah.

Update harder.

Ads eligibility state can reset/misalign depending integration behavior.

Use internal PIM/ERP stable key.

Not title.

Title can change.

SKU shouldn't.

Variant per row

Feed compatibility path OpenAI menyebut satu product atau variant per row.

Ini important.

Kaos:

S black.

M black.

L black.

S white.

Each variant may need distinct row depending model.

Group relationship via item group/group fields.

Don't collapse all sizes into one row if price, availability, or image differs.

AI shopping user often asks:

“size 43 black in stock?”

Need variant-level truth.

Product feed is not brochure catalog.

It is transaction-oriented data.

Required basic fields must be complete

For Google-compatible path, OpenAI docs list core fields such as:

id.

title.

description.

link.

image_link.

availability.

price.

brand.

For OpenAI-native schema, equivalent core information applies.

Don't launch with 30% missing description.

Don't use title as description.

Don't leave brand blank.

Feed validation may reject malformed rows.

Even if accepted, thin data reduces usefulness.

Merchant should monitor:

accepted.

rejected.

warnings/errors.

coverage.

Don't treat upload success as catalog success.

Some rows can fail while others process.

Title should describe product, not marketing noise

Bad:

“BEST SELLER ORIGINAL TERMURAH 2026 PROMO!!!”

Good:

“Men’s Trail Running Shoes Waterproof Black.”

Title has job:

identify.

differentiate variant.

Help retrieval.

Not shout.

OpenAI product docs put title length/format constraints and recommend plain product information.

Description can be richer but still factual.

Material.

use case.

features.

compatibility.

Do not stuff search terms.

Conversational shopping benefits from descriptive attributes.

But only true ones.

Price must include currency and be current

Price isn't decorative.

ChatGPT can present product info.

Ads can drive user to purchase.

Wrong price is trust failure.

Feed docs require amount + currency.

For Indonesia:

if integration supports IDR market, use configured currency according feed setup.

Do not assume market without confirmation.

OpenAI notes market-specific processing depends registered feed configuration.

Merchant must confirm supported market and currency.

If sale price:

must be valid.

Within effective period.

Lower than regular price.

Don't leave expired sale.

Feed update cadence needs match price volatility.

Flash sale every two hours?

Daily file may be stale.

API updates may be better if available.

OpenAI commerce docs generally recommend full feed periodically plus updates during day depending integration.

Choose based catalog dynamics.

Availability is equally important

In stock.

Out of stock.

Backorder.

Preorder.

If preorder/backorder, availability date may be required.

This is important for AI shopping.

User asks:

“bisa dikirim minggu ini?”

If feed says in stock but warehouse zero, bad.

Inventory source should be operational system.

Not manual spreadsheet.

For small merchant, manual possible.

But update discipline.

Feed quality is business operation.

AI Ads cannot compensate stale inventory.

Product URL must be directly reachable

Feed `url` should resolve.

HTTP 200.

Public.

Product detail page.

No login.

No broken redirect.

No geo block that prevents target market.

For Ads, landing page also needs OAI-AdsBot crawlability.

This is where article 157 connects.

Feed says product exists.

AdsBot must validate landing page.

If URL behind WAF challenge:

feed valid perhaps.

Ad review fails.

Commerce stack includes:

feed.

website.

crawler.

checkout.

All must align.

Image URL must be public and accurate

Main image.

High quality.

Correct variant.

No auth token that expires.

No hotlink block.

If black variant row uses red image, user misled.

Additional images can help.

Video maybe.

3D model where supported.

But basics first.

Product image is identity.

AI shopping highly visual.

Don't make text overlay cover product.

Don't use generic placeholder.

Feed can be technically valid yet commercially poor.

Quality matters.

GTIN and MPN improve product identity when available

OpenAI-compatible feed docs support GTIN and MPN.

If product genuinely has identifiers, provide.

If no identifier, use proper `identifier_exists` behavior in Google-compatible flow.

Do not invent GTIN.

Fake identifier can merge product incorrectly or fail validation.

For own handmade product without GTIN, state appropriately.

Product identity integrity > filling every field.

Brand also needs consistency.

Same brand spelling across variants.

No “Nike”, “NIKE”, “Nike Official” as brand value.

Normalize.

Categories and attributes help conversational retrieval

Traditional feed categories help classify.

But ChatGPT shopping can respond to natural language like:

“sepatu waterproof buat hiking ringan.”

Attributes:

material.

color.

size.

gender.

age group.

dimensions.

weight.

product category.

variant.

provide richer match.

Ads can benefit because product relevance is easier to understand.

But attributes must be real.

Don't label everything:

premium.

eco.

medical-grade.

orthopedic.

unless substantiated.

Feed is structured claim.

Merchant owns accuracy.

`is_ads_eligible` must be intentional

For Ads processing, OpenAI docs require ads eligibility flag.

Set true only product merchant wants processed for ads.

Not all products must be ads eligible.

Maybe:

restricted product.

low margin.

out of season.

regional only.

stock unstable.

Separate search eligibility, checkout eligibility, ads eligibility.

OpenAI schema has flags for these different functions.

This is powerful.

Also dangerous if default everything true.

Commerce team needs policy.

Which catalog can surface organically?

Which can be purchased in ChatGPT if approved?

Which can be advertised?

Flags should mirror commercial/legal constraints.

Don't treat as technical checkbox.

Ads product feed is not same as organic shopping feed

Base schema overlaps.

But paid eligibility is separate.

A product can be searchable but not ads eligible.

Or ads eligible depending registered feed configuration and program availability.

Reporting also separate.

Organic product discovery.

Sponsored product ad.

Don't call both “ChatGPT product visibility.”

Article 159 distinction applies.

Paid and organic systems separated.

Feed may supply product data to both contexts depending integration flags, but outcome/eligibility should be tracked separately.

Google-compatible feed can reduce integration cost

Merchant with Google Merchant feed may have head start.

OpenAI says if registered feed supports compatibility path, it can ingest compatible delimited product data without renaming all columns.

Formats:

UTF-8 TXT/TSV/CSV and supported compressed variants.

Not every Google program/attribute is supported.

XML, JSON, RSS, spreadsheet aren't automatically part of that compatibility path.

So “kami punya Google feed” not enough.

Check:

format.

fields.

parser.

required values.

currency.

identifiers.

row validation.

Seller identity.

Use OpenAI spec as source.

Don't assume 100% compatibility.

Feed ingestion needs QA report

Every upload should produce metrics:

total rows.

accepted.

rejected.

error reasons.

missing required.

invalid URL.

price error.

identifier error.

availability issue.

variant issue.

Ads eligible count.

Search eligible count.

Don't wait until campaign doesn't show.

Data team should own dashboard.

Catalog errors are campaign readiness issues.

If 10% rejected, which 10%?

Maybe top sellers.

Error percentage alone insufficient.

Weight by revenue/priority.

Prioritize high-value products.

Update strategy: full feed plus deltas

Large catalog doesn't need full upload every minute.

OpenAI commerce docs describe file upload and API paths.

Typical model:

full snapshot daily.

updates throughout day via API.

Depending catalog.

Small feed:
API can handle full plus updates.

Promotions:
API-specific according docs.

Merchant should design:

source-of-truth.

export.

validation.

upload.

delta.

retry.

monitoring.

rollback.

Not manual drag-and-drop forever.

If ads scale, integration should be reliable.

Attribution should be planned before launch

Feed docs mention adding attribution parameters to product URLs when merchant needs feed-specific click tracking.

This is important.

Don't launch then ask:

“Traffic dari feed mana?”

Use UTM or internal tracking.

But separate:

organic shopping.

ads.

campaign.

Feed.

Use supported Ads reporting too.

Don't let tracking parameters change canonical product identity.

Canonical remains clean.

Website handles UTM.

Analytics captures.

This connects commerce data to business outcome.

OAI-AdsBot must reach product landing pages

Even perfect feed won't solve inaccessible destination.

Checklist:

robots allows OAI-AdsBot.

WAF.

CDN.

Cloudflare.

CAPTCHA.

auth.

geo.

rate limit.

redirect.

HTTP 200.

Landing page content matches feed.

Price.

stock.

product title.

If feed says 1.999.000 but page 2.499.000, mismatch.

Product feed and site must share source.

Ideally PIM/ERP drives both.

This reduces drift.

Returns and policy still matter even if not first required fields

Buyer wants confidence.

Shipping.

return.

warranty.

availability.

Merchant should maintain policy on site and commerce integration as supported.

Ads can create purchase intent quickly.

If page hides return policy, conversion quality suffers.

Product data is not only acquisition.

It supports expectation.

Don't optimize click and create returns.

Merchant economics matters.

Start with 100 clean products, not 100.000 dirty ones

For onboarding, smaller high-quality set can be better operationally.

Validate parser.

IDs.

prices.

images.

landing pages.

ads eligibility.

Tracking.

Then expand.

This aligns with user's usual micro-batch instinct: scale after validation.

OpenAI guidance for Ads crawler also notes smaller batches can help avoid rate-limit/bot protection during troubleshooting.

For feed, phased launch makes debugging easier.

Don't push entire catalog if source data not ready.

Production checklist

Merchant identity correct.

Stable IDs.

One variant per row.

Required fields complete.

Titles factual.

Descriptions useful.

URLs public.

Images public.

Price current.

Currency supported/configured.

Availability current.

Identifiers valid.

Variant groups correct.

Attributes normalized.

`is_ads_eligible=true` only intended products.

Feed validation monitored.

Landing pages OAI-AdsBot accessible.

Analytics attribution ready.

Organic vs paid reporting separated.

Update cadence defined.

Owner defined.

This is product feed readiness.

Not just export file.

At the opening, team asks:

“Kita sudah punya Google Merchant feed. Tinggal kirim?”

Jawaban terbaik:

“Kita punya starting point.”

If OpenAI confirms compatibility, many core fields can map.

But the real work is verifying that catalog truth survives the trip.

Product ID.

Title.

Variant.

Price.

Stock.

Brand.

Image.

URL.

Ads eligibility.

All current.

ChatGPT Ads product feed is not a content-marketing hack.

It is structured commerce infrastructure.

The merchant that wins isn't necessarily the one with the longest description.

It's the one whose product data can be trusted enough to answer a shopper's question without inventing, guessing, or sending them to a page where the reality is different.