Competitor tracking automation that pings you when pricing moves on Zo

Competitor tracking automation in Zo works by snapshot diff. You keep a watchlist file of competitor URLs, Zo reads each page on a schedule, compares this run against the snapshot saved last run, and messages you only when something real moved. That is how you monitor competitor website changes with nothing connected, because Zo reads public pages directly.

Key takeaways

• Zo reads public web pages with nothing connected, so a competitor watcher is the one automation you can build before authorizing an app.
• The mechanic is a stored snapshot plus a diff. Zo writes what each page looked like into a workspace file, then compares the next run against it.
• A watchlist file beats a prompt stuffed with URLs. Edit the file, and the automation picks up the change on its next run.
• Raw diff monitoring fires on cosmetic churn. Visualping's guidance is to describe the change you care about in plain language rather than alerting on any pixel that moved.
• Press releases often announce a pricing change before the pricing page updates, which is why the changelog earns its own row.
• Every scheduled run bills AI credits whether it finds a change or not, so cadence is a cost decision.

Why does a competitor watcher work without connecting anything?

Most Zo automations wait on a plugin. This one does not. Competitor pages are public by definition, and Zo fetches a public URL with zero setup, so automated competitive intelligence is available before you decide how you feel about handing over inbox access.

Competitive research is also the task nobody schedules. You check a rival's pricing page the week you rewrite your own, forget it for five months, then hear about their new billing model from a prospect.

How do you set up competitor tracking automation in Zo?

Five steps. The first one is a file, and it is the step people skip.

1. Write the watchlist file. Create Competitors/watchlist.md. One row per page: competitor, URL, page type, plus two columns Zo fills in itself.
2. Take the first snapshot. Run it once in chat. Zo reads every URL, writes a snapshot into Competitors/snapshots/, and stamps the date. Nothing to report yet, because there is no previous state.
3. Read what came back. Check whether Zo loaded every page or quietly gave up on one. Some sites refuse automated reads, and you want to know now, not in November when silence looks like stability.
4. Turn it into an automation. Paste the watcher prompt, state the schedule in plain English, pick delivery. Zo converts your sentence into a rule behind the automation schedule card.
5. Set conditional delivery. The instruction that matters tells Zo to stay silent when nothing moved. Without it you get a weekly "no changes detected" email and stop opening it by week three.

What does the watchlist file look like?

Six columns. The last two belong to Zo, and they turn the file into a log you can skim when someone asks how long it has been since Crosswind touched their pricing. It is a plain file in an open format, so sync it down or commit it to a repo. See files on your server.

Why a file instead of a prompt full of URLs? Prompts rot. Adding a sixth competitor to a prompt means editing the automation and hoping you did not break the delivery condition. Adding a row to a file is one line.

Which competitor pages actually earn a slot?

Four types pay for themselves.

The pricing page. Watch tier names, numbers, seat minimums, and the feature bullets under each tier. A quiet feature migration from Pro to Enterprise is a price increase wearing a costume.

The changelog or release notes. The underrated row, and the best place to track competitor launches. Cotera's write-up on automated pricing alerts notes that press releases and blog posts often go live before the pricing page catches up, so your earliest signal is the announcement.

The careers page. A roadmap tell nobody checks. Three open infrastructure roles with a compliance keyword in every description is a company building for enterprise buyers, eight months early.

Comparison pages that name you. A competitor's /compare/yourproduct is their live sales objection script. When it changes, their sales team changed its argument.

How do you stop the alerts from being noise?

Here is the failure that kills most change monitors. A page "changed" because a testimonial rotated or the hero image swapped to the seasonal one. Raw markup diffing cannot tell that apart from a 20% price increase, so it reports both with equal confidence and you stop opening it. Prior art, not a Zo quirk: Visualping's guidance on competitor pricing change alerts is to describe the change you care about in natural language, because element-level noise produces alert fatigue.

Zo reads the page the way a person does rather than diffing markup. So tell it what counts.

Read Competitors/watchlist.md. For every row, fetch the URL and read the page.
Compare what you read against the saved snapshot for that URL in
Competitors/snapshots/. Judge the comparison by MEANING, not by markup.

For a Pricing page, a real change is any of:
- a tier name added, removed, or renamed
- any dollar figure, seat minimum, or usage cap that moved
- a feature bullet that moved between tiers
- a change to the free plan or trial length
- a new billing model (per-seat to usage-based, annual-only, etc.)

Ignore entirely: testimonials, logo walls, hero images, copyright years,
banner promos, blog links in the footer, and wording tweaks that leave the
commercial terms identical.

For a Changelog page, report only entries that are new since the snapshot.
Summarize each in one line.

For a Careers page, report only net-new roles and note the team and seniority.

Then: overwrite each snapshot file with what you read this run, and update
the Last snapshot and Last change columns in the watchlist.

If NOTHING qualified as a real change on any page, do not message me. Write
one line to chat and stop.

If something did qualify, email me. Subject: "Competitor watch: <what moved>".
Body: what changed, the competitor, the URL, the before and after, and one
sentence on why it matters to us. Nothing else.

That prompt defines a real change per page type, names the noise, keeps the snapshot fresh, and makes delivery conditional. The last part decides whether you read the alerts or filter them away.

How often should each page type be checked?

Cadence is a cost lever. Every run spends credits whether it finds anything or not, and a five-minute schedule fires 288 times a day and bills for all 288. Match the interval to how fast each page actually moves.

Five competitors across those six rows is a manageable number of runs. Twenty on daily checks is a bill, and a digest nobody finishes.

What about SERP watching and brand mentions?

Same mechanic, different target. Rather than snapshotting a page, Zo runs a search, records what ranks, and diffs the result set against last week.

Every Monday at 7am, search these queries and record the top 10 organic
results for each: "<keyword one>", "<keyword two>", "<keyword three>".

Compare against Competitors/serp-snapshot.md. Report only:
- a competitor that entered or left the top 10
- a position change of 3 or more for us or a tracked competitor
- a new domain in the top 5 we have never seen before

Also search "<our brand name>" limited to the last 7 days and list any new
mention with the source and one line of context.

Overwrite the snapshot with this week's results. If nothing crossed those
thresholds and there were no new mentions, do not send anything.

The thresholds are the whole trick. Rankings jiggle by a position or two constantly, so a threshold-free diff reports movement every week, and three positions is a defensible floor. Zo's web search handles the queries, the file handles the memory.

When does Zo need the browser instead of just reading the page?

A read is a fetch. Zo pulls the public URL and works with what came back, fast. Driving the Zo browser means a real Chromium session clicking through the page, which is slower.

For competitor watching, almost everything is a read, because pricing pages are public by design. Login-gated pages are the exception, and they cost you a browser session, a slower run, and a session that can expire and take the watcher quiet with it. The read versus browse split predicts which you get.

What goes wrong

A site blocks the read and the run reports no change. Dangerous, because a failed load and a stable page look identical in an empty inbox. Say so explicitly: If a page fails to load or returns a block page, do not treat that as "no change." Flag it as a failed read with the URL and the error, and email me on the third consecutive failure.

Cosmetic churn generates false positives. The standing complaint against raw price change monitoring, fixed by naming the ignore list in the prompt. If it still fires on nothing, tighten the definition of a real change instead of widening the ignore list.

The credit bill creeps. Ten competitors at four pages each on daily checks is 1,200 page reads a month, so cut cadence before you cut competitors. See pricing for how credits work.

A watcher goes quiet and you assume stability. Every run is saved as a real conversation you can open. The transcript shows whether Zo fetched the URL, what it compared, and why nothing qualified. See debugging an automation run.

A connected app's token lapses. The watcher itself needs nothing connected, but your delivery channel might. Route alerts through a connected app and let its authorization expire, and the schedule keeps firing while the message goes nowhere.

Judgment calls stay judgment calls. "Did the commercial terms change?" is fuzzy, and Zo will sometimes rule differently than you would on a borderline rewording. Tighten the definition or accept the odd extra email.

Nothing sends on its own. Zo drafts, you send. If the watcher spots a price cut and you want a note going to your sales team, keep the human gate on it. An automation that emails colleagues about a competitor before you have read it is a bad day waiting to happen.

Between-run state lives in files, not in the model. The watchlist and snapshots persist across runs because they are saved to disk, not held in the model's memory.

Frequently asked questions

Does competitor tracking automation require any connected apps?

No. Zo reads public web pages with nothing authorized, which is why this is a reasonable first automation. A connected app only matters if you want delivery somewhere specific, and email works out of the box.

How does Zo know what a page looked like last time?

It saves a snapshot to a file in your workspace each run and reads that file back on the next one. The comparison runs against the stored snapshot rather than a live memory, so state survives restarts, plan changes, and long gaps between runs.

How do I stop getting alerts about testimonials and banner changes?

Name them in the prompt. List what counts as a real change for that page type, then list the elements to ignore outright. Zo reads for meaning rather than diffing markup, so a specific definition of "real change" does most of the filtering.

What if a competitor's site blocks automated reads?

Some do. Instruct the automation to flag a failed load as a failure rather than reporting no change, and to escalate after a few consecutive misses. For a genuinely locked page, fall back to a browser session and accept a slower run.

How often should I check a competitor's pricing page?

Weekly is enough for almost everyone. Pricing pages change a handful of times a year, so daily checks multiply credit spend without improving signal. Put the daily cadence on the changelog, where the announcement usually lands first.

Can one automation watch several competitors at once?

Yes, and it should. One automation reads the whole watchlist, so adding a competitor is a new row rather than a new automation. Split into separate automations only when cadences genuinely differ, for example a daily changelog watcher and a monthly careers watcher.