Supplemental feeds, done right: patching a primary feed without breaking it

A supplemental feed in Google Merchant Center is one of the most useful and most misused tools in the feed toolbox. Done right, it lets you fix or enrich specific fields without touching your source of truth. Done wrong, it becomes a shadow primary feed that fights the real one and leaves you debugging which value won. The difference is entirely about discipline.

What it actually is

A supplemental feed does not stand alone. It is keyed by id to your primary feed and overrides or adds only the fields it contains, leaving everything else untouched. Think of it as a patch: same product IDs, a handful of columns, applied on top of the primary. If a product is not in the primary, the supplemental cannot conjure it; it can only modify what is already there.

The jobs it is perfect for

Use it when you need to change a narrow slice without rewriting your export. Adding custom_label values for campaign segmentation. Overriding bad or generic titles for Shopping specifically, while leaving your storefront titles alone. Correctinggoogle_product_category on a problem set. Adding promotional IDs. Excluding a subset of products. All of these are targeted edits to specific fields on specific products, which is exactly what a supplemental feed is built for.

The trap: turning it into a second primary

The misuse is loading a supplemental feed with most of the catalog and most of the fields, so it effectively becomes a competing primary. Now two feeds claim authority over the same data, the resolution rules are subtle, and a wrong value in either one is a hunt to track down. The symptom is a product showing a value that appears in neither feed you were looking at, because you were looking at the wrong one. Keep the supplemental narrow and it stays a patch; let it sprawl and it becomes a conflict.

The rules that keep it clean

Override only what you must, never re-state fields the primary already gets right. Keep one supplemental feed per clear purpose rather than one giant catch-all, so each has an obvious owner and reason. Document what each one overrides, because future-you will not remember. And make sure every row keys to a real id in the primary; orphan rows that match nothing are silent dead weight that makes the whole setup look more complicated than it is.

The deeper principle

A supplemental feed is a layering tool, and layering only helps when each layer has a single, clear job. The moment a layer tries to do everything, you have not added flexibility, you have added a second place for the truth to live, and two sources of truth is just zero sources of truth with extra steps. Patch narrowly, or do not patch at all.

The plug

SnowPipe treats overrides as exactly that, scoped, documented edits on top of one canonical product, so you get the flexibility of supplemental data without the two-feeds-fighting problem. It is at pipe.snowforge.dev.