Detecting what a competitor really shipped, with evidence per change

Competitor alerts usually report noise about competitors rather than changes in what they sell. A blog post announces a feature that will reach customers next year, a homepage redesign looks like a new product, and a genuinely significant change, such as a removed plan limit or a new API endpoint, appears quietly in the documentation and nobody notices for a quarter. This guide is about one narrow question: what did the competitor actually ship? It covers where shipped changes leave traces, how to set a baseline, how to turn page diffs into change records with evidence, and how to review them before they reach sales or product teams. For the wider practice of competitive research, see automating competitive intelligence.

Announced is not shipped

Before collecting anything, agree on the states a capability can be in. Mixing them up is the most common reason competitor reports mislead.

A change record should always carry its state. “Competitor launched X” is a claim; “X moved from preview to available on the top two plans, per the pricing page” is a finding someone can check.

Where shipped changes leave traces

Marketing pages are the noisiest place to look. The more reliable traces sit in pages written for existing customers and developers, because those pages have to be accurate for support reasons.

• Changelogs and release notes. The most direct source when a company keeps one. Watch for entries being edited or removed later, not only added.
• Documentation and API references. New endpoints, parameters, limits and deprecation notices often appear here before any announcement. A new section in the docs navigation is a strong signal.
• Pricing and plan pages. Packaging changes tell you what the company thinks a capability is worth and who it is meant for.
• SDK repositories and package registries. Version bumps, new methods and release tags are dated and hard to fake.
• Help center and status pages. New help articles show what customers are asking about; new components on a status page reveal new service surfaces.
• App store release notes and integration directories. Useful for mobile products and for partnerships that have actually gone live.

Job postings and conference talks hint at direction, not at what shipped. Keep them in a separate “signals” lane so they never get reported as releases.

Set a baseline before you watch

A diff is only as good as the snapshot it compares against. On day one, capture each page you plan to watch, store the normalized text with its address and retrieval time, and treat that as the baseline. Without it, the first run reports the whole page as new, and every later run compares against whatever happened to be there last week. The note on setting a baseline before you monitor explains why this step deserves its own review.

Normalization does most of the noise reduction:

• Strip navigation, footers, cookie banners, rotating testimonials and “last updated” stamps that change on every build.
• Split long pages into sections by heading and compare section by section, so one edited paragraph does not mark the whole page as changed.
• For pricing tables, extract the table into rows and columns and compare cells, not rendered text.
• For API references, compare the list of endpoints and parameters, not the prose around them.

Turn diffs into change records

A diff says text changed. A change record says what that means. The step in between is classification, and it is where an AI model is genuinely useful: given the before text, the after text and the page type, it can propose what kind of change this is. A person then confirms it.

{
  "competitor":  "example-rival.com",
  "surface":     "pricing page",
  "change_type": "limit changed",
  "state":       "priced",
  "before":      "Team plan: up to 5 projects",
  "after":       "Team plan: unlimited projects",
  "source":      "https://example-rival.com/pricing",
  "retrieved":   "YYYY-MM-DD",
  "evidence":    "Unlimited projects (Team and above)",
  "status":      "proposed",
  "reviewer":    null
}

Useful change types are few: new capability, removed capability, renamed or repositioned, limit changed, price or packaging changed, deprecation announced. Anything that does not fit is either cosmetic or needs a person to read it. Keep the before and after text together with the quoted passage, so a reader can check the claim without visiting the page, which may have changed again by then.

Pricing pages need extra care

Pricing pages are the most valuable surface and the easiest to misread. Many companies run pricing experiments, show different prices by region or currency, and keep some plans behind a sales conversation. A single snapshot may show a variant most visitors never see.

• Record the region, the currency and whether you were logged in when the snapshot was taken.
• Do not conclude that a price changed from one observation; confirm it on a later run or from a second source such as the documentation or the terms.
• Watch the plan comparison table as structured data; feature rows moving between columns often matter more than the headline price.
• Respect each site's terms of use and robots rules when collecting, and never use a logged-in account you are not entitled to.

Review before it reaches sales and product

A competitor change that lands in a battlecard or a roadmap discussion stops being a draft. If it is wrong, reps repeat it to customers and product teams react to something that did not happen. Put a review step between detection and distribution.

1. Batch the week's proposed change records by competitor.
2. For each one, a reviewer checks the evidence passage against the before and after text, then confirms or corrects the type and state.
3. Only confirmed records go into the weekly summary, with their sources.
4. Rejected records stay in the log with the reason, so the same false positive is recognized next time.

For turning confirmed changes into positioning and analysis, see competitor analysis with AI agents.

Where GoCux fits

GoCux does not crawl competitor sites. Pages enter the workspace through an authorized browsing or export step and keep their original address and retrieval date after import, which gives every change record a fixed point of reference. Pulse runs a recurring question over the sources you select; its definition, including what counts as a material change, is approved as one exact version, and each run is reviewed change by change without acting on anything by itself. Extraction pulls values such as plan limits from the captured material and attaches the supporting passage to each, leaving a value unknown when the page does not state it. Distributing a summary outside the team is one of the actions that pause for a person, which matches the review step above; the note on reviewing changes before they travel explains why that matters.

Checklist for competitor change alerts

• Your team agrees on the states: announced, preview, available, documented, priced.
• Watched surfaces include changelogs, docs or API references and pricing pages, not only the homepage and blog.
• Every watched page has a reviewed baseline with its address and retrieval time.
• Pages are normalized and compared by section; pricing tables and endpoint lists are compared as structured data.
• Each change record carries a type, a state, the before and after text, a quoted passage and a source.
• Pricing observations record region, currency and login state, and are confirmed before anyone reports them.
• A person confirms each record before it reaches a battlecard or a roadmap discussion.