Anatomy of a traffic alert you can act on

A traffic alert is a sentence that has to survive two readings. The first is on a phone at 11:40 on a Wednesday, between two other things, when all you need is to know whether to care. The second is a week later, when a client asks what happened and the numbers in Search Console have since been restated and no longer match what you remember.

Most alerts fail the first reading by saying too little and fail the second by storing nothing. This is what we think an alert has to carry, field by field, using the example from QueryWatch’s own Demo Mode dataset. The numbers are demo numbers; the structure is the point.

The notification

What lands on the Lock Screen is one line plus one sentence:

brightloom.co · clicks down 34%. 412 clicks on Sunday, Sep 6 vs a usual Sunday of 624. /pricing explains 56% of it.

Four facts, each doing a job. The property, because you manage more than one. The metric and the size of the move, so you know whether to stop walking. The observed value against its baseline, so “34%” is anchored to real clicks rather than a feeling. And the page that explains most of the move, which is the difference between an alarm and a lead. If the drop is mostly one page, you already know what kind of problem this is before you open anything.

The baseline

The percentage only means something if you know what it is measured against, and the wrong baseline produces the alert everyone switches off.

QueryWatch compares the latest complete day with the same weekday over the previous four weeks: a Sunday against the last four Sundays, a Tuesday against the last four Tuesdays. Not today, because today in Search Console is always a partial day, and a partial day always looks like a drop. Not yesterday alone, because a site’s Sunday is not its Monday, and comparing adjacent days fires every weekend. Not a plain seven-day average either: on a site that does most of its traffic on weekdays, a seven-day average makes every quiet Sunday look like a 40 percent drop, which is exactly the false alarm that gets an alert switched off.

The rule that fires is a day at least thirty percent away from that weekday baseline, or at least two standard deviations from it, whichever you hit. Both numbers are adjustable per property. A property doing fifty clicks a day and one doing fifty thousand do not want the same threshold, and a rule you cannot change per site is a rule you will end up disabling for all of them.

The evidence snapshot

This is the field that handles the second reading. At the moment an alert fires, QueryWatch stores what it saw: the observed value, the baseline it was compared against, the dates of both, the threshold that was hit, and the top contributing pages at that moment.

It does this because Search Console data keeps moving. Google finalises performance numbers two to three days after the fact and sometimes restates them afterwards. An alert that simply links to the live report will, a week later, open a chart that no longer shows the thing it alerted you about. The snapshot means the alert still says, verbatim, what it saw on the day. When the client asks, you can quote it.

The screen it opens

Tapping the notification lands on the change investigation for that day, which is the part that turns an alert into work you can do. It lists the pages that contributed to the move, each with its before and after numbers and the share of the drop it accounts for. In the demo example, /pricing went from 186 clicks to 68 and explains 56 percent; /features/automations from 92 to 41 for 24 percent; a blog post for 8 percent more. The same view exists by query.

It also shows the counter-mover: the page that moved the other way. In the demo it is a blog post up 22 clicks on the same day. A counter-mover matters because a loss on one page and a gain on another often means Google swapped which of your pages it shows for a query, which is a different problem from a page losing visibility outright. We go through the whole investigation step by step in clicks dropped, now what.

The free tier shows the top three contributors; Pro shows twenty and keeps the history.

The four rules

The anomaly rule above is the one people think of as “the alert”, but there are three more, each switchable per property.

A new query in the top ten: a query you are watching, or any query with at least fifty impressions that day, enters positions one to ten. This is the alert that tells you a page finally landed rather than that something broke.

A watched URL changing its indexing state: a page you have marked as watched changes its index verdict or coverage state in Google’s URL Inspection results. This catches the key page that silently drops out of the index, which otherwise shows up weeks later as a slow bleed in clicks.

A sitemap error: a submitted sitemap’s error count rises, or the sitemap disappears from Search Console. Usually the first sign that a deploy broke something structural.

The cadence, and the cap

The relay checks every six hours. It would be easy to promise every fifteen minutes and it would be useless, because the data does not change faster than Google finalises it. Polling more often re-reads the same numbers and risks alerting on a partial day.

And there is a hard cap: one notification per property per day. If two rules fire for the same site on the same day, they arrive as one notification. An alert that fires twice for the same drop trains you to ignore it, and an app that cries wolf gets its notifications switched off within a week, after which it is worth nothing.

The Monday digest

Alerts fire when something moves. The digest arrives every Monday whether or not anything did: clicks, impressions, CTR and position for the week against the previous one, how many queries entered or left the top ten, which alerts fired, and the biggest mover across your properties. It is templated and deterministic. No model writes it and nothing in it is invented, which is a deliberate choice for something you might forward to a client. The last twelve are kept.

What it costs you

Alerts are a Pro feature, and turning them on is the one thing in QueryWatch that sends a Google credential off your phone, because something has to check Search Console while you are asleep. The app explains this in a consent screen before anything is sent, the relay is our own server rather than a third-party backend, and turning alerts off deletes the row immediately. The alerts page has the full version, and where does your Google token go has the questions you should put to any app that offers the same thing.