Monitoring vs validation: catching the error before you submit it

A disapproval email is a post-mortem. By the time you read it the items are already out of the auction and the spend has already gone to the wrong products. Validation catches problems at submission. Monitoring catches them before submission, and catches the ones validation structurally cannot see.

Validation is a gate. Monitoring is a watch.

Validation answers one question: is the feed acceptable right now? It runs at a moment, usually just before upload, and if the feed passes you stop thinking about it.

Feeds do not stay clean just because nobody touched them on purpose. A plugin update changes how variants are exported. A supplier renames a column. An image host starts failing on a batch of URLs. A developer loads new products through an import path that skips enrichment. Each of those lands after validation passed and before anyone looks again, and the next thing to read the feed is usually the channel.

Monitoring inverts the order. Instead of checking the feed when you submit, you check it on every sync and alert when its condition moves. The unit of analysis shifts from "are there errors" to "has error behaviour changed", which is the question that predicts trouble.

The four signals worth alerting on

Not every field deserves an alert. These four cover most feed failures, and each maps to a distinct failure mode.

Error-rate delta

Suppose a feed sits near 1% item errors for months. That is stable, and you can fix it whenever. Now a single sync takes it to 4%. The level alone tells you little, because both states are just numbers. The change tells you something happened recently, and recent causes are findable causes. Alert on the delta against a rolling baseline rather than on an absolute count, because absolute thresholds either cry wolf weekly or sit quiet while the feed drifts.

Disapproval spike

Count new disapprovals per sync against their rolling average, which is a different number from your total disapproval count. That total includes everything you already triaged. Spikes matter because two very different events surface here first: a bug in your own feed, and a channel policy update that disapproves a category you have sold for years without changing anything.

Sync failure

Attribute coverage drop

Measure the share of items carrying the attributes your campaigns segment on: GTIN, brand, size, colour, whatever your ad groups target. Coverage drops when new products enter through a path that skips enrichment. Nothing errors. The items simply fall out of the ad groups that require those attributes, and the campaign quietly shrinks.

Thresholds you will actually respect

Thresholds fail in one direction. Too tight, and you train yourself to ignore alerts, at which point the monitor is decoration. Build them from your own rolling baselines. A workable starting configuration:

alerts:
  error_rate_delta:
    compare: current sync vs 7-day rolling average
    trigger: rate above 2x baseline
  disapproval_spike:
    compare: new disapprovals vs 7-day rolling average
    trigger: count above 3x baseline
  sync_failure:
    trigger: last successful sync older than one cycle + 6h
  attribute_coverage:
    attributes: [gtin, brand, size, color]
    trigger: coverage below 95%, or a 3-point drop vs last sync

Treat every value there as a starting point to tune against your own data. The mechanism is what matters: compare the feed to its own history, alert on deviation, and re-tighten any threshold that fires an alert you ignore.

Image compliance as a recurring checklist

Image rejections are the most mechanical failures in feed management, which makes them the easiest to automate. The requirements are stable and boring, which is exactly why a script should hold them instead of your memory.

What monitoring cannot do

An alert tells you something changed. It cannot tell you why. Investigations go faster when a change log sits beside the monitor: feed app updates, plugin upgrades, new import paths, supplier file changes. When an error-rate delta fires, the first question is what changed in the last 48 hours, and a log answers it in seconds instead of an afternoon.

That is the workflow the free feed validator is built around: the same checks running on every sync rather than on demand, alerts firing on deviation from the feed's own baseline, and a report that names the specific items and attributes that moved.

Where to start

Build sync failure first. Add error-rate delta second, attribute coverage third, and disapproval spikes last, once you have baselines worth comparing against. The order follows blast radius: catch first whatever costs the most per hour of going unnoticed.

Common questions

What's the difference between feed validation and feed monitoring?

Validation is a point-in-time check that asks whether the feed is acceptable right now, usually run before upload. Monitoring runs on every sync and alerts when the feed's condition changes. Validation catches what is wrong in this file. Monitoring catches what broke since the last one passed.

Which feed alerts should I set up first?

Sync failure, because a feed that never updated produces no errors at all while serving stale prices. Then error-rate delta against a rolling baseline, then attribute coverage, then disapproval spikes once you have enough history for the baseline to mean something.

What error rate is normal for a product feed?

There is no universal number, which is why the delta matters more than the level. A feed sitting at 1% errors for months is stable. The same feed at 4% after one sync is a recent change with a findable cause, and that is what an alert should be watching for.

How often should I audit feed images?

On a schedule you record, and at least every few months. Image requirements change, hosts start failing, and hotlink protection gets enabled by someone doing unrelated work. Log the date of the last full audit and treat a stale date as a finding.