This morning Merchant Center shows 260 disapproved products. Yesterday there were 12. The number 260 on its own will not show you the change, though, until you have something to compare it with.
On a catalog of 80,000 products, 260 disapprovals is an ordinary swing. On a smaller catalog, the same number means part of the range is down, and revenue with it. Without a comparison with the previous day, you cannot tell a swing from an outage.
I will show you what Merchant Center watches on its own and which four signals are worth watching on top of that. At the end you will find a public script that watches them for you.
What Merchant Center shows you on its own
The product overview shows product status and a history chart. According to the Merchant Center Help, the chart helps you understand changes in product status over a selected period. Looking back, you can find in it when disapprovals started to pile up.
Merchant Center splits issues by level. Account-level issues appear in a banner at the top of the account. All product-level issues are on the "Needs attention" tab.
Some of the information also lands in your inbox. According to the Merchant Center Help on issues, Google sends a warning email with examples of issues that need fixing. It also tells you about an account suspension by email.
How many extra disapprovals are a reason for alarm depends on your catalog size. You set the alarm threshold yourself, in a script on top of the Merchant API that compares today's status with the previous day.
4 signals for when the built-in report is not enough
The script watches four signals at once, and each of them catches a different type of problem. The thresholds for the signals are examples. You set them differently for a small and a large catalog.
1. Absolute increase
The first signal fires when disapproved products grow by more than a fixed number versus the previous day, for example 10. An absolute threshold suits mainly a small catalog. On a catalog of 500 items, relative change jumps even without a cause: a few extra disapprovals and the percentage shoots up, although nothing broke in the feed.
On a large catalog, 10 products are noise. There, raise the absolute threshold according to catalog size.
2. Relative increase
The second signal tracks the percentage versus the previous day, for example from 20%. Some set 10%, others 30%. On a catalog of 80,000 products, 10 extra disapprovals are noise, 2,000 are not. The percentage, however, is calculated from yesterday's number of disapproved products, not from catalog size. With 12 disapproved yesterday and 260 today, the catalog from the introduction would trigger an alert, although it is an ordinary swing. So set the relative threshold according to how many disapproved products you usually have on a normal day.
The relative signal has a weak spot where few products were disapproved yesterday. Alerts then arrive even without a cause, on a small catalog and a large one alike.
3. New disapproval reason
The third signal compares reasons instead of products. It fires for every reason in the item_issues field that was not in the previous day's output. That way it catches a broken attribute or a policy action before it shows up in the counts.
This signal needs no threshold. It is enough that the reason was missing from yesterday's output and is there today, even on just a few products.
4. Share of the catalog
The last signal watches the share of disapproved products in the whole catalog, for example above 5% of the range. It works as a backstop for slow growth. The first three signals stay silent when disapprovals grow every day in batches below the threshold and the reasons stay the same. The share of the catalog shows that trend over time.
| Signal | Example threshold | What it catches | When it fails |
|---|---|---|---|
| Absolute increase | for example +10 products a day | a jump on a small catalog | reports noise on a large catalog |
| Relative increase | for example 20%, elsewhere 10 or 30% | a jump versus yesterday's number of disapproved products | reports without a cause when yesterday's number was low |
| New reason | a reason that was not there yesterday | a broken attribute, a policy action | an increase in a reason you already know |
| Share of the catalog | for example above 5% of the range | slow growth in small batches | silent until the share crosses the threshold |
Example
The catalog from the introduction: 12 disapproved yesterday, 260 today, 80,000 products in the catalog
- Absolute increase: from 12 to 260 is +248 products, threshold +10AlertOn a large catalog, 10 products are noise.
- Relative increase: from 12 to 260 is more than +2,000%, threshold 20%AlertThe percentage is calculated from yesterday's number of disapproved products.
- Share of the catalog: 260 of 80,000 is 0.325%, threshold 5%SilentWorks as a backstop for slow growth.
Each of the four signals has a blind spot, which is why the script watches all of them at once.
How to build the monitoring on the Merchant API
The Merchant API returns product status data in Reports through the reports.search method. The query targets the product_view table with the fields id, offer_id, aggregated_reporting_context_status and item_issues. The shape of the query according to the Merchant API documentation:
SELECT offer_id, id, title, price FROM product_view WHERE aggregated_reporting_context_status = 'NOT_ELIGIBLE_OR_DISAPPROVED'
To watch the reasons, add the item_issues field to the selection. The status in the aggregated_reporting_context_status field takes four values: ELIGIBLE (the product is eligible for all contexts), ELIGIBLE_LIMITED (eligible only in some contexts), NOT_ELIGIBLE_OR_DISAPPROVED and PENDING. Watch the version: work with Merchant API v1. According to Google's plan, v1beta was to end on February 28, 2026.
The script stores every snapshot and compares it with the previous one. The result is a list of counts by disapproval reason: for each reason, the change versus the previous day and a flag showing whether the reason is new. When one new reason sits on hundreds of products, check the last feed fetch first.
I made the finished monitor public on GitHub, and you will also find a link to it on the about page. For campaigns I have a separate script for watching the bidding change. The monitor runs free in Google Apps Script and sends the alert to Google Chat or by email. It triggers itself once a day.
Time the check to the fetch schedule you have set for the data source in Merchant Center, so that one feed fetch happens between two checks. You then compare the difference in the output with what changed in the last import. The import is the first place to look for the cause. Disapprovals also grow without an import, though, for example when Google finds a policy mismatch.
What to do with the alert
Send the messages where the work happens: to Google Chat, by email or to another chat. Set the thresholds so that no alert arrives on quiet days.
Decide in advance who handles which reasons. Missing or wrong data in the feed is for whoever manages the feed, unavailable images and pages for a developer. Policy violations are for the store owner, by changing the range or the website.
Diagram
Who handles which disapproval reason
- Missing or wrong data in the feedFeed managementFixes the data error, for example in a supplemental feed.
- Unavailable images and pagesDeveloper
- Policy violationStore ownerBy changing the range or the website.
After an alert, look at the reason first and only then at the count. Find out whether the reason is new or has merely grown. For a new reason, check what changed in the last feed fetch. You can then fix a data error, for example, in a supplemental feed.
The procedure for individual reasons is in the overview of the 10 most common disapproval reasons. When the reasons are scattered across the whole range, first check the account-level issues in the banner at the top of Merchant Center. What to do when an account suspension looms is in my article on account suspension for misrepresentation.
Summary
- You see product status, history and issues directly in Merchant Center. The history chart sits in the product overview, the "Needs attention" tab gathers product issues, and both a warning and a notice of account suspension arrive by email. The threshold for the daily change, however, is set by the store itself, and a script watches that threshold.
- Four signals run at once. Set the absolute and relative increase, the new reason and the share of the catalog according to whether you have hundreds or tens of thousands of items.
- The disapproval reason decides who makes the fix. The number of disapproved products only tells you that something is going on.
- The script takes its data from Merchant API v1, from the
product_viewtable with the status of every product and theitem_issuesfield. - The finished monitor is free. The Google Apps Script from GitHub sends the alert to Google Chat or by email.
- Tie the check to the feed import. One check per data source fetch helps you trace which import may have brought the problem.
So to the history chart in Merchant Center you add your own threshold and an alert that tells you when to act.
Download the monitor from GitHub, set the four signals according to your catalog size and compare the first output right after the next feed fetch.
