Competitor Monitoring and Signal Tracker
Competitor monitoring fails from noise, not missed signals. This pack measures both ratios and reads the signals competitors already publish.
Free download · No account needed
Nobody abandons a competitor tracker because they missed something. They abandon it because the reviewer got 77 notifications in a quarter, 11 of which carried a real change, and stopped opening them in week five. So this pack is built on two measured columns rather than a weekly checklist: how much of what fires is real, and how many checks it takes to catch one change. Both drive a documented action, and both are ratios your current tool does not report.
The reason the noise is that high is that most tools only do the last-resort mechanism, which is fetching a page and diffing a region. This pack works down a preference order instead. A published feed first, because it is dated at source. Then structured data, because a careers page carrying job posting markup gives every role a posting date and a country without reading a word of prose. Then the sitemap, where one request returns every URL a company publishes with a change date against each.
That third one is the mechanism nobody sets up, and it needs testing before anything is built on it. The sitemaps protocol defines that field as the date of last modification of the page, and plenty of systems ignore that and stamp the build time on every URL. Counting distinct values settles it in one fetch: 1,412 URLs sharing three dates is a deploy. Your competitor teardown is the depth pass; this is the standing one.
What is in the pack
Competitor Register
One row per competitor with the distinct-date test result, the mechanism per surface, and the reason for each
Watch Schedule
One row per watch with its lag budget, the request group serving it, and whether it rides along free
Change Log
Detected date and claimed change date kept apart, with every row marked real or furniture
Signal Interpretation Register
One row per hypothesis with its confirm and kill conditions, both written before the evidence arrives
Detection Mechanics
Five mechanisms in preference order, with the distinct-date test and what each one is structurally blind to
Cadence Method
How a lag budget becomes a schedule, and why grouping by request matters more than the interval
First Fetch Findings
What one retroactive pass returned: recency maps, reconstructed hiring volume, and changes already missed
Change Digest
The outbound report, which names hypotheses settled and still open rather than listing the week's changes
How it works
- 1
Send names and domains
That is genuinely the whole ask. No surface list, no cadence decision, no mechanism choice per page, because all three come out of the first pass.
- 2
Read what they publish
One pass over each domain's sitemap, feeds and job posting markup, testing the modification dates before anything gets built on them.
- 3
Get the history first
The pass is retroactive: recency maps say what a competitor has stopped maintaining, and posting dates reconstruct hiring volume by month going back years.
- 4
Then schedule and interpret
Cadence per surface from a lag budget, grouped by the request that serves it, and every real change either attaches to a hypothesis or is logged and left alone.
Frequently asked questions
What do I need before this is useful?
The competitors you care about, by name and domain. That is enough to start, and it is worth saying plainly because the instinct is to go and assemble a list of URLs and surfaces first. Everything else, including which mechanism serves which page, falls out of the first pass.
How is this different from an alerting tool?
Alerting tools mostly do one mechanism, which is fetching a page and diffing a region. It is the last resort here, because it costs a request per surface, cannot date a change better than between two checks, and fires on consent banners and carousels. Nine of them produced 86 per cent noise in the example.
Why test the sitemap dates at all?
Because a build timestamp is indistinguishable from a real change feed until you count the values. Google's own guidance says it uses the date if it is consistently and verifiably accurate, and a competitor who fails that test is expensive to watch forever, which is worth knowing on day one.
Does this find anything before monitoring has run?
That is the first thing it does. One date per URL is a recency map, so it says which parts of a competitor's site they have stopped maintaining. Job posting markup carries the original posting date as a required field, so live roles reconstruct hiring volume by month for years back.
Why not just check everything weekly?
Because the surfaces differ by a factor of 16.5 in how often they change, so one interval is simultaneously right for one of them and twelve times too fast for another. And the cost is not requests, it is the reviewer: a schedule nobody abandons beats a schedule that is theoretically complete.
What stops the digest becoming a list of changes again?
The register reports hypotheses, not changes. Of 133 logged changes in the example quarter, 46 attached to a hypothesis and 87 touched nothing, which is the normal ratio. They still get logged, because the pattern that turns a batch of them into evidence usually shows up two quarters later.
Does this write the battlecard?
No, and the boundary is deliberate. This space detects change and interprets it, then hands the answer to a named person. The depth analysis of one competitor belongs in a competitor teardown, and the field-facing artifact belongs in a sales battlecard. A detected pricing change also invalidates whatever your published comparison page asserts about them, which is a separately sourced claim.
Find out what your competitors already published
Send the names and domains. The first pass is retroactive, so you get months of history before any monitoring runs.
Monitor my competitors