Supplemental feeds in Merchant Center
How supplemental feeds add and override attributes on top of a primary feed, keyed on id, when to use one, join order, and where an enrichment layer fits.
A supplemental feed adds or overrides a handful of attributes on products that already exist in your primary feed. It never creates products on its own; it joins to the primary feed on id, so a spreadsheet of corrected GTINs or margin labels can patch specific columns without you rebuilding the whole export. Useful for data that genuinely lives outside your catalog, but every supplemental feed is another file someone has to maintain forever.
What a supplemental feed is
A supplemental feed is a secondary data source that adds to or overrides attributes on products that already exist in your primary feed. It is not a standalone catalog: it holds no products of its own. Merchant Center joins it to the primary feed on the id attribute, and for every matching row it applies the columns the supplemental file supplies, leaving every other attribute, and every unmatched product, exactly as the primary feed left it.
The mental model that matters: the primary feed is the base layer; the supplemental feed is a thin patch on top. This is the same shape as any well-behaved enrichment layer: attributes are added or replaced on top of a source, never written back into the source itself.
The join is on id, and only id
Everything hinges on the id (item ID / offer ID) matching between the two feeds:
- A supplemental row whose
idmatches a primary-feed product patches that product. - A supplemental row whose
idmatches nothing is silently ignored: no error, no product created. - A primary-feed product with no matching supplemental row is untouched.
Because the match is exact and case-sensitive, the single most common failure is an id mismatch: a trailing whitespace, a SKU-vs-variant-ID difference, or a store export that changed its ID scheme. When a supplemental feed "does nothing", check the IDs before anything else.
When to reach for one
| Use case | Why a supplemental feed fits |
|---|---|
| Corrected GTINs from a spreadsheet | Data lives outside the catalog; you're joining a known-good column in |
Margin bands / profit labels into custom_label_* |
Comes from a buying or finance sheet, not the store |
| Seasonal or promotional flags | Set on a subset of products for a fixed window |
sale_price from a promotions calendar |
Overrides the primary price on specific IDs |
| Excluding products from a channel | Set excluded_destination on a targeted list |
The common thread: the data genuinely lives somewhere other than your store's catalog. If the value is derivable from data already in the feed, that's a feed rule, not a supplemental feed.
Deep dive Join order, precedence, and the maintenance tax
Merchant Center resolves each attribute through a defined pipeline, and knowing the order is the difference between a clean override and a confusing one:
- Data sources resolve first. For a given attribute, Merchant Center picks the value from its configured source: primary feed, or a supplemental feed if one supplies that column. This is where the
idjoin happens. - Supplemental values override the primary for the attributes they supply. If your primary feed sets
titleand a supplemental feed also setstitleon the sameid, the supplemental value wins. It does not merge or append; it replaces. - Feed rules run on top of the resolved value. A rule that appends brand to
titlesees whichever title survived the supplemental join, not the original primary value. Layering a supplemental override and a feed rule on the same attribute is where "why is this product's title wrong" investigations go to die. - Multiple supplemental feeds attached to one primary apply in the order Merchant Center evaluates them; two supplementals writing the same attribute on the same
idis undefined territory you should never rely on.
The precedence is powerful, but each supplemental feed is a standing liability:
- It's a file someone maintains forever. The margin sheet that fed it last quarter drifts; the GTIN patch stops covering new products the day you add them. Supplemental feeds don't refresh themselves.
- It's invisible from the source file. Your primary export says one thing, Google serves another, and the diff lives in a UI nobody screenshots, which is exactly the problem feed rules have.
- It's Google-only. A GTIN you patched in via supplemental feed still isn't in the data every other channel (Meta, Bing, marketplaces) pulls from. You've fixed the symptom on one surface.
- It scales badly. Two or three targeted supplementals are fine. A dozen, each patching a different corner of the catalog, is a sign the fix belongs upstream where it's versioned and previewable across every product.
The durable pattern: use supplemental feeds only for data that truly originates outside the catalog (margin bands, buying-sheet flags), and push systematic quality work (titles, categories, missing identifiers) into an enrichment layer that runs before the feed is served. That layer produces the served feed non-destructively: it adds and overrides attributes on top of your source data, your store's catalog stays untouched, and the result is inspectable per product rather than buried in a side file. See how enrichment works.
Supplemental feed vs feed rule vs enrichment
| Approach | Best for | Weakness |
|---|---|---|
| Supplemental feed | Joining corrected data you already have, keyed on id |
You maintain the side file forever; Google-only |
| Feed rule | Fixes derivable from data already in the feed | No full-catalog preview, limited logic |
| Upstream enrichment | Systematic quality at scale: titles, categories, identifiers | Requires a feed layer between store and Google |
Most healthy setups converge on the same split: enrichment upstream for quality, a feed rule or two for column mapping, and supplemental feeds reserved for data that genuinely lives outside the catalog. If your supplemental feeds are doing the heavy lifting of feed quality, that work wants to move upstream. See how enrichment works.
Frequently asked questions
Can a supplemental feed add new products?
No. A supplemental feed only touches products that already exist in your primary feed. Any id in the supplemental file that doesn't match a primary-feed id is ignored; there's no product to attach the data to.
What happens if the same attribute is set in both feeds?
The supplemental feed wins for the attributes it supplies. That's the point; it overrides the primary value for those specific columns, on those specific products, and leaves everything else untouched.
Supplemental feed or feed rule, which do I use?
A supplemental feed when the corrected data already exists somewhere (a file of GTINs, a sheet of margin bands); you're joining data in. A feed rule when the fix is derivable from data already in the feed. See the feed-rules guide for the full split.