Feed rules, or fix the source data

Ask whether the corrected value is true everywhere, or true only for Google. Merchant Center gives you both options: data sources are the foundation for submitting product listings, inventory, promotions and reviews, and a rule sits between the source and the processed product.

If a product's colour is recorded as HEX #FF0000 in the source system and Google needs the word Red, that value is wrong everywhere. Your own site search cannot use it, your merchandising team cannot filter on it, and every other channel will need the same patch. Fix the source.

If a product needs a google_product_category id that exists only in Google's taxonomy and appears nowhere else in the business, that is a channel-specific mapping. It has no meaning in the source system, and forcing it in there is how you end up with a products table carrying six vendor-specific columns nobody can explain. A rule, or a supplemental feed, is the correct home.

Most real cases are one of those two, and the argument in the room is usually about the third case: the value is wrong everywhere, but fixing the source needs a sprint from a team with a queue, and the ads are disapproved today. That case is real and a rule is the right answer. The failure is not using the rule. It is never writing down that you did.

The API row is not a detail. Google states that the Data Sources sub-API supports default rules for linking supplemental sources to primary ones, and that complex custom rule creation and management are not supported through the API. Those rules are managed in the Merchant Center interface.

So a rule is, by construction, a manual configuration. It cannot be diffed, it cannot be code reviewed, and it will not be reproduced automatically if the account is rebuilt. Everything you would normally insist on for a transformation, you are giving up. That is fine for two rules and a serious problem at twenty.

The same guide notes a second limit worth knowing before you design around rules: supplemental data sources and rules are not supported through the API for advanced multi-client accounts, and must be managed in the interface. If your structure is an advanced account with sub-accounts, the automation ceiling is lower than you may have assumed.

It helps to know what the rule is actually doing, because people picture it editing their file. It does not.

Google's products guide draws the distinction clearly: a ProductInput is the raw data you submit to a data source, and a Product is the read-only, processed result built from one primary input and zero or more supplemental inputs after all feed rules and processing have been applied.

That means the thing you can inspect in the interface is the output, not your input. When a value looks wrong, the first question is which layer produced it: the source file, a supplemental source, or a rule. Without that discipline you get the classic loop where someone edits the source, sees no change, edits it again, and eventually concludes the feed is broken. A rule was overwriting it the whole time.

Order matters too. Google notes that you can manage the order of supplemental data sources within the default rule, which is what decides precedence when a primary and a supplemental both carry a value. If two supplemental sources disagree, the order is the answer, and it is a setting rather than an accident.

Take a real case. A retailer has 12,000 products. Roughly 900 have a brand value of Generic, which the specification tells you not to submit. A rule that maps Generic to empty takes an hour to write.

Now price the alternative honestly. Fixing it at source means a data cleanup on 900 rows and a validation rule in the product information system so it does not come back. Call that three days of someone's time, plus a change request.

One hour against three days looks decisive. It is not, because the rule is not a one-hour cost. It is one hour plus every future occasion someone has to reason about it: the next migration, the next agency handover, the next time a value looks wrong and somebody spends half a day tracing it. If that happens twice a year for three years, the rule cost more than the cleanup.

The other half of the arithmetic is coverage. The cleanup fixes 900 products for every channel the business sells through. The rule fixes 900 products for one. If the business is on two marketplaces as well, you are going to write the patch three times.

So the honest test is not which is cheaper today. It is whether the defect will recur. A one-off import error is a rule. A validation gap in the source system that will keep producing bad rows is a source fix, and patching it is how you end up maintaining a shadow data model in a vendor's interface.

Channel-specific mappings with no meaning elsewhere. Google product category ids, custom labels used only for campaign segmentation, feed labels.

Emergency stops. A rule that suppresses a category during an incident is exactly the right tool, because you want it live in minutes and gone in days.

Enrichment from a genuinely separate system. If your merchandising team maintains a spreadsheet of campaign priorities that has no home in the catalogue, that belongs in a supplemental source rather than being forced into the product database. Whether it should exist at all is a separate question worth asking.

What I will argue about is the fourth category: rules that exist because the source is wrong and nobody wanted the conversation. Those accumulate silently, and they are the reason a feed that worked for two years breaks catastrophically when the ecommerce platform changes. The rules were the specification and nobody wrote them down.

Write down every rule outside Merchant Center, in whatever the team actually reads. One line each: what it does, why, who asked, and what would let you delete it. A rule with no deletion condition is permanent by default.

Give every rule an owner and a review date. Six months is reasonable. Most of them will turn out to be unnecessary, and deleting a rule is the cheapest cleanup available.

Monitor the file processing result rather than assuming it worked. The file upload status reports a processing state, item counts and the issues encountered, which is enough to alert on. A rule that silently stops matching produces no error, only a slow drift, and that is exactly the failure class behind connectors whose schema changes underneath you.

And keep the count in view. The migration behind the 154-source case note worked because every transformation was inventoried before anything moved. Feed rules are transformations. If nobody can list them, the catalogue cannot be moved safely, which makes them a migration risk rather than a marketing setting.

When the rule count gets past what one person can hold in their head, the answer is not better documentation. It is that the transformation layer belongs somewhere it can be versioned and tested, which is the argument for owning the pipeline rather than renting it.