Monitor competitor SaaS pricing pages and get structured plans, typed change alerts, and a decision-ready battlecard — not a wall of page text.

Point it at pricing URLs, or just give it a keyword ("project management software") and it auto-discovers the top competitor pricing pages itself.

Why this monitor

Most pricing trackers regex the page text and dump it. You get junk plan names, prices with no plan attached, and "changes" that are just copy edits. This actor extracts the actual plan cards:

{
  "name": "Pro",
  "amount": 8.75,
  "currency": "USD",
  "period": "month",
  "per_seat": true,
  "is_free": false,
  "is_custom_price": false,
  "features": ["Unlimited message history", "Group video calls", "..."],
  "cta": "Get Started"
}

…and diffs them statefully between runs, so you get typed events, each one answerable with an action:

Event	Fires when
price_changed	a plan's price moved — with old, new, % and direction
plan_added / plan_removed	the plan lineup changed
trial_changed	free trial appeared, disappeared, or changed length
annual_discount_changed	annual-billing discount appeared or changed
billing_period_changed	a plan switched monthly ↔ annual billing
features_changed	a plan's feature list materially changed
page_changed_unparsed	page changed but nothing structured moved (honest signal, never silent)

The first run on a URL bootstraps a baseline (no change events, no surprises). Every scheduled run after that emits only what changed.

Keyword auto-discovery (no URL paste)

Set keyword to your category and the actor finds the top competitor pricing pages via search (Google SERP when your account has the GOOGLE_SERP proxy group, otherwise Bing/DuckDuckGo), filters out review sites and "best X software" listicles, verifies each candidate is a live pricing page, and monitors them.

You can mix modes: pin your must-watch competitors in pricingPageUrls and let discovery fill the remaining slots up to maxCompetitors.

Battlecard

Each run can emit one competitive battlecard across all monitored pages:

• cheapest & priciest paid entry points, median entry price
• free-tier and trial matrix per competitor
• full plan matrix (name, price, period, per-seat)
• everything that changed this run, summarized
• positioning notes ("X has no trial and no free tier — friction opportunity")

Pipe it to Slack or your CRM via a webhook on the run, or schedule the actor weekly and read the battlecard as your Monday pricing brief.

Input

Field	Type	Notes
keyword	string	SaaS category for auto-discovery. Optional if URLs given.
pricingPageUrls	array	Public pricing page URLs. Optional if keyword given.
maxCompetitors	integer	Cap on pages per run (default 10, max 25).
emitBattlecard	boolean	One battlecard per run (default true).
eventTypes	array	Filter which change events to emit. Empty = all.
kvStoreName	string	Named KV store for state. Keep it stable across runs.
forceBrowser	boolean	Force managed-browser rendering (rarely needed — escalation is automatic).
proxyConfiguration	object	Apify Proxy; defaults to residential.

Output records

All records land in the default dataset with a record_type discriminator:

• snapshot — one per monitored page per run: plans, trial/discount signals, parse_confidence, extraction_method
• change_event — typed events as in the table above
• battlecard — one per run

Dataset views (Snapshots / Change events / Battlecard) are pre-configured in the Apify console.

How it parses (and why it's reliable)

1. Fast static fetch with TLS impersonation; JS-shell pages escalate automatically to a managed Camoufox browser render.
2. Plan cards are found structurally — repeated sibling card patterns in the DOM, not class-name guessing, not page-text regex. JSON-LD offers enrich the result when present.
3. Junk grids (FAQ accordions, feature-comparison tables) are rejected by per-grid quality scoring.
4. Every snapshot carries parse_confidence and extraction_method, and a degraded parse never fabricates plan-removal events — you get an honest page_changed_unparsed instead.

Pricing events

Event	Charged
pricing-snapshot	per pricing page successfully extracted
pricing-change-event	per typed change event emitted
battlecard-report	per battlecard generated

Failed pages are never charged. Baselines are charged as snapshots only — a first run never bills change events.

Scheduling

Typical setup: a weekly (or daily) schedule with your competitor set, a stable kvStoreName, and a webhook or integration reading the dataset. The actor is stateless between runs except for the named KV store, so you can fork configurations per product line by changing kvStoreName.

Legal

Only public pricing pages — no login, no paywall, no personal data. You own your runs and the extracted data. Monitoring public competitor pricing is standard competitive-intelligence practice; this actor reads nothing a regular visitor's browser wouldn't.

More scrapers from our toolkit

Building a data pipeline? These actors pair well with this one — each runs on your own Apify account with the same pay-per-result pricing, no subscription:

• Ambitionbox Reviews Scraper
• Indeed Employer Intelligence
• Meta Ads Library Scraper

Chain any of them together from the Integrations tab (the Run succeeded trigger) to build a multi-step workflow — one actor's output feeds the next.

Usage statistics

This Actor creates a small, content-free summary at the end of each run. It is used only to monitor reliability and improve this Actor. A copy is saved as USAGE_STATS in your own Apify key-value store, so you can see the exact record created for your run.

Set disableUsageStats to true in the input to opt out. Nothing is sent then; your USAGE_STATS record only says that statistics were disabled.

Only these fields are recorded:

• schema version, Actor name and build number;
• UTC start and finish hour (not a precise timestamp);
• run duration, number of results and time to the first result, each as a coarse range;
• whether the result was empty, the end status, and an error type from a fixed list;
• memory setting and counts of charged events;
• names of the input fields you set, never their values;
• the selected option for input fields that offer a fixed list of choices (for example a sort order).

We do not collect input text, search terms, URLs, domains, usernames, email addresses, names, proxy credentials, tokens, scraped records, output items, raw error messages, stack traces, or hashes of any of those values. Records are kept for no longer than 13 months, used only as aggregated operational statistics, and never sold or shared.

Additional fields (Phase 2)

This Actor also records your Apify user ID, whether Apify marks the account as paying, the size range of list inputs, the selected country when the input offers a fixed list of countries, and one category from a fixed Actor taxonomy. We use these fields only for aggregate reliability, repeat-use and cross-Actor analysis; reports suppress any cell with fewer than five distinct users.

The same disableUsageStats: true input flag turns these fields off too. The user ID is removed after 13 months; we do not export, sell, share, or attempt to re-identify this data.

Run-outcome signals (v2)

To learn whether a run did what it was asked to do, the record also holds a few more coarse ranges and yes/no flags. None of them contains content:

• the result limit you asked for (a range, when the input has one) and what share of it was delivered;
• results delivered per input item you listed (a range);
• output quality as ranges: how fully the result fields were filled, the share of rows that look like errors, the share of duplicate rows, and how many different fields appeared. These are counted in memory while results are saved; no result content is kept;
• how the run was started (console, API, schedule, webhook, another Actor);
• how it ended: stopped by you, timed out, reached the requested limit, stopped by the charge limit, and how many times the platform moved the run;
• if this Actor reports it: how many items to process worked or failed (ranges) and one failure reason from a fixed list;
• a short code made from the names of the input fields you set, never their values.

Repeat-run fingerprint (v2)

When your Apify user ID is recorded (see above), the record also holds an 8-character one-way code made from your input (proxy settings left out) and this Actor's name. It only lets us see that the same account ran the same input again soon after an unsatisfying run; we never see the input itself. It is stored only in the database, never published, and reports use it in aggregate with the same five-user minimum. It is the one exception to the statement above that no hashes are collected, and disableUsageStats: true turns it off.