Merchant Center feed rules: the advanced guide
How to use Merchant Center feed rules to transform product data without touching your source feed, set operations, extractions, find & replace, conditions, and where rules break down.
Feed rules let you rewrite your product data inside Merchant Center, mapping wrongly-named columns, filling blanks, appending brand to titles, without changing the feed your store produces. They're powerful for small surgical fixes, but they're a blunt instrument at scale: no preview across the whole catalog, limited logic, and every rule is another invisible layer someone has to remember exists.
What feed rules actually are
Feed rules are per-attribute transformation pipelines that Merchant Center applies after fetching your primary feed and before processing it. Each target attribute (say title or custom_label_0) gets its own rule made of up to three stages:
- Data sources: where the value comes from: a specific column in your primary feed, a supplemental feed column, a fixed value, or a fallback chain ("use
gtinif set, otherwisebarcode"). - Transformations: operations applied in order: append/prepend, find & replace (with regex support), extract (pull a colour or size out of another field), calculate (numeric operations on price fields), split/choose, clean up (trim, case).
- Conditions: any stage can be gated: if
brand= X andprice> 50, then…
The legitimate use cases
- Column mapping: your export calls it
ean, Google wantsgtin. One data-source rule, done. This is the single best use of feed rules. - Fallback chains:
mpnfrom the primary feed, else from a supplemental feed, else blank. - Cheap conditional labels: set
custom_label_0tosalewhensale_priceexists; margin-band labels from a supplemental feed join. - Emergency surgical fixes: strip a trademark symbol that trips a policy check, blank a systematically-wrong attribute at 6pm on Black Friday. Rules deploy instantly; a rebuilt feed file might take a day.
Deep dive Where feed rules break down
Treat these as hard limits, learned the expensive way:
- No catalog-wide preview. You get a handful of example items per rule. A regex that behaves on the examples and mangles 3,000 long-tail titles ships silently. There is no dry-run against the full catalog.
- Order-sensitivity is invisible. Transformations run top-to-bottom and later rules see earlier rules' output. Two people editing the same attribute's pipeline months apart create emergent behaviour nobody designed.
- Regex dialect is limited: RE2-style: no backreferences, no lookaround. Complex extractions (pulling size out of inconsistent title formats) hit the wall fast.
- Rules are invisible outside Merchant Center. Your feed file says one thing, Google serves another, and the diff lives in a UI nobody screenshots. When performance shifts, rules are the last place anyone looks. Document every rule somewhere your team actually reads.
- They don't fix data, they mask it. A rule that appends brand to titles doesn't make your source data better: every other channel (Meta, Bing, marketplaces) still gets the weak version.
The practical ceiling: 2–5 boring, documented rules (column mappings, a fallback, an emergency patch slot). If your rules tab is doing real data work (building titles, deriving categories, filling identifiers), that logic belongs in a proper enrichment layer where it's versioned, previewable across the whole catalog, and serves every channel, not just Google. That's the job Optimise does: enrichment happens before the feed is served, the output is inspectable per product, and your source platform stays untouched.
Feed rules vs supplemental feeds vs upstream enrichment
| Approach | Best for | Weakness |
|---|---|---|
| Feed rules | Column mapping, fallbacks, emergency patches | No full preview, invisible layer, limited logic |
| Supplemental feeds | Joining corrected data you already have (keyed on id) |
You maintain the side file forever |
| Upstream enrichment | Systematic quality work: titles, categories, identifiers at scale | Requires a feed layer between store and Google |
Most healthy setups converge on: enrichment upstream for quality, one or two feed rules for mapping, supplemental feeds only for data that genuinely lives outside the catalog (margin bands, seasonal flags from a buying spreadsheet).
Frequently asked questions
Do feed rules change my actual feed file?
No. Rules are applied by Merchant Center after it fetches your feed. Your source file is untouched, which also means anyone looking at the source file can't see what Google is actually serving.
What order do transformations run in?
Per attribute, the pipeline is, data sources first (which feed/column supplies the value), then transformations in their listed order (each one's output feeds the next), then modifications like optimisations. Supplemental feed joins happen at the data-source stage, keyed on id.
Feed rules or supplemental feeds, which should I use?
Supplemental feeds when you have the corrected data somewhere (a spreadsheet of GTINs, a file of better titles), you're joining data in. Feed rules when the fix is derivable from data already in the feed (append brand to title, map a column, conditional set). Complex logic belongs upstream in whatever builds your feed.