Managing Feed Quality — Exclusions and Validation

Introduction

A product feed doesn't get better the more items you cram into it. Let an unpublished product slip in, or one missing a required field, and Google Merchant Center (GMC for short — the console where you register product information with Google) disapproves it at review.

What makes disapprovals awkward is that no warning appears. The count of listed products in the console just drifts downward, so by the time you notice, several hundred items may have dropped out of circulation. Tracing "traffic from Shopping has fallen off lately" back to a stack of accumulated disapprovals is a common story.

This article covers how we keep products that shouldn't be listed out of the feed, and what we check before handing anything to Google. It's about the quality of the feed rather than its size.

Keeping products that shouldn't be listed out

Drafts and unpublished products end up counted as broken links

An EC site's product data always contains drafts that haven't gone live and products deliberately kept private. If those slip into the feed, Google visits the product page and arrives at a page that doesn't exist.

The result is a disapproval — and specifically the "broken link" kind, which affects how much your account is trusted. Let enough of them accumulate and it starts to matter at the account level. So we check each product's publication status and drop anything that isn't live at the point the feed is built. The only things in the feed should be products that are published and can be bought right now. Enforcing that is step one of quality management.

Finer control using stock levels and tags

Published-versus-unpublished isn't always enough. Products that have been out of stock for a long time, products already scheduled for discontinuation, pre-order-only items, products carrying a particular operational tag. There are more "we could list it, but we'd rather not right now" cases than you'd expect.

This is where building the feed yourself pays off. You can look at a product's tags and stock status and set conditions that follow the commercial judgement behind them. A dedicated app only lets you choose from the options it ships with. Handling something like "exclude only products that carry this tag and have zero stock" is the kind of thing that comes free when the feed is yours.

Over-excluding costs you just as much

Add too many exclusion conditions, though, and you start losing listing opportunities outright. Drop every low-stock product because it feels safer and the listed count comes in far below what you expected — which leaves you in much the same place as a pile of disapprovals would.

So we made a habit of checking how many products each new condition removes. With "this condition drops N items" written down, you can weigh the reason for excluding against what it costs. Out-of-stock products with restock dates, for instance, are often better left listed, so deciding per product type beats applying one blanket rule.

Make the exclusion conditions switchable from settings

Exclusion rules often need to differ by site or environment. In a test environment you might want drafts included so you can check how they render, while production excludes them strictly. Run several sites and the range of products each one lists will differ too.

Put another way, the conditions become dials you can turn later. With that in place, an operational request like "list out-of-stock items on this site only" is handled without touching the mechanism at all.

Checking the data before you hand it over

Most disapprovals come from a missing required field

Line up the reasons for disapproval and most of them turn out to be mundane. The price was empty. The image URL didn't resolve. The identification number had the wrong number of digits. Gaps that small are enough for a product to be rejected the moment GMC receives it.

The first four stop the listing outright; the last one still lists but performs poorly. Splitting them that way makes it easier to decide what to fix first.

The important part is catching these before the feed goes out, rather than learning about them once GMC has already disapproved the product. Spot a gap while the feed is being built and you can fix it before any listing stops.

Send every gap to both "exclude" and "get it fixed"

When a gap turns up there are two responses. One is to drop that product from the feed so only complete records get listed. The other is to tell whoever owns the data what's missing, so the source record gets corrected.

The second half is the point: don't stop at excluding, follow through to the fix.

Run on exclusion alone and the source data never improves, so those products keep losing listing opportunities indefinitely. Run both — drop it for now, but get it corrected — and the number of listable products grows over time.

Learning the review rules as you operate

Products can fail review even with every field filled

Even with all required fields complete, a product runs into disapproval if it touches GMC's listing policies. Items in restricted categories, product names containing claims that read as exaggerated, and images with large text overlaid are the usual examples.

Mechanical checks won't catch all of these. Where policy interpretation is involved, some human judgement is always left in the loop.

Read the disapproval report and fold it back into the rules

So we check the disapproval report in the GMC console regularly. It breaks the counts down by reason, which lets us work from the most frequent reasons downward and fold each one back into the rules that build the feed.

If disapprovals caused by product naming keep appearing, we change how the name is assembled for that product group. If a particular category keeps failing, we exclude that category from the start. Reason by reason, the disapprovals go away. It feels less like fixing a bug and more like raising the quality of the feed as you run it.

Summary

Feed quality management stands on two things: controlling what never goes in, and checking what does before it leaves.

• Exclusion control: reliably drop drafts and unpublished products, then refine using stock levels and tags
• Conditions live in configuration: adjust per site and per environment without touching the mechanism
• Required-field checks: find the gaps while the feed is being built, before anything gets disapproved
• Exclude and follow up: protect the listing today while the source data gets corrected

These checks only work because mapping design has already settled what goes into each field. Delivering the finished feed day after day is covered in caching and health checks, and the whole flow is laid out in automated product feeds.