Explore 2025 product feed specs for Google, Meta, and OpenAI. Learn required fields, formats, and best practices to build a unified feed that powers better ads and creative.
If you work in ecommerce long enough, “product feeds” stop feeling technical and start feeling personal. When something looks wrong in your Google Shopping ads or a product goes missing from Instagram, it is almost always the feed. Now we are adding a new player into that mix: OpenAI’s product feed for ChatGPT.
The good news is that all three major destinations, Google, Meta, and OpenAI, want the same thing at the core. They all need a clean, structured, always-fresh description of what you sell. The differences are in the details: how often they expect updates, which attributes are required, and what they do with that data once they ingest it.
This article walks through the specs at a practical level so you can plan a single, coherent feed strategy that works across Google, Meta, and OpenAI, and sets you up for better creative and better performance.
Why Product Feed Specs Matter More Than Ever
On Google, Shopping ads are generated from your Merchant Center product data, not from the keywords in your campaigns. Your bids and structure matter, but the system decides what to show and when based on the attributes you send it in the feed.
Meta works the same way. Catalog ads and Shops rely on the fields in Commerce Manager. The required attributes look simple on paper, but any mismatch or missing value can quietly pull products out of rotation.
OpenAI is pushing that logic even further. ChatGPT uses your feed to decide which products to surface inside conversational search and now, with Instant Checkout, which products someone can actually buy inside the chat itself.
Underneath all of that is the same pressure: ecommerce is still growing quickly. Global ecommerce is expected to reach tens of trillions of dollars in annual sales and already accounts for more than a fifth of total retail in some markets. Personalization then amplifies the stakes. A large share of consumers say they are more likely to buy when product recommendations feel tailored, and many brands are now treating real time product data as a strategic asset rather than just plumbing.
If your product feed is the language you speak to these platforms, the spec is the grammar. Get the grammar wrong and the best creative and budget can’t save you. Get it right and tools like Marpipe can actually use that structure to build better catalog ads, smarter templates, and stronger testing across channels.
Google Merchant Center and Meta Commerce Manager
Diving Into Each Major Platform: Product Feed Specs
Google Product Feed Specs for Merchant Center and Shopping
Google’s product feed lives in Merchant Center and powers Shopping ads, Performance Max, free listings, and more. Google maintains a detailed “Product data specification” that spells out exactly how each attribute should be formatted.
At the core, Google expects a set of standard attributes for every product. You will recognize most of them from any marketplace:
In every row you are essentially telling Google: “This is the product ID, here is the title, here is what it costs, here is where to buy it, here is the main image, here is whether it is in stock, and here is which brand or identifier it belongs to.” That usually means fields like id, title, description, link, image_link, price, availability, condition, brand, and either gtin or mpn.
On top of those basics, Google strongly encourages you to fill out:
Category and taxonomy fields like google_product_category and product_type, which help Google understand where to place and compare you.
Variant structure using item_group_id, color, size, and related attributes for apparel and other multi-variant products.
Local and regional attributes such as local availability and local price if you run Local Inventory Ads.
From a format perspective, Google accepts text or XML feeds and supports scheduled fetches, uploads, and API based updates. Most retailers push a daily feed, although some verticals update more frequently, especially if pricing or inventory moves quickly.
Two things matter most in practice:
First, Google Shopping ads and Performance Max campaigns are only as good as your feed. Google’s own documentation repeats this point: Shopping ads are generated from your Merchant Center data, which means your optimization work should start with titles, descriptions, and attributes.
Second, you need consistency between what is in the feed and what is on the landing page. If price, availability, or identifiers do not match, you will see disapprovals and lost impressions.
Meta’s own spec and third party documentation agree on a set of required fields for most catalog surfaces. For Shops, Instagram Shopping, and typical catalog ads, the required attributes are: id, title, description, availability, condition, price, link, image_link, and at least one of brand, mpn, or gtin. Marketplace and some Page shop use cases also require inventory and google_product_category.
Everything else layers on top of that. You can add optional attributes such as additional images, sale prices and sale windows, gender, age group, color, size, pattern, and material. Those fields are not strictly required to sync products into Meta, but they become very important when you want to build product sets, filter your catalog, or design creative that reflects specific attributes.
Meta also defines extra attributes for:
Checkout on Facebook and Instagram, which requires fields like quantity_to_sell_on_facebook and sometimes size details in certain categories.
Region specific compliance, especially for selling in India.
Vertical specific feeds for travel, vehicles, and property, each of which introduces its own set of fields.
Like Google, Meta accepts CSV, TSV, XML, or similar formats and allows you to schedule fetches or upload files. You can also connect catalog feeds directly from platforms like Shopify, BigCommerce, or feed management tools.
From a marketer’s standpoint, the important part is how closely Meta ties these attributes to catalog ads. When you run dynamic product ads or catalog campaigns, Meta uses fields such as price, availability, product_type, and google_product_category to decide which product to show in which format. If those values are missing or inconsistent, you end up with mismatched creative, irrelevant retargeting, or products that never leave the “processing” stage.
For Marpipe users, Meta’s spec is where feed quality starts to directly affect creative quality. If your catalog has clear product types, consistent naming, and thoughtful variants, Marpipe can generate more precise templates and introduce creative logic like “show review stars when product_review_rating is above 4.5” or “highlight discount badges only when sale_price is present.” That is nearly impossible to do cleanly if the underlying feed is messy.
At a high level, the OpenAI spec follows a familiar flow.
Merchants apply at chatgpt.com/merchants and, once approved, receive a secure HTTPS endpoint and authentication details. They then format their catalog according to the Product Feed Spec, using one of the supported file formats, which currently include TSV, CSV, XML, and JSON. OpenAI ingests that feed, validates each record, and indexes the data so ChatGPT can retrieve, rank, and display products in response to user queries.
Refresh expectations are more aggressive than most legacy catalog systems. The spec is designed to accept updates as frequently as every fifteen minutes, so things like pricing, inventory, and availability stay close to real time.
The process typically starts with an initial load or sample feed. That early push lets OpenAI validate parsing and structure before you turn on regular updates. From there, it becomes a straightforward push model where your system sends updates to the agreed endpoint over encrypted HTTPS.
Flags and core identifiers
OpenAI’s spec introduces a pair of explicit control flags: enable_search and enable_checkout. These are lower case enum style fields that tell ChatGPT whether a product can appear in search at all and, if it does, whether it can be purchased via Instant Checkout. enable_checkout only works when enable_search is set to true, which gives you a clean way to limit which SKUs can be bought inside ChatGPT.
The basic product identity fields will feel familiar:
You define a stable id for each product, ideally a SKU or internal product identifier that does not change over time. Global identifiers such as gtin remain recommended and help with matching, while mpn becomes required whenever a GTIN is missing. Titles, descriptions, and a canonical product link round out the basic data set, with length limits that are generous enough for full product copy but still optimized for on-platform presentation.
Item information, media, and merchandising
Beyond the basics, the OpenAI spec groups fields by category.
Item information covers essentials such as condition, product_category, brand, material, physical dimensions, weight, and age group. These fields support classification and relevance. They also provide hooks for ChatGPT to answer more nuanced questions, like “find a waterproof hiking boot under $150 for adults with wide feet.”
Media fields include the usual image_link and additional_image_link attributes, plus optional video_link and model_3d_link. That last one is notable, since it explicitly anticipates richer 3D or AR experiences, rather than treating them as out of band content.
Pricing and promotional attributes look similar to what you see on Google and Meta: a required price, optional sale_price, a sale_price_effective_date window, and unit based pricing when relevant. Availability and inventory are broken out in a detailed way, with fields for availability, availability_date for preorders, inventory_quantity, expiration dates, and pickup options that define whether items can be collected in store.
Variants are handled through an item_group_id that matches your own parent product structure. The spec then lets you differentiate variants with fields such as color, size, size_system, gender, and custom variant dimensions. This is a familiar pattern for teams that have already done the work for Google and Meta, with the added expectation that the group ID reflects how you present the product on your own site.
Fulfillment and merchant information fields describe shipping methods, costs, and delivery estimates, along with seller_name, seller_url, and policy URLs for privacy and terms. When Instant Checkout is enabled, policy URLs become required so buyers can see clear terms without leaving the ChatGPT interface.
Returns, reviews, and performance signals
OpenAI’s spec also gives you space for signals that most marketers have wanted in feed specs for years.
Returns can be defined with a return_policy URL and a return_window in days, which helps ChatGPT answer questions about whether an item is “easy to return” without scraping your site. Performance related fields allow you to include metrics such as popularity_score and return_rate, which in turn can inform ranking and surfacing. Review attributes such as product_review_count, product_review_rating, store_review_count, and store_review_rating give the system structured insight into social proof.
There is even room for Q&A content and raw review payloads, which brings unstructured sentiment into a more structured schema.
Compliance fields capture warnings, age restrictions, and other regulatory flags. Related product attributes like related_product_id and relationship_type open up cross sell and recommendation logic. Geo tagging fields such as geo_price and geo_availability let you express region specific pricing and stock without building separate regional feeds.
Finally, OpenAI maintains a prohibited products policy that defines which products can and cannot be listed. That policy is as important as the schema itself, since it determines whether your category is even eligible to surface or transact inside ChatGPT.
Comparing Google, Meta, and OpenAI feed specs
If you step back from the individual fields, a pattern emerges.
All three platforms require a shared core: a unique product ID, a clear title and description, a canonical URL, a main image, price, availability, condition, and at least one brand or identifier field. If any of those are missing or formatted incorrectly, you will run into disapprovals or silent failures on every platform.
Google and Meta both lean heavily on taxonomies. Google pushes you toward google_product_category and product_type, while Meta often expects at least a Google or Facebook product category for Marketplace and some Shop use cases. OpenAI includes a product_category field but puts more emphasis on broader object level understanding, since ChatGPT can blend feed data with other knowledge sources.
Update frequency is another key difference. Google historically expects at least updates when values change and a full refresh at least every thirty days, although most serious advertisers push daily feeds. Meta tends to follow your chosen schedule, which can range from a daily automatic import to more frequent pushes if your inventory changes quickly. OpenAI, on the other hand, is optimized for near real time, with a spec that explicitly supports updates as often as every fifteen minutes.
The most striking contrast is what sits on top of the core schema.
Google and Meta focus primarily on fields that improve ad relevance and creative rendering. They care deeply about attributes that drive matching, like identifiers, categories, and text fields, and about attributes that drive compliance and user expectations, like price, condition, and availability.
OpenAI uses many of those same fields but adds levers that are specifically designed for conversational shopping. Flags such as enable_search and enable_checkout, explicit popularity and review metrics, Q&A, geo specific overrides, and support for 3D models all reflect a world where a model is deciding what to show inside a conversation, not just inside a carousel.
Building a Multi-Platform Feed Strategy
The real question is how to handle all of this without creating three separate, fragile exports.
The most scalable pattern is to design a “master” feed schema that covers the union of what you need for OpenAI, Google, and Meta, then map down from that master into each platform’s specific requirements. In practice, that means:
You treat OpenAI’s spec as a superset for structured product data, because it already captures richer concepts like reviews, returns, and geo overrides. You then ensure that every product in your master feed has clean core attributes that map to Google’s and Meta’s required fields. When you export into Merchant Center or Commerce Manager, you drop fields those platforms do not care about and transform the remaining values so they match each spec.
You also commit to a shared set of standards across all three:
Stable, unique IDs that never change.
Consistent naming conventions and title patterns.
A single source of truth for price, availability, and inventory.
Clear rules for variants and grouping.
A dedicated feed management layer makes this significantly easier. That might be a home built export process or a specialized tool. From a Marpipe perspective, the same clean master feed that keeps Google and Meta happy also unlocks more precise creative automation. When you have structured attributes for category, audience, reviews, and performance, you can do meaningful things with creative logic: build catalog templates that look different for high AOV products, swap copy for products with strong review counts, or test entirely different layouts for specific categories.
We have covered that relationship between feed quality and creative performance in more depth in our pieces on AI powered creative testing, product feed management best practices, and the importance of data hygiene for dynamic ads on the Marpipe blog. Those articles go deeper into how teams structure feeds to support catalog ads at scale, how they identify and fix data issues, and how creative testing sits on top of that work.
Treat Your Product Feed as a Core Infrastructure
If you are managing feeds today, the arrival of OpenAI’s product feed does not mean starting over. It means tightening what you already have and thinking of your feed as a shared foundation across Google, Meta, and ChatGPT rather than three separate tactical exports.
The steps are straightforward:
Audit your existing Google and Meta feeds against their official specs. Fix the basics first. Then, look at the OpenAI Product Feed Specification and decide what it would take to extend your current schema to meet that standard, even if you are not integrated with ChatGPT yet. Once you have a unified view of product data, bring creative into the conversation. Ask what your paid social and performance teams would do differently if they had cleaner fields for category, audience, reviews, and returns.
That is where platforms like Marpipe start to feel less like a “nice to have” creative tool and more like part of your feed infrastructure. The better your feeds are, the more your creative can reflect what actually matters in your catalog, across Google, Meta, and whatever comes next.
Marpipe’s built-in feed management and enrichment tools
Frequently Asked Questions
1. Do I need separate product feeds for Google, Meta, and OpenAI? You don't need three separate feeds, but you do need three separate outputs. The best way to do this is to create a single master schema that includes all of the main properties and then map those fields into the format that each platform needs. ID, title, price, availability, and product URLs are all basic fields that Google, Meta, and OpenAI all have in common. OpenAI's spec is the most complete, thus a lot of teams take it as their internal baseline and then change it to fit Google or Meta.
2. How often should I update product feeds across these platforms? Google and Meta both accept scheduled updates, most commonly daily, but they also expect updates whenever price or availability changes. OpenAI’s spec is built for more frequentupdates and supports refreshes every fifteen minutes. If you have rapid inventory turnover or frequent flash sales, syncing more often will help your performance and prevent disapprovals or out-of-stock problems across all platforms.
3. What happens if my product feed has missing or inconsistent data? Missing fields can cause hidden problems even before you see an error message. On Google, incomplete or mismatched values often lead to disapprovals or low impression share. On Meta, missing brand, GTIN, or variant attributes limit which products can appear in Shops or catalog ads. On OpenAI, incomplete data reduces the likelihood of your product surfacing in conversational search. The most important thing for catalog performance is having clean, consistent data.
4. Which fields matter most for improving creative and ad performance? Adding structured attributes like category, brand, material, color, and variant details make your catalog more flexible for creative automation. Platforms like Marpipe leverage those fields to build rule-based templates, apply dynamic overlays, highlight reviews or discounts, and test product sets in a more meaningful way. The more complete your feed is, the richer and more accurate your creative output becomes across Google, Meta, and ChatGPT.
5. How do I prepare for OpenAI’s Product Feed Specification if I’m not integrated yet? An internal audit is the easiest place to start. Look at your Google and Meta feeds right now and compare them to the OpenAI schema. Find any missing properties, such as structured reviews, returns, custom variants, or availability in certain areas. Even if you don't provide data to OpenAI right now, making sure your catalog matches the spec will make it easier for you to use conversational commerce, find better product matches, and make your creative work more adaptable when you're ready to integrate.
Boost ad performance in days with a 7 day free trial.
.png)
