Change monitoring and disapproval prediction
How Optimise watches your feed around the clock, logs what changed and when, and predicts which products are at risk of disapproval before Google acts, so you fix the feed pre-emptively.
Your feed doesn't stay still: a bulk edit, a price sync or a re-import can quietly break products between enrichment runs. Optimise monitors the feed continuously, records every change with a timestamp, and flags products that match known disapproval patterns before Google disapproves them. The point is to fix problems pre-emptively rather than react after impressions are already lost.
Feeds don't stay fixed
A feed that scored above 90 last week can quietly regress this week. A bulk edit in Shopify wipes a batch of barcodes. A supplier price file lands with the columns shifted. A platform migration re-imports every product with new IDs and scatters your variant groups. None of these announce themselves; they show up as a slow drop in impressions weeks later, after the damage is done.
Continuous monitoring exists so a quiet regression can't cost you weeks of performance before anyone notices.
The two jobs
Optimise does two related things around the clock: it watches for change and it predicts risk.
Change monitoring
Optimise checks your feed continuously and records every change with a timestamp. When something moves (a price, a barcode, a category, a batch of new products), it's captured in the change log, and any effect on your feed health shows up as score movement tied to that entry. So when the number moves, you can see what moved and when, instead of guessing.
Disapproval prediction
Beyond watching for change, Optimise scores each product against the patterns that cause real Merchant Center disapprovals: and flags at-risk products before Google acts on them. A flagged product is one that's still serving but matches a known failure pattern, so you can fix the feed pre-emptively rather than react to Diagnostics after impressions are already lost.
What the change log gives you
| Column | What it tells you |
|---|---|
| What changed | The field or products affected: e.g. "barcodes cleared on 214 products" |
| When | A timestamp, so you can line it up with an import or edit you made |
| Effect | The movement in your Feed Health Score attributable to the change |
| Status | Whether it's been addressed, or is still open |
The value is diagnostic: a drop in your Feed Health Score is never a mystery, because the log shows the upstream event behind it.
Deep dive How prediction works, and why pre-emptive beats reactive
Disapproval prediction is the difference between fixing a problem while the product is still serving and fixing it after it's already gone dark.
It scores against real failure patterns. Rather than only checking static completeness, Optimise pattern-matches each product against the things that actually trigger Merchant Center disapprovals:
- Identifier and brand mismatches: a branded product whose GTIN or brand doesn't line up with what Google's catalogue expects
- Category–attribute combinations that trigger manual review
- Image URLs prone to crawl failures
- Title constructions that trip editorial policy (promotional text, symbol spam, keyword stuffing)
- Variant groups that have fragmented or merged incorrectly
A flag reduces your score before Google disapproves. At-risk products drag your Feed Health Score down pre-emptively: the whole point is that the score reacts before Google does, so you fix the feed rather than react to Diagnostics after impressions are lost.
Every flag names its reason. A predicted-risk item is listed with the specific rule it matched, so you can see exactly why it was flagged and what to change: not just "this might fail" but "this title contains promotional text" or "this GTIN doesn't match the brand".
Why pre-emptive wins. By the time a product shows as disapproved in Merchant Center Diagnostics, it has already stopped serving and you've already lost the impressions and sales it would have made while you notice, diagnose and fix. Catching the same problem as an at-risk flag while the product is still live means the fix lands in the supplemental layer and the product never goes dark. When products do slip through to a live disapproval, Fix disapproved products covers the recovery path.
Because every fix is applied in the supplemental layer, addressing a flagged product is non-destructive and reversible: you're correcting what Google sees, never editing your store. See How enrichment works for the mechanics.
The workflow in practice
- Watch the score. A movement in your Feed Health Score is your early warning.
- Read the change log. It tells you what upstream event caused the movement, and when.
- Clear the at-risk list. Each flagged product names the rule it matched; fixing it applies an override in the supplemental layer.
- Confirm the recovery. The score reflects the fix on the next check, before Google ever needed to act.
Where to go next
- Understand how flags feed the score in Feed Health Score explained
- Handle products that reach a live disapproval in Fix disapproved products
Frequently asked questions
How is predicting a disapproval different from waiting for Google?
Google disapproves after the fact, and by then the product has already lost impressions and you're reacting in Diagnostics. Optimise flags products that match known disapproval patterns while they're still serving, so you can fix the feed before Google acts and never lose the visibility.
What triggers a change-log entry?
Anything that moves in your feed between checks, such as a price change, a barcode wiped by an import, new products added without complete data, or a category or title shift. Each entry is timestamped so you can see exactly what changed and when.
Does fixing a flagged product change my store?
No. Fixes are applied in the supplemental layer that feeds Google, exactly like every other enrichment. Your Shopify data is untouched.