CTA Destination Regression Monitor — Signup, Checkout & Demo Links

Monitor the declared destinations of visible, English-language commercial calls to action on one public page. The Actor establishes an accepted baseline, runs safely on an Apify schedule, and reports removed or disabled controls, placeholders, missing fragments, changed destinations, and bounded HTTP failures.

This Actor does not click controls, submit forms, log in, purchase anything, or verify that a checkout or signup completes. It monitors the public CTA and destination layer only.

Buyer workflow

1. Run discover with a public URL and a stable watchId.
2. Review every detected CTA in observedCtas.
3. Run lock_baseline explicitly with the same URL and watchId.
4. Save a new Apify Task with mode set to check.
5. schedule the Task daily or weekly without overlapping runs.
6. Route dataset results through an Apify-native webhook or integration if alerts are needed.

The first baseline run never emits a regression. A baseline is never learned or changed automatically. Replacing one requires replace_baseline plus the exact current baseline hash.

What counts as an alert

The default requires the same conclusive change in two consecutive checks. This prevents a single transient failure from being called confirmed.

• confirmed_regression: a removed or disabled CTA, placeholder target, changed declared destination, missing fragment, or completed 4xx/5xx route probe persisted for the configured confirmation count.
• recovered: every monitored dimension returned to the locked baseline for the configured confirmation count.
• inconclusive: an access challenge, duplicate semantic CTA label, timeout, rate limit, probe failure, route cap, robots/nofollow skip, or incomplete removal evidence. Inconclusive runs never close an open incident.

CTA identity uses normalized intent and label, never the destination or DOM position. Destination changes therefore remain attached to the same CTA. If duplicate normalized labels make that identity ambiguous, the Actor reports inconclusive instead of inventing a match.

State and billing safety

• Persistent state lives in the caller's named revenuepath-watch-state key-value store. Normal Apify users therefore keep isolated state under limited Actor permissions.
• The URL and watchId are hashed into the record namespace; one watch cannot read another watch's pointer.
• Each state revision is immutable behind a small pointer record.
• The PPE event is completed-watch-check. Production code verifies that the event is registered and that one event remains within the caller's limit before scanning.
• The result is pushed and its event accepted before state advances. A rejected charge performs no state write.
• Apify key-value storage has no atomic compare-and-swap. Pre- and post-charge revision checks reduce overlap races, but exactly-once alerts cannot be promised. Keep schedules non-overlapping; a crash or final write race can repeat an alert.
• x402 and Skyfire calls should be treated as one-shot checks unless the caller supplies a durable normal Apify identity and schedule.

The Store price is $0.10 for one accepted completed-watch-check event, plus a one-time $0.00005 Actor Start event per run. Platform usage is not separately passed through to the user.

Safety boundary

The scanner accepts public HTTP/HTTPS targets on ports 80/443, rejects credentials and private/reserved network addresses, pins resolved addresses for direct probes, honors robots rules, blocks non-GET/HEAD browser traffic, and limits routes, bytes, redirects, and runtime. It does not claim lost revenue, full transaction coverage, or security-vulnerability detection.

Local verification

$npm test

The suite covers browser extraction, full healthy inventory capture, explicit baseline locking, six controlled regression classes, transient suppression, recovery, inconclusive handling, ten unchanged page variants across three repetitions, semantic identity, duplicate ambiguity, URL/watch isolation, stale-writer rejection, PPE registration, charge-before-state ordering, and pre/post-charge conflict behavior.