Product Feed Rules for Merchant Center

Product feed rules are transformations that help submitted data match Merchant Center’s product-data requirements. Google now describes this capability as attribute rules: rules can transform or combine values from product data sources so Google can interpret the result. A safe rule changes only the intended attribute, for the intended product population, using an owned source and a reviewable condition.

This is an educational guide, not a promise that any rule will resolve a disapproval or improve performance. Start with product feed optimization, Google Shopping feed optimization, and supplemental feeds for the wider data path. Do not use a rule to invent product facts, conceal missing inventory, alter prices without authority, or make campaign decisions that belong to another workflow.

Define the rule contract before editing data

Write the expected outcome in one sentence. Examples include “fill a missing material value from the catalog attribute for apparel products,” “normalize a controlled brand spelling,” or “map an approved internal product type to the corresponding field.” The contract should name the account, source, market, language, product population, target attribute, permitted operations, owner, reviewer, and evidence required for acceptance.

A rule is not justified because it is possible in the interface. It is justified when the current data fails a known requirement or consistency contract and the proposed transformation is supported by an authoritative source. If the source is incomplete, the correct result may be a visible unresolved issue rather than a guessed value.

Record the current value, proposed value, matching key, condition, source priority, effective date, expiry or review date, and rollback value. Keep the rule’s scope separate from campaign settings, bids, budgets, customer data, and landing-page copy. A product-data transformation should not quietly become a general automation permission.

Separate source fields from derived values

Treat a catalog field, a primary feed field, a supplemental field, structured data, and a derived value as different evidence classes. A derived value may be useful for formatting, but it should not be represented as a manufacturer identifier, medical claim, certification, or other fact unless the source actually supports it. Label derivations so an owner can tell what was supplied and what was transformed.

Choose primary and supplemental sources deliberately

The source model determines what a rule is allowed to do. Google’s product data source guidance distinguishes primary sources, which add or remove products and provide core targeting data, from supplemental sources that enrich or update existing products. A rule should respect that ownership instead of treating every field as interchangeable.

Create a source map before writing conditions:

Define what happens when two sources disagree. Precedence should be explicit by attribute and population. A supplemental value can be authoritative for one field while the catalog remains authoritative for another. Do not use a broad fallback that fills a missing value with a different product’s value or with a marketing phrase.

Use stable matching keys

Match supplemental data with a stable product ID, item group, or other key defined by the source contract. Check case, whitespace, market, language, and variant scope. A key that joins at the parent product level can incorrectly give every variant the same size, color, availability, or price. Preserve the input key and the matched row in the audit record.

Build conditions that describe the intended population

Start with an inclusion statement: “Apply to products where field A is empty, field B is an approved value, market is C, and source freshness is within the owner’s contract.” Then define the exclusion cases. Conditions should be understandable to a reviewer who did not create them.

Use controlled values for categories, brands, materials, colors, and other enumerations. Normalize only the differences that the owner has documented, such as capitalization or a known punctuation convention. Do not strip words indiscriminately from titles or descriptions; a word that looks promotional in one catalog can be an important product fact in another.

A good condition is narrow enough to test. If its population is “all products,” ask whether every product has the same evidence and business meaning. If not, split the rule by product family, market, or source owner. Smaller scope makes the output easier to review and reduces accidental changes when a new category enters the catalog.

Keep missing data visible

Do not convert missing information into a plausible default. An empty material is not automatically “Other,” an unknown brand is not automatically the store name, and a missing availability value is not “in stock.” If a field is required and no authoritative source exists, expose the missing-data issue and route it to the catalog owner.

Set precedence and avoid rule collisions

A rule set needs a documented order. State whether the process takes the submitted value first, then a supplemental value, then an approved derivation, or follows another owner-approved sequence. Include the conditions under which a later rule can replace an earlier value. “Last rule wins” is not a useful policy unless the ordering itself is versioned and reviewed.

Check collisions across titles, descriptions, product type, Google product category, identifiers, availability, price, shipping, and custom labels. Two rules can be individually reasonable but contradictory in sequence. For example, a title rule might remove a brand token that a later matching condition expects, or an availability rule might overwrite a regional state with an online state.

Use a rule inventory containing name, purpose, owner, source, target attribute, condition, precedence, markets, languages, effective time, status, test population, last review, and rollback procedure. Retire a rule when its source contract ends. An inactive rule that remains undocumented is a future collision.

Test rules before applying them to the full catalog

Use a representative but explicitly defined test set: products with complete values, missing values, existing values that must be preserved, multiple variants, bundles, international markets, special characters, and known edge cases. The set should be derived from the rule’s actual population and risk, not selected merely because it is convenient.

Compare before and after values field by field. Count additions, replacements, unchanged rows, empty outputs, invalid values, unmatched keys, and products outside the intended population. Inspect real examples, especially the first and last values in a normalized string. A passing row count cannot prove that the values are correct.

Verify landing-page agreement

For customer-visible attributes, compare the output with the exact landing page and selected variant. Google’s product data optimization guidance emphasizes current product data and consistency with the landing page. A title rule cannot justify a claim that the page does not make, and a price or availability transformation must not hide a checkout mismatch.

Test a product that has a disabled option, a changed price, a regional restriction, and a recently updated catalog record. If the rule is not permitted to alter those fields, assert that they remain unchanged. Keep the test result and reviewer decision with the rule version.

Monitor processing and diagnose failures

After saving or applying a rule, review the processed source, affected item count, diagnostics, warnings, disapprovals, and unmatched or invalid values. Separate a rule syntax problem from a source freshness problem and from a landing-page problem. The same symptom can have different owners.

Record a run ID, source version, rule version, population, market, language, start and finish times, output summary, diagnostic reference, and verification result. If processing is partial, say which products were not evaluated. Do not call a rule successful because the interface accepted it; success requires the output to meet the rule contract and remain consistent with the offer.

When a rule causes unexpected results, stop or roll back the smallest authorized change. Preserve the before state and affected IDs. Do not delete the only evidence of the failed run. If a current value is already correct, prefer a no-op over replacing it with a derived value merely because the rule can do so.

Review common product feed rule mistakes

The most damaging mistakes are usually scope and ownership errors:

• Treating a feed rule as a way to invent facts or repair an unavailable source.
• Applying an account-wide transformation to products with different markets or variant grains.
• Using a supplemental key that does not preserve the exact product and item group.
• Overwriting a valid catalog value because a derived value is easier to compute.
• Removing important title details while trying to normalize promotional text.
• Using out_of_stock to hide an available product instead of reviewing destination controls.
• Changing price, shipping, availability, or landing-page claims without the responsible owner.
• Ignoring the processed result and relying only on a saved-rule confirmation.
• Leaving an old rule active after the source or taxonomy has changed.

The correction is not always another rule. It may be a catalog fix, a source update, a key correction, a page change, or a documented decision that the product should remain unresolved until evidence exists.

Establish a reviewable rule lifecycle

Use a small lifecycle: proposed, tested, approved, active, monitored, paused, retired. The state should identify the owner and the evidence that moved it forward. A rule can be technically valid but not approved for production because its source, market scope, or business impact is unclear.

At each review, ask whether the target attribute still has the same meaning, whether source precedence is still valid, whether new product families are entering scope, whether the landing-page renderer changed, and whether diagnostics show a new failure mode. Review frequency should come from the source owner’s change risk and platform requirements; do not invent a universal interval.

Product feed rules are complete when each transformation has an explicit contract, a trustworthy source, narrow conditions, documented precedence, tested output, visible diagnostics, an owner, and a rollback path. The strongest rule set is not the one with the most clever expressions. It is the one a different operator can explain, verify, and safely stop when the evidence no longer supports the output.