Shopify Price Change Monitor

Watch bounded public snapshots of Shopify or possibly-Shopify stores and review observed changes in platform detection, product count, price range, currency, and a clearly labelled heuristic revenue band. This is store-level competitor research, not per-SKU history, a full-catalog guarantee, or merchant revenue data. The scanner runs in-process: no child Actor and no hidden second Actor charge.

What you get

• A named buyer-scoped watch that remembers the last comparable bounded store snapshot.
• Every scheduled run reports ONLY what changed — a store newly added to the watch, or an already-tracked store's observed price range, product count, currency, Shopify detection, or heuristic revenue band shifting.
• Coverage travels with the row. A large public catalog is scanned up to 750 products; productCountIsLowerBound=true, catalogCoverage="partial", a confidence risk, and FULL_PUBLIC_CATALOG_COVERAGE prevent that bounded observation from looking exact.
• A temporary products-feed or later-page failure cannot be sold as a catalog collapse. The previous comparable store state is preserved and the run emits a free source notice.
• A best-effort KVS lease covers baseline read, scan, paid delivery, and state commit. Detected overlap returns a free WATCH_BUSY notice; keep schedules for one watch_name non-overlapping because named KVS does not provide transactional exactly-once delivery.
• Add or drop stores from your watch at any time — a new store gets its own "just started tracking this one" moment, and a dropped store gets an honest (free) notice, never billed.
• Runs on Apify: schedule it, monitor it, call it from the API, export to JSON/CSV/Excel or push straight into your own pipeline.

How to run it

1. Click Try for free and inspect the current Apify plan and live event prices.
2. Paste the store URLs you want watched into Websites, optionally a name for this watch.
3. Hit Start. Schedule it to run again (daily or weekly) to get a stream of only the CHANGES each time.

Pricing

Pay-per-event under the currently published six-tier contract: $0.005–$0.004 per Actor start and $0.01–$0.008 per delivered new/changed store, depending on the buyer's Apify tier. A store DROPPED from your watch list is reported for visibility but never charged — it's your own choice to stop tracking it, not new information about the store. The "no changes" notice on a quiet run and any error/notice row are also never charged. At the highest published prices, 10 delivered changes cost $0.105 in events: one $0.005 start plus ten $0.01 result events. The live Pricing tab is authoritative.

Input

Field	Required	What it does
websites	yes	Public store URLs to watch, e.g. "allbirds.com". Up to 100 submitted values; equivalent forms of one normalized hostname are checked once.
watch_name	no	Stable buyer-scoped baseline namespace. Separate portfolios need separate names. Keep schedules for one name non-overlapping; detected overlap returns free WATCH_BUSY.
max_items	no	Max new/changed-store rows delivered (and charged) per run (1-200, default 20).

Migration: older API clients and saved Tasks may still send baseline_key. Runtime accepts that legacy alias only when watch_name is absent, preserving the same stored baseline. New integrations should use watch_name; an explicitly empty watch_name selects the documented fallback and never revives a legacy value.

{
    "websites": ["allbirds.com", "gymshark.com"],
    "watch_name": "dtc-competitors",
    "max_items": 10
}

Source and coverage contract

The Actor requests public first-party storefront HTML plus public /products.json and /collections.json endpoints. HTTP is bounded by DNS SSRF checks, pinned public addresses, redirect limits, timeouts, and response-size limits. The product scan requests at most three pages of 250 products. Therefore:

• catalogCoverage="complete" means the bounded public product-feed scan reached its end;
• catalogCoverage="partial" means the known 750-product scan limit was reached;
• an interrupted later catalog page is catalogCoverage="unavailable", preserves the prior comparable baseline, and produces a free source notice rather than a paid apparent collapse;
• productCountIsLowerBound=true means the row observed at least that many products, not that the merchant has exactly that many products;
• priceMin and priceMax cover observed public product variants only;
• revenueBand is a low-confidence heuristic derived from observed catalog characteristics;
• inaccessible public product data is an operational gap, not zero products and not a paid competitor change.

The Actor does not log in, bypass storefront access controls, inspect orders, inventory, customers, analytics, traffic, conversion, or private Shopify administration data. It is an independent tool and is not affiliated with, endorsed by, or sponsored by Shopify.

Baseline state, concurrency, and privacy

One compact comparison envelope is stored in the named shopify-price-change-monitor-baseline Key-Value Store available to the account running the Actor. It contains public store snapshot fields, observation time, and short hashed lease or delivery-hold records. It does not retain fetched HTML, full product rows, cookies, credentials, customer records, or an Apify token. Named storage persists according to the caller's Apify storage settings; delete the record/store when the watch is no longer needed. Do not put secrets or unnecessary personal data in websites or watch_name.

Only a genuinely missing record starts a new baseline. A malformed, foreign, or delivery-held non-null record fails closed before scanning or paid delivery. If delivery or charging becomes ambiguous, or a paid row cannot be committed to baseline state, automatic paid retries are held until the prior run is reconciled. Use a new watch_name only when you intentionally want a new first-observation series; it is not a way to pretend histories are comparable.

Output

Historical new-store row from a real 30.07.2026 run. That release observed the same 750-product bound but did not yet expose the additive coverage fields; the current contract adds them and lowers confidence when the snapshot is partial:

{
    "baselineKey": "selftest-shopify-1",
    "found": true,
    "changeType": "new-store",
    "url": "https://www.allbirds.com/",
    "isShopify": true,
    "priceMin": 3,
    "priceMax": 160,
    "currency": "USD",
    "productCount": 750,
    "revenueBand": "$10M+",
    "error": "",
    "summary": "\"https://www.allbirds.com/\" added to watch \"selftest-shopify-1\" — Shopify store, 750 product(s), price range USD3–160."
}

Changed-store row (real output, live run 30.07.2026 — reflects a real detected shift back to the store's true price range after a synthetic test mutation):

{
    "baselineKey": "selftest-shopify-1",
    "found": true,
    "changeType": "changed-store",
    "url": "https://www.allbirds.com/",
    "isShopify": true,
    "priceMin": 3,
    "priceMax": 160,
    "currency": "USD",
    "productCount": 750,
    "revenueBand": "$10M+",
    "error": "",
    "summary": "\"https://www.allbirds.com/\" changed for watch \"selftest-shopify-1\": priceMax 99999 -> 160."
}

Field	Meaning
baselineKey	Which watch this row belongs to.
found	true for a real result row (new or changed store); false for a notice/error row.
changeType	"new-store", "changed-store", or null for a notice row.
url, isShopify, priceMin, priceMax, currency, productCount, revenueBand	Backward-compatible observed store fields. Read them with coverage and heuristic gaps.
productsAccessible, catalogCoverage, catalogComplete, catalogScanLimit, catalogTruncatedReason	Public product-feed availability and bounded-scan coverage.
productCountIsLowerBound, partial	Prevent a capped observed count/range from being treated as full-catalog proof.
before, after, changedFields, changeFlags	Exact observed transition values and normalized change labels.
confidenceScore, confidenceBand, confidenceRisks, dataGaps	Evidence support and what the bounded scan or heuristic cannot establish.
recommendedAction, actionPriority, safeToAutomate	Manual review routing; safeToAutomate stays false.
failureType, retryable	Distinguishes source, baseline, budget, and WATCH_BUSY recovery paths.
error	Empty string when the check completed cleanly (including "nothing changed" and "a store was dropped"); non-empty only on a real problem.
summary	Human-readable one-liner.

Other tools we built

Related tools

Related tools for adjacent workflows in e-commerce.

Actor	What it does
Zid Store Products Scraper	Pair it in the e-commerce workflow: Pull live product catalogs (name, price, sale price, category, image) straight from Zid storefronts — a...
Chotot Vietnam Listings Scraper	Pair it in the e-commerce workflow: Pull live classified ad listings (real estate, vehicles, electronics, jobs and more) straight from...
Shopify Store Intelligence	Pair it in the e-commerce workflow: Confirm a site runs on Shopify and pull store intelligence from its public feeds — product count, price...

FAQ / Limitations

Does this track individual product prices? No — this tracks store-level signals (price RANGE across the catalog, product count, a rough revenue band), not per-SKU price history. If you need per-product tracking, this is not that tool.

What happens if I change my websites list? A newly added store gets its own "first time tracked" moment; a removed store gets an honest, free notice and stops being compared going forward.

What this is NOT. The revenue band is a rough heuristic from the observed bounded catalog and observed average price, not real sales data. A 750-product row is normally a lower bound, not the full catalog size. Treat both as research context, not a forecast.

Can I overlap the same watch in two schedules? Do not design the schedule that way. If overlap is detected, a hashed KVS lease lets one run hold baseline read, scan, delivery, and commit while the other returns a free WATCH_BUSY result. The named KVS does not provide a transactional compare-and-swap primitive, so this is a best-effort guard, not a contractual exactly-once guarantee. Keep schedules for the same watch_name non-overlapping. Different watch names remain independent.

Why is my watch held after an error? A delivery/charge outcome or paid baseline commit became ambiguous. The Actor retries a durable hold and, if that write still fails, attempts to retain the active lease before failing the run. A total KVS write outage cannot create a durable exactly-once guarantee. Inspect the prior run and retained state before retrying; if you deliberately start a new history, use a new watch name.

Found a bug or need per-SKU tracking? Issues on the Actor's page.

Commercial guide: Shopify Store Price and Catalog Change Monitor

Watch bounded public store snapshots for observed price range, product-count, currency, platform-detection, and heuristic revenue-band changes with explicit coverage, baselines, evidence, and failure holds.

This guide is written for buyers, operators, analysts, and automation builders. It explains what the Actor observes, how to turn the Dataset into a controlled workflow, and where human verification remains mandatory.

The decision this product supports

Which watched store-level metrics changed since the prior comparable observation, and which changes deserve manual competitor-pricing or catalog research?

The Actor reduces collection and first-pass triage work. It does not remove responsibility for source verification or authorize an external business action. The commercial value comes from a structured, repeatable evidence layer: stable identity, observation time, source evidence, confidence, gaps, recommended action, and failure semantics travel with the raw facts.

Who uses it

User	Value
DTC founders	Track a compact set of competitor stores for broad price-positioning and catalog movement.
Ecommerce marketers	Receive change-only rows instead of repeatedly comparing store snapshots by hand.
Agencies	Operate named client watches and deliver evidence, materiality, limitations, and action together.
Pricing analysts	Review catalog-wide min/max movement while understanding that this is not per-SKU price history.
Sales operations	Use Shopify detection and catalog signals for research without presenting heuristic revenue as fact.
Automation builders	Schedule bounded store lists and deduplicate state transitions by entityId and eventId.

Input contract

Input field	How to use it
websites	Required list of up to 100 Shopify or possibly-Shopify public store domains/URLs.
watch_name	Stable baseline namespace for one store portfolio and methodology. Use a new name for an intentionally different watch.
max_items	Maximum new-store or changed-store rows delivered and billed per run, from 1 to 200.

Recommended first Input

{
  "websites": [
    "allbirds.com",
    "gymshark.com"
  ],
  "watch_name": "dtc-competitors",
  "max_items": 10
}

Start with this bounded example, inspect every Dataset field, and only then expand the scope. Input limits are product controls, not inconveniences: they make cost, completeness, and error handling visible.

Field dictionary

Field or group	Meaning
entityId, eventId, baselineKey, url	Stable store/watch and monitor-event identity plus direct store reference.
changeType, changedFields, before, after, changeFlags	New-store, changed-store, no-change, removed-input, and exact transition semantics.
isShopify, priceMin, priceMax, currency, productCount	Current bounded public catalog observation; productCount is not automatically a full-catalog total.
productsAccessible, catalogCoverage, catalogComplete, catalogScanLimit, productCountIsLowerBound	Whether the public product feed was usable and whether the 750-product bounded scan is complete or a lower bound.
revenueBand	Rough heuristic derived from public catalog characteristics, never observed merchant revenue.
priceChanges, materialityScore, materialityBand	Explicit price-range deltas and weighted change significance.
observedAt, firstSeenAt, lastSeenAt, previousObservedAt	Stateful observation timing.
confidenceScore, confidenceBand, confidenceRisks	Evidence support for the store snapshot/change statement, separate from materiality.
sourceEvidence, negativeSignals	Store URL observation and platform/failure caveats.
recommendedAction, actionPriority, actionReason, safeToAutomate	Manual competitor-research routing.
failureType, retryable, recommendation	Baseline, source, and budget recovery guidance.

Common decision fields

Field	Operational meaning
recordType	The semantic row family. Use it to distinguish a business result from an advisory or terminal record.
schemaVersion	Version of the additive decision-intelligence contract. Pin or validate it in strict consumers.
entityId	Stable entity identity for deduplication and joins. It is not necessarily a legal identifier.
inputRef	The relevant submitted input reference after normalization.
observedAt	When the Actor observed or finalized the evidence. It is not necessarily the source publication time.
firstSeenAt and lastSeenAt	Always-emitted observation boundaries. Stateful monitors use the compatible baseline/current boundary. Stateless rows set both equal to observedAt for the current run; that equality does not establish historical tenure.
freshness	A structured statement about evidence age or availability, not a prediction. Its basis and age unit follow the source-specific field definition.
eventId	For monitors, the stable identity of one observed transition or monitor outcome. It is distinct from entityId.
before and after	For monitors, the bounded comparable snapshots used for the decision. Null means that side of a comparison was not honestly available.
changedFields and changeFlags	Machine-readable monitor deltas and normalized change labels. Empty arrays mean no supported changed field was established, not that every possible real-world fact stayed constant.
materialityScore and materialityBand	Magnitude of an observed monitor change when the Actor can calculate it. Materiality is separate from evidence confidence and may be unknown when the source lacks the required facts.
confidenceScore	Evidence support on a 0–100 scale. It is separate from materiality, lead score, or business value.
confidenceBand	Readable high/medium/low/unknown grouping of evidence support.
confidenceReasons	Observed facts that raise confidence.
confidenceRisks	Missing, partial, ambiguous, inferred, or conflicting aspects that reduce confidence.
confidenceConflict	Explicit consistency warning when structured evidence does not reconcile.
sourceEvidence	Source-linked observations supporting the row. Preserve this during export.
dataGaps	Important evidence the Actor did not observe or cannot establish. Keep these gaps visible in CRM, spreadsheet, and automation exports.
negativeSignals	Machine-readable risks or gaps. A negative signal is not automatically a negative business outcome.
recommendedAction	Bounded review label produced from the available evidence.
actionPriority	Suggested queue priority, not urgency guaranteed by the source.
actionReason	Plain-language explanation for the recommended action.
safeToAutomate	Whether the narrow recommended action is deterministic enough for automation. Organizational policy still applies.
failureType	Normalized terminal or partial failure classification. Null means no classified failure.
retryable	Whether a later retry may legitimately change an operationally incomplete result.
recommendation	Human-readable handling guidance, especially for terminal rows.

Evidence, confidence, and honest boundaries

What the evidence supports

• A new-store row is the first observed state for a store within this watch, not evidence that the store itself is newly launched.
• A changed-store row compares the same normalized store-level fields with the prior valid watch baseline.
• Price values are catalog-wide observed range values rather than product-specific history.
• A capped snapshot exposes partial coverage, a lower-bound product count, reduced confidence, and a full-catalog data gap rather than looking exact.
• A transient unreadable products feed or interrupted later catalog page preserves prior state and creates a free source notice; it cannot be sold as a catalog collapse.
• The watch lease is acquired before baseline read and renewed through scanning, paid delivery, and state commit; detected overlap returns a free WATCH_BUSY row.
• Equivalent URL forms for one normalized hostname are scanned once, and duplicate normalized identities in a stored baseline fail closed before paid work.
• An incomplete legacy baseline is replaced by the next comparable observation without billing that recovery as a new-store or changed-store event.
• A negative Shopify-marker result remains medium-confidence detection evidence with an explicit positive-platform-confirmation gap; it is not migration proof.
• Malformed, foreign, or delivery-held baseline state fails closed before the store scan or paid work.
• Removing a URL from the submitted watch creates a free visibility notice, not a claim that the store closed.
• Revenue band remains explicitly heuristic and cannot inherit the confidence of directly observed catalog fields.

What this Actor never claims

• The Actor does not track individual SKU price history, inventory, discounts, sales volume, orders, traffic, conversion, profit, or real revenue.
• A 750-product observation does not prove the full catalog contains exactly 750 products or that observed min/max values cover unobserved products.
• The KVS contender lease is a best-effort overlap guard rather than a transactional exactly-once guarantee; schedules for the same watch should not overlap.
• It does not prove a price strategy, promotion, product launch, store closure, merchant intent, or future change.
• It is independent and is not affiliated with, endorsed by, or sponsored by Shopify.
• A site not currently detected as Shopify is not proof that the merchant ceased operating.
• It does not recommend automatic repricing or business decisions.

Reading data gaps correctly

A data gap is part of the result. Nulls, partial flags, confidence risks, source failures, and unavailable fields must survive export. Removing these fields makes the remaining facts look more complete than they are. When two sources conflict or a required identity cannot be proven, lower confidence and keep safeToAutomate=false.

Source evidence is not permission

A public source proves only that a value or statement was observable at the recorded time and URL. It does not establish consent, contractual rights, legal status, accuracy after observation, or authorization for a downstream action. Your organization remains responsible for source terms, privacy rules, outreach policy, retention, and human review.

Decision policy and action routing

Action	How to use it
REVIEW_NEW_WATCHED_STORE	Treat the row as the store baseline and validate current catalog context.
REVIEW_PRICING_OR_CATALOG_CHANGE	Inspect changed fields and the store before updating a competitor brief or pricing hypothesis.
NO_CHANGE	Keep the quiet outcome without generating a task.
REVIEW_WATCH_LIST_REMOVAL	Confirm that the input portfolio change was intentional.
REPAIR_BASELINE_STATE	Restore comparable state before interpreting transitions.
BASELINE_RECOVERED_NO_ACTION	Record the free state recovery; the current observation is now the comparison point for future runs.
WAIT_FOR_ACTIVE_WATCH	Let the run already holding this watch finish; the losing run has no result-event charge.
RETRY_SOURCE_CHECK	Retry only temporary source failures.

Confidence is not attractiveness

confidenceScore answers “how strongly does the available evidence support this factual classification?” It does not answer “how valuable is this lead, property, account, or address?” A high-confidence negative fact may be commercially uninteresting; a low-confidence positive signal may deserve research but not action. Keep the concepts separate in dashboards, exports, and CRM fields.

Why safeToAutomate is conservative

safeToAutomate is intentionally false whenever the next step could amplify an uncertain inference. It may be true only for narrow deterministic actions explicitly supported by the row, such as suppressing an email with invalid syntax. A true value does not waive legal, privacy, consent, contractual, or organizational rules.

Retry policy

• Retry when retryable=true and the failure is operational, such as a temporary source or DNS problem.
• Do not endlessly retry deterministic invalid input, policy refusal, or confirmed absence.
• A retry must preserve the original input reference and must not create duplicate downstream actions.
• Budget exhaustion is not negative evidence about the entity. Resume only the unprocessed scope with an authorized budget.
• A failed Actor run is an operational event. Never transform it into “no listing,” “no contact,” “bad lead,” or “invalid email.”

Commercial use-case playbooks

1. DTC weekly watch

Goal. Track five to ten stores, review price-range and product-count shifts, and validate at source.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that observed fields in a bounded public store snapshot changed within the same named watch after a comparable baseline. Coverage fields decide whether product count and price range describe a complete public feed or only the observed subset. It does not prove per-SKU pricing, sales, revenue, inventory, strategy, intent, or commercial impact.

2. Catalog expansion signal

Goal. Route productCount growth into research while avoiding claims about launches, inventory, or sales.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that observed fields in a bounded public store snapshot changed within the same named watch after a comparable baseline. Coverage fields decide whether product count and price range describe a complete public feed or only the observed subset. It does not prove per-SKU pricing, sales, revenue, inventory, strategy, intent, or commercial impact.

3. Price-positioning brief

Goal. Compare min/max ranges as a coarse catalog signal and use a separate SKU workflow for product-level decisions.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that observed fields in a bounded public store snapshot changed within the same named watch after a comparable baseline. Coverage fields decide whether product count and price range describe a complete public feed or only the observed subset. It does not prove per-SKU pricing, sales, revenue, inventory, strategy, intent, or commercial impact.

4. Platform migration research

Goal. Review isShopify transitions manually and do not equate detection failure with store closure.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that observed fields in a bounded public store snapshot changed within the same named watch after a comparable baseline. Coverage fields decide whether product count and price range describe a complete public feed or only the observed subset. It does not prove per-SKU pricing, sales, revenue, inventory, strategy, intent, or commercial impact.

5. Agency client report

Goal. Deliver only changed rows plus watch scope, observation time, confidence, and the revenue-band limitation.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that observed fields in a bounded public store snapshot changed within the same named watch after a comparable baseline. Coverage fields decide whether product count and price range describe a complete public feed or only the observed subset. It does not prove per-SKU pricing, sales, revenue, inventory, strategy, intent, or commercial impact.

6. CRM account context

Goal. Store changes in an event table and require human review before adding narrative to an account.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that observed fields in a bounded public store snapshot changed within the same named watch after a comparable baseline. Coverage fields decide whether product count and price range describe a complete public feed or only the observed subset. It does not prove per-SKU pricing, sales, revenue, inventory, strategy, intent, or commercial impact.

7. Portfolio maintenance

Goal. Audit removed-input notices so accidental watch-list edits do not disappear silently.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that observed fields in a bounded public store snapshot changed within the same named watch after a comparable baseline. Coverage fields decide whether product count and price range describe a complete public feed or only the observed subset. It does not prove per-SKU pricing, sales, revenue, inventory, strategy, intent, or commercial impact.

8. Failure quarantine

Goal. Branch baseline, source, and budget outcomes away from no-change reporting and retry only eligible cases.

Recommended runbook.

1. Define the submitted cohort and write down why it is in scope.
2. Start with the smallest useful Input and preserve the exact run ID.
3. Inspect the Dataset overview before exporting anything.
4. Check failureType, retryable, completeness indicators, and confidenceBand.
5. Open the relevant sourceEvidence or source URL for material rows.
6. Apply the recommended action as a review label, not as an instruction to contact, buy, delete, accuse, or publish.
7. Record the analyst's final disposition in the destination system.

Do not skip. A change row proves that observed fields in a bounded public store snapshot changed within the same named watch after a comparable baseline. Coverage fields decide whether product count and price range describe a complete public feed or only the observed subset. It does not prove per-SKU pricing, sales, revenue, inventory, strategy, intent, or commercial impact.

Integration recipes

All examples use placeholders. Keep the Apify token in a secret manager and never write it into a Dataset, README, screenshot, or client-side application.

cURL: start a run and wait briefly

curl -sS -X POST 'https://api.apify.com/v2/acts/zinin~shopify-price-change-monitor/runs?waitForFinish=60' \
  -H "Authorization: Bearer $APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  --data '{"websites":["allbirds.com","gymshark.com"],"watch_name":"dtc-competitors","max_items":10}'

The run response includes defaultDatasetId. Read clean JSON rows with:

curl -sS "https://api.apify.com/v2/datasets/$DEFAULT_DATASET_ID/items?clean=true&format=json" \
  -H "Authorization: Bearer $APIFY_TOKEN"

JavaScript with apify-client

import { ApifyClient } from 'apify-client';

const client = new ApifyClient({ token: process.env.APIFY_TOKEN });
const input = {
  "websites": [
    "allbirds.com",
    "gymshark.com"
  ],
  "watch_name": "dtc-competitors",
  "max_items": 10
};
const run = await client.actor('zinin/shopify-price-change-monitor').call(input);
const { items } = await client.dataset(run.defaultDatasetId).listItems({ clean: true });

for (const row of items) {
    console.log({
        entityId: row.entityId,
        confidenceBand: row.confidenceBand,
        recommendedAction: row.recommendedAction,
        safeToAutomate: row.safeToAutomate,
        failureType: row.failureType,
    });
}

Python with apify-client

import os
from apify_client import ApifyClient

client = ApifyClient(os.environ["APIFY_TOKEN"])
run = client.actor("zinin/shopify-price-change-monitor").call(run_input={
    "websites": [
        "allbirds.com",
        "gymshark.com"
    ],
    "watch_name": "dtc-competitors",
    "max_items": 10
})

for row in client.dataset(run["defaultDatasetId"]).iterate_items(clean=True):
    print({
        "entityId": row.get("entityId"),
        "confidenceBand": row.get("confidenceBand"),
        "recommendedAction": row.get("recommendedAction"),
        "safeToAutomate": row.get("safeToAutomate"),
        "failureType": row.get("failureType"),
    })

Apify MCP call

{
  "name": "call-actor",
  "arguments": {
    "actor": "zinin/shopify-price-change-monitor",
    "input": {
      "websites": [
        "allbirds.com",
        "gymshark.com"
      ],
      "watch_name": "dtc-competitors",
      "max_items": 10
    }
  }
}

Generic webhook consumer policy

1. Trigger on a terminal Actor run event.
2. Confirm the run status is SUCCEEDED before reading business rows.
3. Retrieve rows from defaultDatasetId.
4. Reject or quarantine rows whose failureType is non-null unless your policy explicitly handles that failure.
5. Send safeToAutomate=false rows to a human-review queue.
6. Store entityId, observedAt, sourceEvidence, confidence, action, and the Apify run ID together.
7. Make retries idempotent by keying the destination on the stable entity ID plus the intended observation or event identity.

Where this fits in a practical stack

Destination	Recommended pattern
Apify Console	Use the visual Input form, start the run, then open the default Dataset overview. This is the fastest path for a one-off review and the best place to inspect evidence before automating anything.
Apify API	POST JSON input to the Actor run endpoint, wait or poll for completion, then read the default Dataset through the URL returned by the run object.
JavaScript client	Use apify-client from a Node.js service, pass the same JSON object as the Console Input, and preserve the returned run and Dataset IDs in your own audit log.
Python client	Use apify-client in a Python enrichment job, iterate Dataset items, and route rows by recommendedAction, confidenceBand, failureType, and retryable.
Make	Start the Actor from a scenario, wait for the run, retrieve Dataset items, filter unsafe or low-confidence rows, then insert review-ready rows into the destination application.
Zapier	Use an Apify run action or webhook trigger, fetch Dataset items, apply a Filter step, and send only review-approved fields into the next sales or operations step.
n8n	Use HTTP Request or Apify nodes, branch on failureType and retryable, keep a manual-review lane for safeToAutomate=false, and write sourceEvidence together with the business fields.
Google Sheets	Export the Dataset directly or append rows from an automation. Keep stable entityId as a hidden key so reruns update the correct record instead of creating ambiguous duplicates.
Airtable	Map entityId to a primary or deduplication field, store confidence and evidence in separate columns, and expose recommendedAction as the triage view.
Webhook	Configure an Apify webhook for terminal run states, retrieve the Dataset after SUCCEEDED, and treat FAILED or TIMED-OUT runs as operational events rather than negative business evidence.

A safe automation shape

The Actor is a collection and decision-support component. A production workflow should keep raw evidence, decision metadata, and business action in distinct layers:

1. Collect: run the Actor with explicit bounded input.
2. Validate: require a successful run and schema-valid Dataset rows.
3. Triage: branch on failureType, retryable, confidenceBand, and safeToAutomate.
4. Review: open source evidence for rows that may affect a person, campaign, investment, compliance decision, or customer record.
5. Act: execute only the action approved by your own policy and authorized operator.
6. Audit: retain run ID, Dataset ID, observation time, input reference, source evidence, and the final human decision.

This separation prevents a common automation error: turning “data was observed” into “a business action is justified.”

Operating guide

Before the first production run

1. Write the business question in one sentence: Which watched store-level metrics changed since the prior comparable observation, and which changes deserve manual competitor-pricing or catalog research?
2. Confirm every submitted input is within your authorized scope.
3. Use the prefilled small example and review all returned row types.
4. Map stable identifiers, confidence, evidence, actions, gaps, failure, and retry fields into the destination.
5. Establish a human owner for review exceptions.
6. Set a run budget and output bound appropriate to the test.
7. Verify that secrets are stored only in the platform or workflow secret manager.

After every scheduled run

1. Check terminal run status and logs.
2. Compare the number of submitted entities, produced business rows, and advisory rows.
3. Review partial, unknown, conflict, and low-confidence buckets.
4. Inspect a sample of source evidence, including at least one positive and one negative result.
5. Confirm the destination deduplicated on the intended stable key.
6. Verify that no downstream action was triggered from an error row.
7. Track cost per useful reviewed row rather than cost per raw request alone.

Production monitoring signals

Monitor source-unavailable rate, partial-row rate, low-confidence share, missing evidence, retry volume, run duration, Dataset row count, and spend. A sudden shift may indicate source drift, input drift, or an upstream outage. Stop automation and investigate before accepting a new pattern as business truth.

Cost control

Start with one or two stores and max_items=5, inspect the first-state rows and catalog coverage, then rerun unchanged without overlap. Confirm no-change/removal/WATCH_BUSY billing and live tier prices before scheduling a larger portfolio.

Use maxTotalChargeUsd when calling a monetized Actor if your workflow supports it. Treat a buyer-set cap as a hard safety boundary. If the cap stops work, the unfinished items remain unprocessed; they do not become negative results.

Review templates and quality reporting

Row-review worksheet

For every material row, an analyst should be able to answer the following without relying on memory or an unstated assumption:

1. What submitted entity or query does this row refer to?
2. Is it a business result, a baseline/advisory row, a partial observation, or a failure?
3. Which exact source evidence supports the headline fact?
4. When was the evidence observed, and is there a different source publication time?
5. Which fields are direct observations, which are normalized, and which are deterministic derivations?
6. What important evidence is null, missing, partial, ambiguous, or conflicting?
7. Does confidence describe evidence support only, or has someone incorrectly treated it as business value?
8. What recommended action is present, and what additional verification does its reason require?
9. Is the narrow action marked safe to automate? If yes, does organizational policy also permit it?
10. What final human disposition was made, by whom, and from which run and Dataset item?

Field-group review prompts

1. entityId, eventId, baselineKey, url

Contract meaning: Stable store/watch and monitor-event identity plus direct store reference.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

2. changeType, changedFields, before, after, changeFlags

Contract meaning: New-store, changed-store, no-change, removed-input, and exact transition semantics.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

3. isShopify, priceMin, priceMax, currency, productCount

Contract meaning: Current bounded public catalog observation; productCount is not automatically a full-catalog total.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

4. productsAccessible, catalogCoverage, catalogComplete, catalogScanLimit, productCountIsLowerBound

Contract meaning: Whether the public product feed was usable and whether the 750-product bounded scan is complete or a lower bound.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

5. revenueBand

Contract meaning: Rough heuristic derived from public catalog characteristics, never observed merchant revenue.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

6. priceChanges, materialityScore, materialityBand

Contract meaning: Explicit price-range deltas and weighted change significance.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

7. observedAt, firstSeenAt, lastSeenAt, previousObservedAt

Contract meaning: Stateful observation timing.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

8. confidenceScore, confidenceBand, confidenceRisks

Contract meaning: Evidence support for the store snapshot/change statement, separate from materiality.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

9. sourceEvidence, negativeSignals

Contract meaning: Store URL observation and platform/failure caveats.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

10. recommendedAction, actionPriority, actionReason, safeToAutomate

Contract meaning: Manual competitor-research routing.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

11. failureType, retryable, recommendation

Contract meaning: Baseline, source, and budget recovery guidance.

Reviewer prompts: Is the value present? Does its type match the schema? Is it supported by sourceEvidence or a documented deterministic transformation? Is any null being silently converted into a default? Would the value still mean the same thing after CSV export? Does the destination preserve the related confidence and gap fields?

Weekly quality report

Create a recurring internal report with these measures. The report is about pipeline health, not market demand unless the source contract explicitly measures demand.

Metric	Why it matters	Investigate when
Submitted inputs	Defines the actual denominator and scope of the run.	The count differs from the approved batch or schedule.
Business result rows	Shows how many usable observations were produced.	The rate changes sharply without an input explanation.
Advisory/failure rows	Prevents operational failures from disappearing in a results-only dashboard.	Any terminal class grows or is unmapped.
Partial-result rate	Measures incomplete source coverage or configured truncation.	It rises, or analysts stop seeing the partial warning.
Low-confidence rate	Shows the share of rows requiring more evidence.	It rises by source, cohort, or input pattern.
Retryable failure rate	Distinguishes temporary operational issues from deterministic outcomes.	Retries repeat without improving evidence.
Evidence-link coverage	Confirms material facts remain traceable after export.	Links or evidence objects are missing from delivered records.
Safe-automation share	Shows how little or much of the workflow can be deterministic.	A mapping change makes unsafe actions appear safe.
Manual-review backlog	Measures whether human verification capacity matches collection volume.	Rows age beyond the campaign or decision window.
Duplicate destination writes	Tests idempotency and stable identity mapping.	The same entity/run creates multiple external actions.
Cost per reviewed useful row	Relates platform spend to approved, decision-useful output.	Raw volume rises but reviewed utility falls.
Source-drift exceptions	Detects changed markup, response shape, policy, or source availability.	A new unknown pattern survives more than one bounded check.

Client-facing delivery note template

Use a note like this when delivering exports to a client or another team:

This Dataset contains bounded public-source observations produced by the Apify Actor for the submitted Input. Each row includes observation time, evidence confidence, recommended review action, and explicit gaps where available. A positive row is not proof of buyer intent, permission, legal status, future outcome, or any fact listed in the Actor's “never claims” section. Partial and failure rows are included so coverage is not overstated. Validate material rows at their source before acting.

Add the Actor URL, run URL, Dataset URL, build/version, exact Input scope, observation window, pricing model observed for the run, reviewer name, and date of approval.

CRM disposition vocabulary

Keep collection results and sales dispositions separate. A practical downstream vocabulary is:

• needs_evidence_review: useful signal exists but a reviewer has not approved it.
• needs_identity_review: entity or ownership association is not sufficiently proven.
• needs_policy_review: contact, privacy, suppression, legal, or contractual policy must be checked.
• approved_for_research: an analyst may perform more research; this is not approval for outreach.
• approved_for_authorized_action: a named operator approved one specific action under the organization's policy.
• retry_operational_failure: the source or infrastructure failed and a bounded retry is appropriate.
• closed_no_supported_signal: the completed bounded check found no supported signal; this is not a universal negative fact.
• closed_out_of_scope: the input should not have entered this workflow.

Never overwrite recommendedAction with the CRM disposition. The first is Actor-produced decision support; the second is your organization's accountable decision.

Sampling plan

For a new workflow, review every row in the first small run. When the contract is understood, sample all failure and partial rows plus a representative set of high-, medium-, and low-confidence results. Re-expand to full review whenever the source changes, the schema version changes, a new input cohort is introduced, the error distribution shifts, or a downstream user reports an unexplained result.

Change-management record

When you change field mappings or automation policy, record:

1. Previous mapping or rule.
2. New mapping or rule.
3. Actor build/version and schemaVersion used for validation.
4. Test run and Dataset URLs.
5. Positive, negative, partial, retry, and budget fixtures inspected.
6. Security and privacy review outcome.
7. Approver and activation time.
8. Rollback condition and responsible operator.

This makes a commercial data workflow supportable. Without the record, a later operator cannot distinguish a real source change from an undocumented mapping change.

Delivery patterns for marketing and small-business teams

One-off research

Run the Actor in Console, inspect the overview table, open evidence for each material row, and export only the approved subset. Record the run URL in the client or campaign notes.

Recurring watch or hygiene job

Use an Apify schedule. Write rows into a staging table keyed by entityId. Compare current and previous observations only when the Actor supplies valid state or your own pipeline implements an explicit comparable baseline. Never infer a change from a failed run.

Agency client delivery

Deliver three views: business results, evidence/quality exceptions, and operational failures. Include the run URL, observation time, configured scope, and a plain-language statement of what the Actor does not prove. This makes the deliverable auditable and reduces disputes caused by overclaiming.

CRM enrichment

Write into staging fields first. A human or approved policy promotes values into canonical CRM fields. Keep raw source values separate from normalized and decision fields, and do not replace a verified value with a lower-confidence observation.

AI-assisted review

An LLM can summarize rows, but it must receive the evidence, confidence risks, negative signals, and limitations. Require citations to sourceEvidence and prohibit invented identity, intent, legal, funding, mailbox, valuation, or availability facts.

Buyer and operator acceptance checklist

Use this checklist before calling the workflow production-ready.

Product fit

• The business question matches: Which watched store-level metrics changed since the prior comparable observation, and which changes deserve manual competitor-pricing or catalog research?
• The submitted entities were selected through an authorized process.
• A human owner understands the positive, negative, partial, and failure row types.
• The team accepts the boundaries listed in “What this Actor never claims.”
• The destination keeps evidence confidence separate from business scoring.

Input and run controls

• websites is explicitly reviewed and bounded.
• watch_name is explicitly reviewed and bounded.
• max_items is explicitly reviewed and bounded.
• The first production-like run uses a small representative sample.
• A maximum charge or internal spend alert is configured where appropriate.
• The workflow records Actor ID, build/version, run ID, Dataset ID, and input hash.

Data handling

• entityId is mapped to an idempotent destination key.
• observedAt and source-specific time fields remain distinct.
• sourceEvidence, gaps, and nulls are preserved.
• Advisory and failure rows cannot enter the positive-results lane.
• Low-confidence and partial rows have a visible manual-review view.
• Retention and deletion rules match the type of data collected.

Action safety

• recommendedAction is treated as a review label.
• safeToAutomate=false blocks automatic external action.
• Consent, suppression, legal, contractual, and platform rules are evaluated downstream.
• A reviewer can trace a material action back to source evidence and run metadata.
• Retry logic cannot duplicate a downstream action.

Ongoing quality

• The team monitors failure, retry, partial, low-confidence, and empty-result rates.
• A source-drift threshold pauses the workflow for inspection.
• Sample evidence is manually reviewed on a recurring basis.
• Cost per useful reviewed row is measured.
• Documentation and field mappings are updated when schemaVersion changes.

Frequently asked questions

Is this a database?

No. It is an on-demand observation tool. Each run collects or evaluates the submitted scope and records evidence at that time.

Does a found row prove commercial interest?

No. A found row proves only the factual observation described by its fields. Buyer intent is never inferred.

Can I automatically contact every result?

No. Use recommendedAction as triage, verify the evidence and identity, and apply your own consent, privacy, suppression, and outreach rules.

Why is safeToAutomate often false?

Because a useful observation can still require identity, context, legal, or source verification before action. Conservative routing prevents false certainty from scaling.

What should I do with low confidence?

Open confidenceRisks and sourceEvidence, close the important gap, or keep the row in a manual queue. Do not hide the confidence field.

What does partial mean?

The Actor obtained some usable evidence but could not support a complete observation of the configured scope. Partial is not the same as empty.

What is a confirmed zero?

Only an explicit source or deterministic rule can support a confirmed absence. An outage, truncation, or unreadable response is not a zero.

Should I retry every failure?

No. Retry only when retryable is true. Invalid input, policy refusal, or deterministic classification should be corrected or handled, not looped.

Can I delete failure rows?

You can exclude them from a business-results view, but retain them in operational logs so Dataset completeness and retry decisions stay explainable.

How should I deduplicate?

Use entityId for the entity and, for stateful monitors, eventId for the observed transition. Also retain the Apify run ID.

Can I treat confidence as conversion probability?

No. Confidence measures evidence support, not purchase probability, revenue, suitability, or expected return.

Can I change the recommended action?

Yes. It is an explainable default. Your downstream policy can be stricter, and should encode organization-specific authorization and risk tolerance.

How do I estimate cost?

Run the smallest representative input, inspect live event prices and run usage in Apify, then model the number of billable result events. The live pricing panel is authoritative.

Why use a small prefill?

It produces a cheap, fast, inspectable first run and reduces the chance of scaling a wrong input or workflow assumption.

Can I schedule it?

Yes. Use an Apify schedule, but make the destination idempotent and review changes in failure, partial, and confidence rates.

Can I export CSV or Excel?

Yes. Apify Datasets support common export formats. JSON is recommended when you need nested evidence and decision fields.

Can I send results to Sheets or Airtable?

Yes. Preserve entityId, confidence, evidence, gaps, actions, and failure fields instead of mapping only the headline value.

Can I use it from Make, Zapier, or n8n?

Yes. Start the Actor, wait for a successful terminal state, read Dataset items, then branch on decision and failure fields.

Can an LLM consume the output?

Yes, but pass the structured evidence and limitations together. Instruct the model not to invent missing facts and to cite sourceEvidence.

What happens when a source changes?

The run may become partial, unavailable, or fail validation. Monitor these rates and inspect logs before treating changed output as a real-world shift.

Does public mean unrestricted?

No. Public visibility does not remove source terms, privacy obligations, retention rules, or the need for a legitimate downstream purpose.

Is a source URL permanent?

Not necessarily. Store observation time and material facts because web content can change or disappear.

Can I rely on one row for a high-stakes decision?

No. High-stakes legal, financial, employment, compliance, safety, or personal decisions require appropriate primary evidence and qualified review.

How do I report a suspected parsing issue?

Provide the Actor run ID, a redacted input, affected field, expected source evidence, and whether the issue reproduces. Never include tokens or private data.

What does success mean?

A change row proves that observed fields in a bounded public store snapshot changed within the same named watch after a comparable baseline. Coverage fields decide whether product count and price range describe a complete public feed or only the observed subset. It does not prove per-SKU pricing, sales, revenue, inventory, strategy, intent, or commercial impact.

Support information to include with an issue

Provide the public Actor name, Apify run ID, Dataset item index or stable entity ID, a redacted Input, the relevant source URL, expected behavior, observed behavior, and whether retrying produced the same result. Do not include an Apify token, API key, private customer record, or unnecessary personal data.

Final interpretation rule

A change row proves that observed fields in a bounded public store snapshot changed within the same named watch after a comparable baseline. Coverage fields decide whether product count and price range describe a complete public feed or only the observed subset. It does not prove per-SKU pricing, sales, revenue, inventory, strategy, intent, or commercial impact.