Meta Ads Offer & Landing Page Tracker

Monitor active ads from Facebook Pages or advertiser-scoped Meta Ad Library URLs and observe their associated landing pages over time. It is for DTC/e-commerce teams, agencies, media buyers, and competitive-intelligence workflows that need reliable observed changes, not a generic Ad Library scraper.

The first compatible run creates a baseline and emits snapshots, never market-change events. Later compatible runs emit snapshots and/or changes according to outputMode. A change records an observation, not global commercial truth: A/B tests, country context, personalisation, blocking, and incomplete coverage can affect what is seen.

Inputs

• competitors: 1–50 Facebook Page URLs or advertiser-scoped Ad Library URLs. Labels are presentation-only, not identity.
• monitorName: stable state namespace for the monitor.
• countryCode, maxAdsPerCompetitor, trackLandingPages, maxLandingPages, outputMode, landingPageTimeoutSecs, and browserFallback have conservative defaults in the Input tab.

The Store health-check prefill is one public Nike Page with monitor name store-health-check-nike, countryCode: ALL, and both per-competitor and landing-page limits set to 1. It is an example for the Console only; the API defaults remain suitable for normal monitoring calls.

The supported events are NEW_AD, AD_COPY_CHANGED, LANDING_URL_CHANGED, PRICE_CHANGED, ORIGINAL_PRICE_CHANGED, DISCOUNT_CHANGED, and PRODUCT_CHANGED. AD_STOPPED, PRODUCT_REMOVED, ROAS/profitability, winning-ad scoring, creative AI analysis, and universal scraping are deliberately not supported.

Landing tracking removes known tracking parameters from identity, preserves functional parameters, fetches shared canonical landings once when known, and uses JSON-LD before structured and OpenGraph metadata. Failed, blocked, or ambiguous extraction never overwrites a confirmed commercial value. Consumers should de-duplicate retries using eventId; a later legitimate recurrence of the same before/after transition receives a new ID.

Output and pricing

The default Dataset contains SNAPSHOT and CHANGE records. RUN_SUMMARY in the default Key-Value Store reports coverage, warnings, child runs, landing statuses, and charge counters. Use Apify schedules and Dataset/webhook integrations for automation.

The configured PPE prices are US$0.05 per successfully fetched, contract-validated, normalized competitor and US$0.01 per unique conclusively checked landing (FOUND, NOT_PRESENT, AMBIGUOUS, or documented NOT_APPLICABLE). The synthetic apify-actor-start event is US$0.00005 per charged start (the count depends on allocated memory). Platform usage for this Actor is included in PPE. Failed, blocked, and extraction-failed landings are not charged; failed child runs, changes, and Dataset items are not separately charged by this Actor.

The upstream Facebook Ad Library Actor is a separate run in the user's account and adds its own current cost. Its limitPerSource may return and bill up to 30 additional records. Every child call receives a finite ceiling that accounts for that documented over-return. If a finite parent ceiling cannot accommodate the requested child coverage, the tracker reduces limitPerSource and reports UPSTREAM_BUDGET_LIMIT_REACHED. Parent and child spending limits are still separate Apify run limits.

This Actor is configured as PAY_PER_EVENT with included platform usage, the two custom events above, the synthetic start event, and no apify-default-dataset-item event. This repository's .actor/pay_per_event.json mirrors that saved Console configuration; deploying source does not itself change pricing.

This Actor is not affiliated with, endorsed by, or an official product of Meta.

Limitations

This Actor does not scrape Meta directly, has no residential proxy, dashboard, native Slack/email integration, visual analysis, or complete historical Ad Library coverage. It blocks private/internal HTTP(S) targets and caps redirects, body size, and timeouts. Browser fallback is intentionally isolated to the final landing host, so sites that require cross-domain assets can remain incomplete rather than weaken URL safety. Do not overlap runs that use the same monitorName; concurrent observations can race on shared state.