Feed rules vs source data: when to transform and when to fix upstream

Rules are one of the most useful tools in feed management because they let teams adapt data without waiting for a full platform release. They can map stock states, build channel-specific titles, normalise values, combine fields and supplement missing channel attributes. That speed is valuable.

The same speed can also create technical debt. A retailer discovers that colour is poor in the source, so a rule fixes it for Google. Then another rule fixes titles. Then a supplemental source holds brand corrections. Six months later the website, Google, Meta and a marketplace each contain a different version of the product because nobody repaired the underlying catalogue.

Google's current Merchant Center terminology is useful here: attribute rules transform product data from one or more data sources, while supplemental data sources can enrich or override existing details. Google's own local guidance also says required attributes should be added directly to the data source for accuracy and data management where practical, with rules used to supplement.

What attribute rules are good at

A channel rule is a sensible tool when the requirement is genuinely channel-specific or when you need a controlled transformation of otherwise reliable data.

• Mapping values: converting an internal stock state into an accepted channel availability value.
• Channel-specific title structure: combining good source fields into a title optimised for Google without changing the customer-facing PDP title.
• Taxonomy mapping: translating an internal product hierarchy into a destination taxonomy.
• Conditional logic: adding a value only for a defined category, brand or market.
• Temporary remediation: stabilising an urgent issue while an upstream fix is being built, provided the temporary rule has an owner and removal plan.

Google's attribute-rules feature supports operations such as setting values, extracting data and applying conditions. It also lets teams test draft rules before applying them. Use those capabilities deliberately rather than treating production data as an experiment.

What usually belongs in source data

If a value is a factual description of the product and should be consistent across the storefront and multiple channels, I normally prefer an upstream fix.

Data	Usually best home	Why
Brand, GTIN, MPN	Source catalogue / PIM / ERP	Core identity should not differ by destination.
Current sell price	Authoritative commerce / pricing source	Every customer-facing channel needs the same commercial truth.
Availability / stock state	Inventory or commerce source	Channel mappings may translate states, but the fact should originate upstream.
Colour, size, material, capacity	Catalogue source	These attributes also power onsite UX, filters and other destinations.
Google-specific title order	Feed / attribute rule	It is an optimisation of good source fields for one destination.
Google product category	Feed mapping or product-data layer	It is destination taxonomy, not necessarily the retailer's customer-facing hierarchy.
Custom labels	Feed / business-data layer	They are channel segmentation tools, often derived from commercial logic.

A decision framework for where a fix should live

I use five questions before adding another rule:

1. Is the value a fact about the product or a presentation choice for one channel?
2. How many destinations need the corrected value?
3. Can the source system represent the value cleanly?
4. How quickly does the business need the fix?
5. Who can own and test the rule after the person who created it leaves?

The answer can legitimately be “rule now, source later”. That is often the commercially sensible choice during a live issue. The important part is that later is recorded as a real backlog item rather than forgotten.

Example: missing brand

If every product from supplier X is missing brand but the supplier file has a reliable manufacturer field, a rule can map it quickly. If the storefront, marketplaces and customer service exports also need brand, the permanent correction belongs where the business creates or ingests that product record.

Example: title optimisation

The ecommerce site may deliberately use “Air Max Dn8” as the PDP title while Google benefits from a constructed title containing brand, product type, gender and colour. That is a good candidate for channel transformation, assuming the component fields are accurate upstream.

Signs that attribute rules have become technical debt

• nobody can explain why a rule exists;
• several rules write to the same target attribute;
• rule order matters but is undocumented;
• the same business logic is copied in several channels;
• temporary static values have been in production for months;
• source teams assume “the feed team fixes that”;
• changes are made directly in Merchant Center with no ticket or release note;
• a new feed platform cannot be launched because no one can reconstruct the transformation logic.

Google notes that attribute rules can cascade, meaning later processing can depend on earlier rules. This is useful, but it also means complexity grows non-linearly when many transformations touch the same data.

How to unwind rule debt without breaking production

Where supplemental data sources fit

A supplemental data source can enrich or override details on products that already exist in a primary source. It cannot act as a standalone source to add or remove products. That makes it useful for controlled enrichment such as additional attributes or business data without rebuilding the primary data flow.

The same architectural discipline applies: if the supplemental source contains a temporary channel enrichment, fine. If it has quietly become the only place your organisation stores accurate product facts, ask whether the data belongs upstream.

Common questions