Skip to main content
Build a comparison that readers can check against the original pages. Start with a reviewed competitor list, extract a consistent set of facts, then compare only compatible plans, units, and markets. Context.dev provides source discovery, page content, structured extraction, and change monitoring. Competitor selection, strategic analysis, and the comparison interface belong to your application.

Review the comparison scope

Accept a list of product or company URLs, or use Search to propose candidates. Confirm their identities and relevance before adding them to the comparison. A similar name or a search result alone does not establish that two products compete. Write down the comparison question, geography, and intended product variant. For a pricing comparison, collect both the displayed billing basis and any conditions such as annual commitment, seat minimums, usage tiers, promotions, or taxes.

Extract a fixed set of facts

Use a server-side key from the Quickstart. Read selected pricing or product pages with Markdown, or send the following body through Extract. The extraction guide includes cURL and every SDK.
Extract request body
Name the intended plan in instructions when the page contains several. Use nullable fields and factCheck: true to keep unsupported information unknown. Store urls_analyzed, the original extracted values, cache metadata, and the time the request completed. The analyzed URLs describe the request’s evidence set. For a claim that needs an exact source, verify a supporting excerpt and retain the specific URL with that field. Review partial coverage and blocked-page counts before accepting a row.

Normalize without hiding commercial differences

Convert the raw result into a reviewed application model. Keep annual commitments and monthly billing in different groups, even when both pages display a monthly equivalent.
comparison.ts
Assign normalized fields such as market and variant only after review. The grouping function is conservative: identical keys identify rows eligible for further comparison, not proof that their features or service levels are equivalent. Keep rows without a group visible as incomplete rather than ranking them as the cheapest offer. If you convert currency, save the exchange-rate source, date, and original amount. If you normalize a package price, retain the package quantity and the conversion rule. A simple comparison can avoid these conversions and show the original prices with their stated basis.

Separate facts from interpretation

Render a table with the plan, observed price, commercial conditions, source link, observation time, and freshness state. Keep analytical conclusions in a separate section that cites the rows it uses. A generated opinion should not be written back into extracted-fact fields. This workflow also does not supply SEO or GEO visibility metrics, ranking lift, or a validated competitor ranking; those require separate data and analysis.

Refresh and review changes

Use Monitors on the reviewed source pages, or run intentional periodic extractions. A detected change can queue a new observation for the affected row. Compare it with the previous snapshot before accepting changes to plan identity, currency, or billing basis. Store attempts independently from accepted facts, as in the dataset workflow. A timeout must not erase the last known price or be described as a price removal. Try two compatible offers, one annual-commitment offer, an unstated price, and a failed refresh. Check that only compatible rows share a group, every fact has a source and time, and no interpretation appears as an extracted fact.

Structured datasets

Persist observations and refresh records without duplicates.

Website change digests

Turn source changes into a reviewable research feed.