Skip to content

Product Feed Optimization · focused work

Supplemental feeds for Merchant Center

A supplemental source adds or overrides attributes on products that already exist in a primary feed. It cannot create a product and it cannot remove one. It joins on the product identifier and changes only the fields it carries, which makes it the safest way to improve feed data when the store platform cannot produce the value itself.

This is the right work if

  • The store's feed app cannot express the title, category or exclusion rule the account needs
  • Margin, stock cover or seasonality data lives outside the store and never reaches the feed
  • A subset of products needs excluding from one destination but not from the account
  • Identifiers exist in a supplier file that the store platform has nowhere to store
  • A title or category change needs testing on part of the catalog before it is built into the store

What it is

What a supplemental source is for

Merchant Center calls these supplemental data sources, and older documentation calls them supplemental feeds. Either way the mechanism is the same: a second file or connection whose rows are matched to the primary feed by the product identifier, adding attributes that were missing or replacing ones that were wrong. Typical uses are overriding titles built by a rule the store's feed app cannot express, adding custom labels computed from margin or stock data that never leaves the accounting system, filling identifiers that exist only in a supplier file, setting promotion identifiers, correcting a category assignment, or excluding a subset of products from one destination while leaving them live everywhere else.

The risk is that they turn into an undocumented layer. Several sources can apply to the same primary feed, so when two of them set the same attribute the order decides which wins, and a value nobody refreshes becomes a permanent override that outlives the reason it was created. The governance is therefore part of the work: a name that says what each source does, an owner, a stated reason, a refresh schedule and a review date. And a rule of thumb, which is that a value the store platform should own belongs back in the store, with a supplemental source used for what the platform genuinely cannot hold or for testing before a permanent change.

How it is done

The work, in order

What changes

  • Feed data can be corrected without waiting on a change to the store
  • Business data such as margin and stock cover reaches campaign structure
  • Every override has an owner, a reason and a review date
  • Changes are tested on part of the catalog before being built permanently
  1. Check the identifier joins exactly

    The match is on the product identifier and it is unforgiving about case, whitespace and prefixes added by a feed app. Export a sample from the primary feed and compare it against the intended source before uploading anything, because unmatched rows are ignored rather than reported as errors.

  2. Decide what belongs here and what does not

    Values the store should own go back into the store, where merchandisers can see them. Reserve the supplemental source for data the platform cannot hold, for values computed from systems outside it, and for changes you intend to test before committing.

  3. Build the right kind of source

    Use a spreadsheet when a person maintains the values, and a hosted file fetched on a schedule when a system generates them. Set the fetch frequency to match how quickly the underlying data changes rather than to the maximum the interface allows.

  4. Carry only the columns you mean to change

    Include the identifier and the attributes being set, nothing else. An extra column copied from a template will silently overwrite good data across the catalog, and it is difficult to notice because the products remain approved and live.

  5. Record the order and the ownership

    Where more than one source touches the same attribute, write down which one takes precedence, who owns each, and why it exists. This document is what makes the setup maintainable by whoever inherits the account.

  6. Review on a schedule and retire

    Check every source each quarter. Remove overrides whose reason has passed, and move anything permanent back into the store data. Supplemental sources are meant to be a working layer, not a second copy of the catalog nobody dares to touch.

Platform notes

Shopify

Metafields are often the better home for a value a merchandiser maintains, since the feed app can map them, leaving supplemental sources for data that comes from systems outside the store entirely.

WooCommerce

Custom fields can be exported into the feed by most plugins, so the practical question is whether the value is edited by a person in the store admin or generated elsewhere, which decides where it should live.

Questions

Supplemental feeds questions

By CartKernel · Last reviewed

Can a supplemental source add products the primary feed does not contain?

No. Rows whose identifier does not exist in the primary feed are ignored, which is a safety feature rather than a limitation. Adding products means changing the primary source, and anything that looks like a missing product is nearly always an identifier that does not match.

What happens when two sources set the same attribute?

One of them wins according to the order the sources are applied, and the result is deterministic but not obvious from looking at either file. This is the main reason the setup needs documenting, since a debugging session on a mystery value can otherwise take longer than the change did.

Is a spreadsheet safe for a large catalog?

It works, and it becomes fragile as the number of rows grows and as more people edit it. Once a source is large or business critical, generating a hosted file from the system that owns the data removes the human step and makes failures visible in a log.

Should overrides eventually move into the store data?

Yes, for anything permanent. An override is invisible to everyone who works in the store admin, so a title or category that is now considered correct should be corrected at the source. Keeping it in a supplemental source guarantees somebody will eventually be confused by the difference.

Related work and answers

Product Feed OptimizationProduct feed title optimizationProduct feed title optimization: a pattern per category built from real queries, generated from product attributes, kept in policy and measured properly.OpenProduct Feed OptimizationCustom labels for Google ShoppingCustom labels for Google Shopping: five fields defined once, computed from margin, stock and velocity data, and used to split budgets and targets by band.OpenMerchant CenterMerchant Center diagnosticsMerchant Center diagnostics: triaging item issues by revenue at risk, grouping by cause, reproducing what the crawler sees, and fixing at the source.OpenMerchant CenterMerchant Center setupMerchant Center setup: business details, website claiming, shipping and returns, a product data source on the right schedule, and the links that follow.OpenAnswerHow often should a product feed update?Match feed refresh frequency to how fast price and stock change. Daily fetch as a floor, real-time updates for volatile catalogues, and how to spot staleness.OpenAnswerDo you need GTINs for Google Shopping?Google requires a GTIN whenever the manufacturer assigned one. What to submit for products that genuinely have none, and how to keep codes clean.OpenAnswerCan one Merchant Center account serve multiple stores?A Merchant Center account is built around one verified website, so multiple stores usually need sub-accounts under an advanced account. When each model fits.OpenAnswerShould shipping be set in Merchant Center or the feed?Set shipping in Merchant Center for the catalogue and use the feed attribute for exceptions. How rate tables, shipping labels and delivery times fit together.Open

Find the leak.

A free Growth Analysis ranks what your store should fix first, by revenue at stake.