Who it is for
Track what other products ship, in dated notes
Competitive research kept as bookmarks decays into a list of links you cannot search. Clipped into Markdown it becomes a corpus you can grep, diff against last quarter’s capture, and quote in a decision document with the date attached.
Research that stops being usable
The bookmarks folder called “competitors” has ninety entries. Half redirect to a rebranded marketing page, a quarter need a login nobody on the team still has, and none of them say what the page claimed in March. When someone asks whether a rival shipped a feature before or after you did, the answer is sitting on a page that has been rewritten since.
Screenshots do not rescue it either. They cannot be searched, they carry no date beyond a file timestamp, and pasting one into a decision document invites the question of what the rest of the page said. What holds up in a review is the text, with the date the page declared, in a file you can still grep six months later.
And the signal is spread across pages that look nothing alike. The changelog says what shipped, the docs say what it actually does, the pricing page says who it is for, the status page says how often it breaks, and a forum thread says what customers think of all four. Nothing watches any of them for you – you look when you look, and whatever you did not capture on the day is simply gone, because none of those pages keeps a history a visitor can read.
What the corpus gives you
- Publication date read from the page, so a changelog entry keeps its real timing rather than the day you found it.
- Per-site rules route each competitor into its own folder automatically.
- Pricing and limits tables survive: 12 of 15 kept on the technical corpus, against 7 for each engine compared.
- The source URL is in every note, so a claim in your document is traceable to a page and a date.
- Files live in your own vault, next to the decisions they support, searchable with grep or your editor.
- Clip the same page again next quarter and a diff shows exactly what moved.
- Forum threads keep their nesting and each comment’s score, which is where customers say the things a changelog never will.
- The extension uploads nothing about the page, so tracking a competitor leaves nothing behind beyond the page view your browser had already made.
--- title: "Version 1.96: release notes" source: "https://code.visualstudio.com/updates/v1_96" date: "2024-12-11" extraction: "dom" --- ## Workbench - **Search results in the editor.** Results now open as an editor tab. - **Custom window title.** New variables for the active profile and branch. ## Extension authoring - The proposed API for terminal shell integration is now stable.
Setting up a competitor corpus
The setup is per-site rules and a recurring slot in the calendar. Neither is clever, and together they are the whole method.
- Open Options from the extension icon and point the destination at a folder the team can read:
research/competitors, ideally in a repository so history comes for free. - Add a per-site rule for each competitor – their domain to their own subfolder. After that, nothing needs filing by hand, which is the only reason the corpus survives a busy quarter.
- Set what the icon click does to “save to folder”. Capture has to be cheaper than deciding whether to capture, or you will only capture the pages you already knew were important.
- Set the filename template to
{date}-{title}, so four captures of one changelog sort chronologically inside the competitor’s folder. - Turn on
sourceanddatein the frontmatter. The publication date is the page’s own, which is what lets you say a rival shipped a feature in March rather than that you noticed it in March. - Set images to skip. Marketing screenshots are the largest and least useful part of a competitor page, and their URLs change with every redesign.
- Put a recurring slot in the calendar and capture the same five pages each time: changelog, pricing, the docs page for the overlapping feature, the status page, and whatever thread is currently active about them.
Settings for tracking over time
Everything here optimises for the second capture rather than the first. A corpus with one capture of each page is a bookmark list with extra steps.
| Setting | Value | Why this value here |
|---|---|---|
| Icon click | Save to folder | Capture must cost less than the decision to capture |
| Destination | A shared `research/competitors` folder | A corpus one person can read is a private hobby |
| Per-site rule | One competitor per subfolder | Filing by hand is the step that stops happening in a busy quarter |
| Filename template | `{date}-{title}` | Four captures of one changelog sort chronologically without any tooling |
| Frontmatter | `source` and `date` on | Lets a decision document say when a rival shipped, not when you noticed |
| Images | Skip | Marketing screenshots are the bulkiest and least quotable part of the page |
| Cadence | The same five pages, on a recurring slot | The diff is the deliverable, and a diff needs two captures |
--- title: "Rate limits" source: "https://example-api.com/docs/limits" date: "2026-02-19" extraction: "dom" --- | Plan | Requests / min | Burst | Retention | | ---------- | -------------- | ----- | --------- | | Starter | 60 | 120 | 7 days | | Team | 600 | 1200 | 30 days | | Enterprise | negotiated | – | 365 days | Limits are applied per organisation, not per key.
Three questions it answers
Who shipped it first
A rival announces a feature you have had in beta since spring, and the room disagrees about the order of events. Your captures of their release notes carry the dates the pages declared for themselves, so the sequence is established from files rather than from memory.
The page’s own date is the point. A file timestamp says when you clipped; a changelog entry that declares 11 December says when they published, and those are different facts that a screenshot conflates into one.
A pricing change nobody announced
You capture a competitor’s limits page each quarter. Between two captures the burst allowance on the entry plan halves and retention on the top plan triples, with no blog post and no changelog entry – the page simply says something different now.
The diff is three lines and it changes a positioning argument. Neither capture is remarkable on its own, which is exactly why the method only works if capturing is cheap enough to do before you know what will matter.
A claim in a decision document that survives review
The recommendation quotes a rival’s documented rate limit. The quote comes from a file with the source URL and the date above it, so the reviewer who wants to check it opens the file rather than asking you to find the page again.
Pages built entirely from marketing blocks are the exception worth knowing about – those often have no article body, and the extension reports “no article” rather than returning a page of links. When that happens, the documentation page usually carries the same claim in a form you can actually quote.
Against the usual competitive research
Teams generally do the first two, occasionally pay for the third, and rarely do any of them consistently. The costs below are what makes consistency hard.
| How it is done now | What you get | What it costs |
|---|---|---|
| A bookmarks folder | A list of where to look | Every entry resolves to today’s page; half of them redirect within a year |
| Screenshots in a shared drive | What the page looked like | Not searchable, no date beyond the file, no way to quote a sentence |
| A page-monitoring service | Alerts when a page changes | A subscription, and it watches the pages you thought of in advance |
| Notes typed into a document | Your reading of the page | Paraphrase, not evidence; six months on nobody can tell which was which |
| Clean Clipper | Dated text files you can grep and diff | No monitoring and no alerts. It captures when you look, and does not watch |
When a competitor page will not clip
The pricing page came back as “no article”
Modern marketing pages are often built entirely from design components with no article body at all, and more than about a quarter of the extracted text ends up inside link labels and button captions. The extension refuses that rather than returning a page of fragments. The documentation or the terms page usually carries the same limits in prose, and those clip normally.
Only the newest release notes came through
Changelogs commonly paginate, or load older entries behind a “show more” control. The extension reads the DOM at the moment you clip, so what has not been loaded does not exist to capture. Expand the list first, or clip each page of the archive. The files can sit side by side in the competitor’s folder.
The individual entries have no dates
The date field holds one date for the page, taken from the page’s own metadata, not a date per entry. Where a changelog puts the date in the body text of each entry, it comes across as body text and stays readable. Where the site emits no date at all, the field is empty rather than filled with today – and on some corpora that is common rather than rare.
I need to know when it changed, not just that it did
That is the honest limit of this method – there is no monitoring, no alerting and no scheduled recapture, so the resolution of your record is the frequency of your captures. A page you capture quarterly tells you a change happened within a quarter. If the timing itself is the decision, a monitoring service is the right tool and this is not.
What it will not do
It does not watch pages for you: no monitoring, no alerts, no scheduled recapture. You clip when you look. There is no crawler and no batch mode, so a docs site is clipped a page at a time. Marketing pages built entirely from design blocks with no article body may be reported as “no article”, because the extension prefers saying so to returning a page of links. And it does not diff for you; it produces files any diff tool can compare.