Product Feed Management: Which Merchant Center Alerts Actually Block Sales

Search "product feed management" and you mostly get software. Five vendors on the first page, each with a dashboard that counts your Merchant Center issues and a promise to bring the number down. The number is real. What the number means is a separate question, and auditing five live accounts is a way to answer it.

On July 30, 2026 we audited five live Merchant Center accounts, pulling every open product issue on each. 7,170 products scanned, 822 of them carrying at least one issue, 1,133 issue rows in total. Of those 1,133 rows, 42 were stopping a product from appearing in Shopping ads or free listings. The rest were demoted, cosmetic, scoped to a surface the account does not buy, or sitting in Google's own review queue waiting on nobody.

That gap between the alert count and the 42 is the actual management job, and nothing about it is specific to these five catalogs. Here is how the 1,133 breaks down, and the four numbers any brand can run a feed program on instead.

What five live accounts are alerting on

These are live client catalogs, anonymized to vertical and size. The scan caps at 2,000 products per account, so A and B are partial reads and their real catalogs are larger. Issue rows run ahead of products with issues because one product can carry several.

Account C looks like the emergency: 627 rows against 1,089 products, more alerts than the two accounts twice its size put together. Hold that thought, because C turns out to be the clearest case of an alert count describing something other than what it appears to describe.

Four tiers, and the alarming word is the wrong one

Every issue row carries a severity and a serving consequence. Across all 1,133 rows the two lined up perfectly, with no exceptions in either direction:

Two labels land on disapproved, and telling them apart is the one distinction in this whole dataset worth memorizing. Google's Merchant API reference carries a second field alongside severity, called resolution, with two values. MERCHANT_ACTION means "The merchant has to fix the issue." PENDING_PROCESSING means "The issue will be resolved automatically (for example, image crawl) or through a Google review. No merchant action is required now."

Split the 1,133 rows on that field and they come apart cleanly: 1,025 are MERCHANT_ACTION and 108 are PENDING_PROCESSING. The 108 are the same 108 rows carrying the severity label "error." Every one of them. Across five accounts and nineteen distinct issue codes, the tier named after something going wrong is the tier where nothing is wrong and nobody has anything to do.

One row in ten is waiting on Google

107 of those 108 are attribute_pending_review, which is Google looking at a product image. The API detail text says so directly: Google may take up to five days to review it. The last row is an initial policy review on a newly added product. None of it is a defect, none of it has an owner, and all of it clears itself.

Account B makes the point best. It returned 16 issue rows, 10 of them pending review. Anyone opening that dashboard sees a list where the majority of what is on screen is Google thinking, presented at error severity with a disapproved status beside it. Work that list top to bottom and most of your time goes to rows that would have cleared on their own by Friday.

This is the first thing to strip out of a feed report before anyone reads it. The filter is trivial, it removes about a tenth of the noise, and it is the difference between a queue and a feed.

The demoted tier has no column in most dashboards

205 rows sit at warning severity, and Google's definition of that tier is precise: the issue "demotes the product in all reporting contexts it affects." The product serves. It appears. It ranks below the products that filled the field in, on every surface, until somebody fills it in.

All 205 are one code, missing_item_attribute_for_product_type, concentrated in the sporting goods and performance apparel accounts. Google decides which attributes matter for a given product category, notices they are absent, and quietly ranks the product down rather than pulling it.

A dashboard built on approved versus disapproved has nowhere to put this. The product is approved. It sits inside the approved count, inside the approval rate, and the approval rate went up when it was added. 18 percent of everything we found lives in a tier most feed reporting has no row for, and it is the tier where the revenue effect is continuous rather than binary.

Disapproved without a surface is not a number

409 rows read as disapproved. Google's definition of that word: the issue "disapproves the product in at least one reporting context." At least one, of seven.

Every issue row names the surfaces it affects. Filter the 409 down to rows touching Shopping ads or free listings, the two surfaces carrying most of what these clients sell, and 409 becomes 42.

Account C is the one to sit with. 310 disapproved rows, 4 of which touch the surfaces that account sells on. 226 of its critical rows are two Demand Gen and Video policy codes, flagging creative eligibility on surfaces the account is not buying. Its Shopping presence is close to intact and its dashboard is on fire.

Account D runs the other way. 48 disapproved rows, 31 of them blocking Shopping ads and free listings, mostly products missing a required attribute outright. D carries a third of C's alert volume and roughly eight times the real problem. Sorting those two accounts by alert count puts them in the wrong order.

Where the fix actually lives

The other half of managing a feed is knowing who fixes what. We tagged all 1,133 rows by where the change has to be made:

The largest single bucket is the source system, and it is one code: 313 products flagged ambiguous_gtin, meaning the identifier is populated and Google does not believe it. No feed rule fixes that, because the value has to be corrected where it is authored. We covered why a populated identifier can still be wrong in our piece on required and optional feed attributes.

The feed layer, where a feed management tool operates, holds 21.9 percent of the work. That is a real fifth of it and worth automating well. It also sets the honest expectation for what a tool changes on its own. Photography cannot be re-rendered by a mapping rule, a policy flag needs a merchandising decision, and a broken landing page is a website ticket. Buying a feed tool to clear a Merchant Center queue is buying the right instrument for one bucket in eight.

The four numbers we manage a feed on

None of this requires a tool to see. It requires the issue list, the resolution field, and the surface list, all of which arrive on the same API call. What we keep month to month:

• Blocking rows on surfaces you sell on. Filter to disapproved, then filter to the reporting contexts carrying your revenue. This is the number costing money today, and across the five accounts in this audit it was 42 out of 1,133.
• Demoted product count, as a share of catalog. The tier that never shows up in an approval rate. Trend it down and rankings improve without buying a single new impression.
• Merchant-action rows per thousand products. Strip PENDING_PROCESSING and the status notices first, since both move for reasons nobody controls and both make the trend line lie.
• Rows by owner. Route them: source system, merchandising, feed layer, photography, website. A backlog with no owner column is a backlog that sits.

Run those four and the monthly conversation moves from how many alerts are open to which team has the most revenue parked in its column. That is a question somebody can answer.

Where to start

Pull your own issue list and make three passes at it. Drop every row whose resolution is PENDING_PROCESSING. Split what is left by whether the affected surfaces include the ones you sell on. Then tag each remaining row with the team that owns the fix.

Across the five accounts we audited that took 1,133 rows down to 42 urgent ones, 205 quiet ones costing rank every day, and a routing table showing most of the remaining work belongs to teams outside the feed entirely. The count that mattered was two orders of magnitude smaller than the count on the dashboard, and it pointed at a different account.

The part that does not compress this way is the optional attribute block, where the work is a small research problem repeated once per SKU. That is what our Merchant Center enrichment service handles: agents that ground each value in a real source on your own site, validate it, and publish through a supplemental feed with a human approving every batch. The same mechanism is how we handle price competitiveness and the six conversational attributes that AI shopping assistants read.

Want this read on your own catalog? Book a call and we will send back your four numbers.