A report that arrives every Monday whether or not anything happened teaches its reader to ignore it. Three constraints fix that: alert only above a severity floor, only on kinds worth interrupting somebody for, and only when the finding is new.
A weekly Search Console report stays silent when nothing is wrong if it alerts on change rather than on schedule. That takes three constraints working together: a severity floor, so only findings above a set grade are dispatched; a kind filter, so opportunities never interrupt anybody; and a memory of which findings are already open, so a problem reported on Monday is silent on Tuesday while it is still true. Without the third, a threshold-based report re-sends the same finding until somebody fixes it or stops reading.
A scheduled report stops being read because its arrival stops carrying information. An email that comes every Monday whether or not anything happened has an expected value close to zero before it is opened, and a reader who opens twenty of them and finds nothing actionable in nineteen has learned an accurate lesson. The problem is not the content of any single report; it is that the schedule, not the data, decided that the report exists.
Inverting that is the whole design. A report whose arrival is itself the signal is worth opening, because its presence means a threshold was crossed. This is why the interval and the alerting rule should be separate settings: the scan can run every day while the dispatch happens only when something changed. Running often and speaking rarely is the combination that produces a report people still read after six months.
A severity floor is the grade below which a finding is recorded but not dispatched. Market4's insight monitor defaults that floor to high, which means low and medium findings are computed, stored and available on screen without ever being pushed. The reasoning is written into the setting: medium is the level of "worth doing this week", and something worth doing this week belongs on a screen somebody opened, not in a notification that fires at two in the morning.
The kind filter does work the floor cannot. Only two kinds of finding are ever dispatched: anomalies and risks. Opportunities are excluded regardless of how large they are, because an opportunity that existed yesterday still exists tomorrow, and a win pushed overnight is spam wearing the clothes of good news. That distinction between something that has changed and something that is merely true is the same one that separates an alert from a report.
Search Console has no language dimension. On a site in more than one language you separate the data by page or by country, which means the URL structure you chose for translations decides what you can measure.
Search Console's regex filters are RE2 expressions, which is a deliberately smaller syntax than the one most regex tutorials teach. What RE2 leaves out, what to write in place of each missing construct, and the two things a filter does not change.
Market4 turns one release note into a changelog page, a blog post, a mail-out and a week of social posts — and then tells you which of them brought anyone back.
Alerting on change means the monitor keeps the set of findings currently open — already reported and not yet resolved — and compares each scan against it. A finding whose identifier is already in that set is not re-reported. A finding that has disappeared from the set since the last scan is reported as resolved. The consequence surprises people the first time: a real, unfixed problem produces exactly one notification and then goes quiet, and the quiet does not mean it went away.
That behaviour is a deliberate choice with a visible cost, so the reading tool has to compensate for it. A monitor read should return the identifiers of the open findings alongside the schedule, precisely so that somebody can ask what is currently wrong without waiting for a new alert. It should also distinguish a monitor that has never been configured from one that was configured and switched off, because those two states look identical in a report and mean opposite things about whether anybody is watching.
A Search Console finding is worth sending when it clears a volume floor as well as a movement floor, because a percentage swing on a handful of impressions is noise with a dramatic name. Market4's rules pair the two on every check. A striking-distance query has to sit in a position band and also carry enough impressions for the position to mean anything. A below-par click-through rate has to be a real shortfall against the expected rate for its position, on a query with enough impressions for the rate to be measurable at all.
| Finding | Movement condition | Volume floor |
|---|---|---|
| Striking distance | Average position between 8 and 20 | At least 50 impressions in the window |
| Below-par click-through rate | Half or less of the expected rate for that position | At least 100 impressions, position 20 or better |
| Impression collapse | A drop of 40 per cent or more against the previous window | At least 100 impressions in the previous window |
| Rising query | Growth of 50 per cent or more, with a real absolute gain | A prior window that was not effectively zero |
| Zero-click query | Impressions with no clicks at all | At least 200 impressions |
| Cannibalisation | Two or more of your own pages on the same query | At least 20 impressions per page |
The striking-distance band is worth stating precisely because it is often quoted wrongly. The lower bound is position 8, not position 11: a query sitting eighth is already close enough that the move to the first few results is a realistic piece of work, and excluding it because it is technically on page one throws away the easiest candidates on the list. The upper bound of 20 exists because past that point the work stops being an optimisation and starts being a new page.
Search Console data lags, and a report that ignores the lag will alert on a collapse that is only a gap in the data. Market4 treats Search Console as three days behind and GA4 as one day behind, and computes its windows against that rather than against today. A daily scan is scheduled at 02:00 UTC for the same reason — an hour after the analytics sync it reads, so it is never reporting on data that has not arrived yet.
The other cost of frequency is quota. Every scheduled scan runs every rule over every connected source and spends the customer's own Google quota, which is why the shortest available interval is hourly rather than something finer: a finding re-evaluated ninety-six times a day is ninety-six chances to alert on the same number flickering over a threshold. Pick the longest interval that still catches what the reader cares about, and remember that Search Console's own API quotas are a shared budget you are drawing down.
One failure mode sits outside all seven items and catches people anyway. If the scans run but nothing is subscribed to receive them, the findings are computed and recorded and nobody is told, and the system looks healthy from every angle except the one that matters. Check that a delivery destination exists before trusting silence to mean good news, which is the same discipline that separates a working reporting pipeline from one that merely runs.
Because a change-based monitor keeps a set of findings it has already reported and does not re-report them. A problem detected on Monday stays in that set until it resolves, and every scan in between recognises it and stays quiet. This is intentional: repeating an unfixed finding daily trains the reader to filter the sender. To see what is currently wrong, read the monitor's open findings directly rather than waiting for another notification.
Run it as often as the data changes and no more. Search Console data lags by around three days, so anything finer than daily is re-evaluating numbers that have not moved. Each scan also spends the customer's Google API quota across every rule and every connected source, so frequency has a direct cost. Daily is a sensible default for an active site; weekly is enough for a site publishing a few times a month.
High and above, as a default. Medium means "worth doing this week", and something worth doing this week belongs on a dashboard somebody chooses to open rather than in a message that arrives overnight. Reserve notifications for findings where a delay of several days has a real cost: an impression collapse, a page dropping out of the index, a tracking tag that stopped firing. Everything else can wait for somebody to look.
Include them in the report and exclude them from the alert. An opportunity that existed yesterday still exists tomorrow, so pushing it has no time value and its arrival carries no information. A problem is different: it started at a particular moment and the cost of not knowing accumulates. Filtering dispatch by kind, so only anomalies and risks are ever pushed, keeps the notification channel meaningful without hiding anything.
Because position 8 is already a realistic candidate and excluding it discards the easiest work on the list. The old habit of starting at 11 comes from thinking in pages rather than positions, and the page boundary is not where the click-through curve bends. The upper bound of 20 is the point beyond which improving the existing page stops being the right intervention, and a new page targeting the query becomes the better answer.
Search Console will group performance rows by seven dimensions, and searchAppearance is the one that says which result feature an impression came from. It also changes how the totals are aggregated, which is the part that surprises people.