---
title: "Merchant Center Feed Rules: Steps, Examples and Fixes"
description: "Merchant Center feed rules, now called attribute rules, fix product data while Google processes it. Setup steps, copyable examples, fixes and what to automate."
canonical: "https://www.productmetrics.io/blog/merchant-center-feed-rules"
pageType: article
language: en
publisher: "Product Metrics"
author: "Berend Vrakking"
datePublished: 2026-11-05
dateModified: 2026-11-05
image: "https://www.productmetrics.io/og/blog/merchant-center-feed-rules.png"
---

> Content index: https://www.productmetrics.io/llms.txt

# Merchant Center Feed Rules: Steps, Examples and Fixes

## Key takeaways

- Feed rules need Google's Advanced data source management add-on and run top to bottom, so mapping comes before clean-up and scoped defaults come last.
- A rule can fix how a value is written, never whether it is true: a wrong brand or a missing GTIN goes back to the source.
- Labels built on margin, stock or POAS go stale unless their inputs update; keep formatting in feed rules and feed changing labels from live data.

Merchant Center feed rules are transformations [Google Merchant Center](https://www.productmetrics.io/glossary/google-merchant-center "Google Merchant Center (GMC) is a free Google tool where a shop uploads and manages its product data, so its products can appear on Google Shopping and across Google.") applies to your product data during processing, without touching your source file. Google now calls them attribute rules.

I use them to make correct data readable to Google, and that is their limit: a rule fixes how a value is written, not whether it is true. Every operation and limit here comes from Google's Merchant Center Help, read on 5 November 2026.

## What are Merchant Center feed rules?

Merchant Center feed rules, renamed attribute rules, are ordered instructions that change product attributes during processing. They map unrecognised headers, clean up values, fill gaps under a condition and assign [custom labels](https://www.productmetrics.io/glossary/custom-labels).

You turn them on with the **Advanced data source management** add-on (Settings, Add-ons, Discover). Then open **Data sources**, pick a primary product source and go to its **Attribute rules** tab.

Older guides say "feeds" and "feed rules" for the same screens.

Google's [attribute rules documentation](https://support.google.com/merchants/answer/7450276?hl=e) splits the operations into two groups: ones that choose where a value comes from, and ones that modify it.

| Operation | What it does | Limit |
|---|---|---|
| Set to | Takes a column, another attribute or fixed text | Fails only if every reference fails |
| Set to multiple | Sets several destination values | Included and excluded destinations, Shopping ads excluded countries |
| Extract | Pulls a pattern out of text | Needs a dependable pattern |
| Take latest | Uses the most recently updated source | Price and availability only |
| Find & Replace | Swaps one value for another | Runs in sequence, not all at once |
| Prepend, Append | Adds text before or after | Fails only if every source reference fails |
| Calculate, Split & Choose | Computes or splits values | Check the result on real products |
| Clear | Empties the attribute | No later rule touches that product |

### What can a feed rule not fix?

A feed rule cannot make a wrong fact right. Mapping `brand_name` to `brand` tells Google where the brand lives, but it can't correct a wrong name in that column.

Keep core product facts in the source: identity, description, images and manufacturer data. A rule that hides a source error only adds a dependency for the next person auditing the feed.

### Who owns a feed rule?

The harder problem in most accounts isn't a missing attribute; it's ownership.

A product you discounted yesterday still sits in a high-margin campaign, and nobody knows whether the shop export, a [supplemental feed](https://www.productmetrics.io/glossary/supplemental-feed "A Google Merchant Center supplemental feed is a secondary data source that adds details to, or overrides details in, the products of your primary feed.") or an old rule wrote that label. Treat rules as maintained production logic with an owner, not fixes you save and forget.

## How do you create a feed rule in Merchant Center?

You create a feed rule on a primary data source's Attribute rules tab: add a rule for one attribute, save it as a draft, test it, apply it and reprocess the source.

Prepare first, because testing only shows the products you think to check.

| Before you start | Why |
|---|---|
| Edit access to the right data source | A rule on the wrong source never touches the attribute |
| A sample of products | Covers in- and out-of-stock items, variants and every country you sell in |
| The system that owns the attribute | Shop, [PIM](https://www.productmetrics.io/glossary/pim "A product information management (PIM) system is software for maintaining and enriching product information so teams can publish consistent details across sales channels."), supplemental feed or an existing rule |
| The current configuration and output | Your rollback if the new rule misfires |
| A named reviewer | Someone checks the rule when its inputs change |

**Create and test a feed rule in Merchant Center**

1. **Check the current value.** Find the attribute on the primary source and note both its submitted and its processed value, so you know where the discrepancy starts.
2. **Write the rule as one sentence.** For example: when brand is empty, set brand to the brand_name column. It keeps the source column, the target attribute and any fixed text apart.
3. **Pick the operation.** Set to for a mapping or fixed value, Find & Replace for value clean-up, Extract for a text pattern, Take latest for price or availability from several sources.
4. **Limit it with a condition.** Target a verified ID list or an exact source value, not every product. Broad matches do the most damage on condition, brand and country-specific rules.
5. **Save as draft, then Test rules.** Step through awkward variants, missing inputs and products that must stay unchanged in the draft value preview.
6. **Apply, reprocess and read diagnostics.** Apply changes, reprocess the data source and check the processed products and item-level issues. A saved rule only proves the rule saved.
7. **Log the change.** Record the date, purpose, owner, condition and expected result, plus the event that should trigger a review, such as a supplier switch.

### Why does rule order matter?

Rule order matters because Google runs attribute rules in cascade: the first rule runs, then the second reads its result, and so on. The safe order is **map headers first, normalise values second, apply scoped defaults last**.

![Diagram of one product row through three Merchant Center attribute rules: brand mapped from brand_name, gender F normalised to female, condition set to new only for IDs on a verified list](https://www.productmetrics.io/images/blog/merchant-center-feed-rules/merchant-center-attribute-rules-order.webp)

_Each rule reads the output of the rule before it. Put the scoped default last, so a missing value stays visible until the rules that should fill it have run._

The reason is the gap. A default placed first fills `condition` before you learn the source never sent it.

A stock rule that runs before availability mapping reads the raw text, not the cleaned value. When a label looks wrong, trace the value at the point where that rule runs, not only in the final product record.

The test that matters most is on the products a rule must leave alone, not only the ones it should repair.

A costly slip is saving a rule against a supplemental source when the input belongs to the primary source: confirm which source supplies the attribute before you debug the condition.

## Feed rule examples you can copy

These patterns are starting points, not configurations to paste unchecked. Each one assumes you've looked at the raw values first.

| Goal | Operation | Input | Output |
|---|---|---|---|
| Map an unrecognised header | Set to | `brand_name` column | `brand` |
| Standardise gender codes | Find & Replace, or Set to with a condition | `F` or `Female` | `female` |
| Pull size from a title | Extract | `Trail Jacket - Size M` | `size` = `M` |
| Prefer the fresher price | Take latest | Primary feed and a price supplemental feed | Price from the most recently updated source |
| Set condition for new stock | Set to, scoped to an ID list | Warehouse list of new IDs | `condition` = `new` |
| Clean availability text | Find & Replace | `In Stock!` | `in_stock` |

### Normalise codes with a condition, not a default

Say a fashion shop receives `F`, `M` and `Female` in its gender column. Map `F` and `Female` to `female` and handle `M` explicitly. A product-wide `female` default would erase valid differences instead of cleaning them.

### Extract only from a dependable pattern

Extract works when every title follows the same pattern. Test it on the messiest titles in the feed: punctuation, missing size markers, bundles. If the formats differ much, a structured size column beats ever more complicated title parsing.

### Take latest compares sources, not column names

Take latest picks whichever data source updated price or availability most recently; Google limits it to those two attributes.

It can't tell that a `price_2026` column is newer than `price_2025` in the same file. If your export carries both, point Set to at the right column, or fix the export.

### Don't manufacture missing product facts

Google's [local product-data specification](https://support.google.com/merchants/answer/14779112?hl=en) requires brand for new products, except movies, books and musical recordings, and [GTIN](https://www.productmetrics.io/glossary/gtin "A GTIN (Global Trade Item Number) is a unique number that identifies a product that can be priced, ordered or invoiced, usually shown as a barcode.") for new products that have one assigned by the manufacturer.

The same page warns against using your store name as the brand unless you make the product. Scope brand-fill rules to that, and get assigned GTINs from the manufacturer rather than inventing them.

`condition` is required for used and refurbished products, so a blanket `new` default on a mixed range describes some products wrongly. Scope it to a verified ID list.

For enrichment at the source, the guide to [Shopify catalog improvements with ECORN](https://www.ecorn.agency/blog/product-data-enrichment) covers the upstream work, and Google's [product categories](https://www.productmetrics.io/blog/google-shopping-category) need the same care: they're more than another text clean-up.

## How do custom labels work with feed rules?

Custom labels are five optional attributes, `custom_label_0` to `custom_label_4`, that Google never shows to shoppers and that you use to split products in [Performance Max](https://www.productmetrics.io/glossary/performance-max "Performance Max is a goal-based Google Ads campaign type that uses automation to reach customers across Google advertising channels."), Shopping and Demand Gen campaigns.

Google's [custom label specification](https://support.google.com/merchants/answer/6324473?hl=en-GB) allows one value per product per field, 1–100 characters, and up to 1,000 unique values per field across the account. Values beyond that are ignored for reporting and bidding.

![Table of one product's five custom labels: segment stars and category priority high from a supplemental feed, season, price band and launch year from feed rules, with Google's per-field limits](https://www.productmetrics.io/images/blog/merchant-center-feed-rules/merchant-center-custom-labels-five-fields.webp)

_Give each field one kind of value and one owner. Stable facts such as season or price band suit feed rules; segments that move with performance come from a supplemental feed._

Spend a field only on a split someone will use to set campaign priorities. Fix its vocabulary before anyone writes to it: `high_margin`, `low_stock`, `star_candidate`.

Google treats label values as not case sensitive, but `high-margin` and `high_margin` are still two values in two product groups.

### Why do commercial labels go stale?

A margin or stock label is only as current as the data behind it. Feed rules reapply on every processing run, but margin, returns and stock cover usually live outside the feed.

At Product Metrics, Product Rules run after segmentation and write labels to a Merchant Center supplemental feed.

For example, the **Promote Star candidates** rule sets `custom_label_0` to `star_candidate` when POAS is at least 1.4, margin at least 40% and stock cover over 8 weeks. That rule is only right while its inputs are.

A discount changes the margin, a delivery changes stock cover and ad results change POAS, so reapplying a saved condition to stale inputs doesn't help.

When a product's segment changes, its label changes and Merchant Center merges it on the next fetch (06:30 in our setup). The product then moves to whichever campaign or asset group your team split on that label.

### Check the campaign impact before you publish

Tightening a threshold can empty the campaign it feeds. Preview the split before changing the logic, and decide what happens to a product that stops qualifying.

| Check | What to confirm |
|---|---|
| Input freshness | Margin, returns and stock reflect today, not last month's export |
| Exit behaviour | An old value is replaced or removed when a product stops qualifying |
| Campaign coverage | Qualifying products have a home, and so does everything else |

Doing these checks by hand works for a short product list. Across a full range, the labels that drive your priorities need to come from data that updates itself.

> **Get more revenue out of Google Shopping.** Every product segmented and labelled in Merchant Center, so your top performers get more priority. [Analyse your products for free](https://app.productmetrics.io/) Log in with Google, no credit card.

## Why do feed rules break, and how do you fix them?

A feed rule that worked yesterday and fails today usually means its input changed, not the rule: a renamed header, new stock wording or a supplemental source that stopped updating.

Start from the symptom and inspect the raw input before you edit the rule again.

| Symptom | Likely cause | Fix |
|---|---|---|
| Attribute shows as unrecognised | Source header never mapped | Add a Set to rule for that header |
| Value rejected | Unsupported value, such as `Brand new` for condition | Normalise to `new` before dependent rules run |
| Attribute ignored in an XML feed | Google namespace prefix missing | Add the `g:` prefix and its namespace declaration |
| Products disappear after an export change | Exporter sent only changed items to a full-file source | Send the complete product file again |
| In-stock items show out of stock | Stale supplemental availability, or wrong rule order | Check source update dates; run the stock rule after mapping |
| Used items show as new | Unscoped default | Scope the default to a verified ID list |

### Diagnose output that's valid but commercially wrong

Some failures never produce an error. A feed can process cleanly while its labels describe yesterday's stock or last week's price.

Compare the freshness of the supplemental and primary sources first. If a supplemental source overwrites current availability with an older value, the stock label is valid and wrong.

Google's guide to [supplemental feeds and feed rules](https://developers.google.com/shopping-content/guides/products/supplemental-feeds/using-feed-rules) shows how each supplemental feed, such as one for price and one for availability, can carry its own rule set, and notes that rules can only be created in Merchant Center, not through the Content API.

Check your [product feed sync schedules](https://www.productmetrics.io/blog/google-product-feeds) against your fetch and processing history.

### Keep a regression sample and stable IDs

Keep a fixed sample of products in a spreadsheet: out-of-stock items, regional differences and variants. After every material edit, compare expected and processed output, then read the item-level diagnostics once processing finishes.

Keep IDs identical across sources. A supplemental row with a different ID never matches its product, so the rule's input was never there.

For the errors Merchant Center does report, the [Merchant Center errors guide](https://www.productmetrics.io/blog/google-merchant-center-errors) traces each one back to its source.

## Which rules should stay manual, and which should you automate?

Keep stable formatting rules in Merchant Center and automate labels built on changing commercial data. Header mapping rarely changes; labels built on margin, returns and stock need fresh inputs every day.

| Criterion | Manual feed rules | Automated labels |
|---|---|---|
| Who writes the logic | Your team, rule by rule | Product Rules on top of segmentation |
| What updates a label | A person edits the rule; processing reapplies it | A segment change, merged on the next fetch |
| Who sets prices | Your team | Your team; Product Metrics never changes prices |
| Best fit | Stable mappings and clean-up | Margin, returns and stock that change often |
| Audit trail | The change log you keep | Labels traceable to segments and rule conditions |
| Setup | Low per rule, rising as rules multiply | Log in, choose ROAS or POAS, add a supplemental feed once |

Feed rules already run automatically, so automation isn't about execution. It's about who keeps the inputs fresh and who checks that a label still supports the campaign decision.

With [Product Segmentation](https://www.productmetrics.io/product-segmentation), labels reach Merchant Center through one supplemental feed, with no feed rules to maintain, while your team still chooses the logic and the campaign priorities.

### Hand over one label at a time

List every custom label you maintain by hand and mark those driven by margin or stock. Pick one, write the automated version to a spare field and compare the two before you remove the manual one.

The spare field keeps the two approaches from overwriting each other. Investigate disagreements, confirm the campaign routing and name an owner before you switch. Automation removes the rule maintenance, not the responsibility for the decision.

## Final thoughts

The most useful habit with feed rules is boring: write down what each rule reads, what it writes and when its assumptions expire. Formatting rules belong close to the feed; commercial labels belong close to the data that decides them.

Once the feed is clean, the work moves to campaigns and the shop.

If you're also building acquisition campaigns, SimpleLab Digital's guide on [how to create Google search campaigns](https://www.simplelabdigital.com/blog/7-steps-on-how-to-create-a-successful-search-ads-campaign-on-google) covers that separate workflow; just don't use campaign changes to compensate for product data you haven't validated.

And a clean feed only gets shoppers to the product page. Magic Genie's guide to [turning store traffic into more sales](https://magicgenie.ai/blog/e-commerce-marketing-strategies) covers the merchandising and conversion work a better feed supports but can't replace.

## Frequently asked questions

### How quickly does a new feed rule reach my products?

A feed rule takes effect when the data source is next processed. Google's help says to reprocess the source after you apply changes; until then the products keep their old processed values, so check a few items once processing finishes.

### Can a feed rule take products out of Shopping ads?

Yes. The Set to multiple operation can set the included destination, the excluded destination and the excluded countries for Shopping ads. Scope it with a condition, or one rule can remove far more products than you meant.

### What happens if a rule clears a required attribute?

Once Clear runs on a product, Google applies no further rules to it. If the cleared attribute is required, such as an image link or a price, the product can be disapproved, so test Clear on a sample first.

## Keep reading.

- [Custom Label Intelligence: Segment, Bid, and Measure Granularity In Google Shopping](https://www.productmetrics.io/blog/custom-labels-google-shopping)
- [Google Shopping APIs: Merchant API Guide for 2026](https://www.productmetrics.io/blog/google-shopping-apis)
- [Product feed management software: 10 options for 2026](https://www.productmetrics.io/blog/product-feed-management-software)

---

Written by Berend Vrakking, founder of Product Metrics. Last updated 2026-11-05.

1M+ products analysed · Nominated at the Dutch Search Awards for Best Measurement Campaign (2023) and Best Use of Data (2024)

HTML version: https://www.productmetrics.io/blog/merchant-center-feed-rules