feedsmerchant-centerproduct-data

Supplemental feeds: enrich product data without forking the primary feed

Add labels, titles and identifiers through supplemental feeds without replacing the primary catalog or increasing its blast radius.

The short version

Keep your commerce platform or feed tool in charge of the primary feed. Add campaign labels, improved titles, missing identifiers and other targeted corrections through a supplemental source keyed to the same product IDs.

That gives each change a small blast radius, a clear owner and a clean rollback. It does not remove the need for feed-to-page-to-checkout parity: an override must still describe the product shoppers actually see.

Use a supplemental source for enrichment, not reinvention

A primary feed carries the complete offer: identity, title, description, price, availability, URLs, images and market context. Rebuilding that feed just to add a few attributes means taking ownership of every field, refresh and platform rule the original generator already handles.

A supplemental source is narrower. It matches existing products by ID and adds or overrides only the attributes it contains. It cannot create a missing product, and it should not become a second complete catalog.

Use one when you need to:

  • add custom_label_0–custom_label_4 for campaign segmentation;
  • fill verified GTINs, MPNs or brands missing from the primary source;
  • test more useful titles on a controlled product set;
  • add promotion or seasonal attributes with an expiry date;
  • correct a destination-specific field while the source-system fix is being scheduled;
  • apply a reversible merchandising experiment.

Do not use one to hide a broken primary feed, invent availability, or publish a price that differs from the landing page or checkout.

Keep the primary feed owned by its generator

The system that creates the primary feed usually knows about variants, market prices, stock, redirects and platform-specific formatting. A fork must reimplement all of that and then keep pace with store changes.

That creates three avoidable risks:

  1. Large blast radius. One malformed fork can remove or corrupt the whole catalog.
  2. Silent drift. The fork falls behind new variants, markets, fields or plugin behavior.
  3. Unclear ownership. Operations fixes the store, marketing fixes the fork, and neither surface reliably matches the other.

Leave the primary in place. Make the smallest possible supplemental change and keep the rule that generated it beside the feed pipeline.

Design the supplemental source at offer-ID grain

The join key is the contract. Use the exact product ID expected by the destination, including any channel, language, country or feed-label context that is part of the processed offer identity.

Do not join on SKU alone when the same SKU can produce several market or variant instances. Before upload:

  1. Export the destination's current processed product IDs.
  2. Match the proposed enrichment to those IDs.
  3. Count matched, unmatched and duplicate rows.
  4. Stop if the match rate is lower than expected.
  5. Keep the pre-change extract as the rollback baseline.

A supplemental row with the wrong ID does nothing. A row matched to the wrong variant can confidently publish the wrong title, label or identifier.

Split changes by purpose and owner

Do not turn one supplemental file into an ungoverned patch drawer. Separate changes when they have different owners, refresh schedules or rollback conditions.

A practical structure is:

Source Carries Refresh Owner Rollback trigger
Campaign labels Margin, season, experiment labels Daily Paid media Segment membership is wrong
Identifier fills Verified GTIN, MPN, brand Weekly Catalog ops Identifier mismatch appears
Title test Controlled title overrides Daily Merchandising Eligibility or conversion degrades
Promotion layer Sale labels and dates Hourly or daily Trading Promotion ends or prices diverge

Each source should have a short field allowlist. If the campaign-label file unexpectedly contains price or availability, reject it before upload.

Make experiments reversible

A supplemental source is useful because it can be removed independently. Preserve that advantage.

For every change, record:

  • the product population and exact IDs;
  • the original and replacement values;
  • the calculation or editorial rule;
  • the owner and effective date;
  • the metric or defect the change is meant to improve;
  • the verification condition;
  • the rollback condition and expiry date.

Start with a small, commercially meaningful sample. Do not judge a title or identifier test from file acceptance alone; inspect processed products, item issues, eligibility and serving after the platform applies it.

Protect parity after every override

Platforms compare feed claims with rendered pages and checkout. A supplemental source can therefore create the same parity failures as a primary feed.

Check the trio for a value-weighted sample:

  1. Feed instance: the processed value after primary and supplemental sources combine.
  2. Rendered page: visible product facts and structured data for the exact variant.
  3. Checkout: final price, currency, availability and purchasable variant.

Pay special attention to sale-price windows, market-specific currency, parent-versus-variant URLs, GTIN and brand pairs, and stock that changes faster than the supplemental refresh.

An enriched title should remain recognizably true on the page. A corrected identifier must belong to the exact rendered variant. A campaign label may be invisible to shoppers, but its source rule still needs a reproducible business definition.

Deploy in a controlled sequence

Use this release order:

  1. Inventory every primary, supplemental and API-written source already touching the catalog.
  2. Define the target products, fields and expected match count.
  3. Build a file containing only the ID and approved enrichment fields.
  4. Validate IDs, duplicates, lengths, formats and allowed values.
  5. Upload a small sample or limited source first where the platform permits it.
  6. Confirm the platform combined the sources as expected.
  7. Inspect item-level diagnostics and the exact products used by campaigns.
  8. Compare feed, page and checkout for high-value variants.
  9. Expand only after the acceptance checks pass.
  10. Save the successful extract, diagnostics and membership counts as the baseline.

Run the free product feed scanner before upload. Then verify the processed products inside the destination platform; a valid file proves syntax, not correct matching or serving.

Know when to fix the source instead

A supplemental source is a layer, not permanent permission to avoid root causes. Move the change into the primary source when it becomes universal, stable and owned by catalog operations.

Good candidates for a source-system fix include a consistently wrong brand, a missing identifier that is now verified for the full catalog, or a title rule that has completed testing and should apply everywhere.

Keep destination-specific campaign labels and short-lived experiments supplemental. Promote durable product truth upstream so every channel receives the same fact.

Sources