The product feed guide: fields, formats and how platforms read it

The feed is the least glamorous asset in catalog advertising and the most load-bearing. Every dynamic product ad you have ever run was assembled from one. Get a field wrong and the ad does not underperform, it does not appear at all.

Most teams inherit their feed from a platform export, glance at it once, and never open it again. That is usually fine until it is not: prices drift, images get rejected, whole categories quietly stop serving. This guide walks the feed field by field, format by format, and shows where it tends to break.

If you are earlier than that and still working out what catalog ads are, start with what catalog ads are and why plain feeds underperform.

What a product feed actually is

A product feed is a machine-readable list of everything you sell, expressed in fields a platform agrees to understand. That is all. It is not a design asset and it is not a marketing document. It is a database export with a public URL.

The important consequence: the feed is the platform's copy of your catalog. Meta does not browse your store to build an ad, it reads its own stored copy of your products and assembles from that. When your site and the platform's copy disagree, the platform's copy wins, and it is usually the one that is wrong.

Everything downstream inherits from this file. Product sets, audiences, bidding rules, the ad creative itself. A feed problem never stays a feed problem.

The fields that carry the weight

There are dozens of attributes. A handful decide whether you serve at all.

The identity set

These are the fields you cannot skip:

• id · a unique, stable identifier. Use your SKU. Meta caps it at 100 characters. Never recycle an id across different products.
• title · what the product is. Meta allows 200 characters but recommends staying under 65.
• description · plain text. Meta allows up to 9,999 characters and requires it to differ from the title.
• link · the product page URL, starting with http:// or https://.
• image_link · the product image.
• availability · Meta expects in stock or out of stock.
• price · Meta wants a number, a space, then the ISO currency code: 9.99 USD.

Two cross-platform traps live here. brand is required by Google for new products, with narrow exceptions for movies, books and musical recordings. And condition is required unconditionally by Meta with the values new, refurbished or used, while Google only requires it if the item is used or refurbished. A feed built to Google's rules can be valid at Google and rejected at Meta on that field alone.

Attribute names are snake_case (image_link, not imageLink) and must be in English regardless of the market you sell to. The camelCase versions you may have seen belong to Google's API layer, not the feed spec.

Variants and grouping

Every variant is its own row with its own id. You tie them back together with item_group_id, which tells the platform that the small black shirt and the large black shirt are one product. Get this wrong and a single product competes with itself across every placement.

This is also why SKU counts feel inflated when you first look at a feed. A hundred products with five sizes and four colors is two thousand rows. Grouping is what turns that back into a hundred products.

The fields that decide performance

Not required, but this is where the leverage is:

• sale_price · lets platforms show the strikethrough. Without it a discount is invisible.
• additional_image_link · alternate angles.
• product_type · your own taxonomy, useful for structuring product sets.
• custom_label_0 through custom_label_4 · five free-form slots, 1 to 100 characters each, never shown to customers. Google allows 1,000 unique values per label. Meta supports the same five fields.

Custom labels are the most underused part of the spec. They are how you tag margin band, sell-through rate, seasonality or release year, and then build product sets and bidding rules on top of dimensions the platform has no other way to know.

Feed formats

You have more options than most teams realize, and the choice matters less than the reliability.

XML. The common flavor is RSS 2.0 carrying Google's namespace: <rss xmlns:g="http://base.google.com/ns/1.0" version="2.0">. Meta accepts RSS and Atom XML. XML handles long descriptions and repeated fields like multiple images without the escaping pain that CSV brings.

CSV and TSV. Google accepts tab-delimited .txt and .tsv; Meta accepts CSV and TSV. Easier to open and eyeball, worse at anything containing commas or line breaks.

Google Sheets. A first-class data source at Google. Genuinely useful for small catalogs and for supplemental overrides.

APIs. For anything time-sensitive, a scheduled file fetch is the wrong tool. Meta exposes items_batch, which takes up to 5,000 items per request with a payload ceiling around 28 MB. On the Google side, note that the old Content API for Shopping has been deprecated in favor of the Merchant API, so integration guides written before 2025 are pointing you at the wrong endpoint.

Size limits are generous and rarely the problem: Google accepts up to 4 GB, Meta up to 8 GB and recommends splitting catalogs beyond a million items.

How often the feed refreshes

This is where the theory meets the fact that your prices change.

Meta is explicit: scheduled feeds do not support uploads more frequently than once per hour, with HOURLY, DAILY and WEEKLY as the intervals. Google lets you set a fetch schedule in Merchant Center but does not publish a maximum frequency for standard product feeds, so treat any specific number you read elsewhere with suspicion.

The practical takeaway is that a scheduled fetch is a floor, not a ceiling. If you run flash sales or your stock moves fast, the gap between a price changing on your site and the platform learning about it is measured in hours. That gap is where overspend and angry customers live. Batch APIs exist precisely to close it.

Where feeds break

Four failure modes account for most of it.

Price and availability mismatch

The most common and most damaging. Google compares your feed against your landing page and, when they disagree, applies a preemptive item disapproval. The named issue is "Mismatched product price." It is not a warning, the product stops serving.

The cause is almost always timing rather than a bad value: the feed was accurate when it was generated and stale by the time it was fetched.

Identity gaps

gtin is conditional rather than required, but Google reports "Limited performance due to missing value: GTIN" when it is absent. It is not a disapproval, it is a quiet tax. Products without identifiers match fewer queries.

Image problems

Google's current minimums are 100x100 for non-apparel and 250x250 for apparel. A 500x500 minimum has been announced but enforcement does not begin until January 31, 2027, which means most of what you will read about a 500x500 requirement is describing the future as though it were the present. Accepted formats are broad: JPEG, WebP, PNG, GIF, BMP and TIFF, up to 16 MB.

The rule that catches people out is not about size. Google requires an unobstructed view of the product and disapproves images carrying promotional elements: logos, calls to action, price text, watermarks and borders. The named issue is "Promotional overlay on image [image_link]" and it applies to both Shopping ads and free listings.

Meta takes a different posture. Its catalog image guidance discourages overlay text and time-sensitive information such as temporary price drops, but frames it as delivery quality rather than a hard rejection, and Meta recommends clean or transparent backgrounds specifically so that creative can be composited on top. The result is that the feed image and the ad creative are two different things, and platforms disagree about how far apart they should be.

Structure errors

"Invalid RSS/Atom document format" means your XML is malformed, usually an unescaped ampersand. Cheap to catch, embarrassing to leave running.

The gap the feed cannot close

A correct feed is table stakes. It gets your products eligible, priced right and in the correct product set. What it does not do is make anyone want to click.

The feed carries data. It has no opinion about hierarchy, no brand system, no offer framing, no sense of what a 9:16 placement needs versus a square one. That is a different layer of the problem, and it is the one that actually moves return on ad spend. We wrote about the levers in five ways to lift your catalog ad performance, and what the change looks like in practice in the before and after guide.

FeedForce works on that layer for Meta catalog ads: your brand rules are defined once, then applied across the catalog automatically, so the creative keeps up with a feed that never stops moving. The feed stays your source of truth. The ads stop looking like everyone else's.