Merchant Sale Transition Audit
Pricing
Pay per usage
Merchant Sale Transition Audit
Audit feed vs static JSON-LD prices at sale boundaries. Compare up to 25 SKUs, classify new/existing/resolved differences, and export evidence, CSV and a reusable baseline.
Pricing
Pay per usage
Rating
0.0
(0)
Developer
Elena Lyalina
Maintained by CommunityActor stats
0
Bookmarked
2
Total users
1
Monthly active users
3 hours ago
Last modified
Categories
Share
Catch declared feed prices that disagree with static product JSON-LD when a promotion starts or ends. Compare up to 25 SKUs per run, retain exact evidence, and distinguish a new difference from an existing or resolved one using an earlier baseline.
Use this Actor for a small promotion-release check in a catalog or merchant-feed workflow. It returns a structured review queue, CSV and a reusable baseline. It does not change your store or feed.
Pricing and the demonstration
The live Pricing tab is authoritative: author pay-per-event fees are not active until shown there. Under the proposed pay-per-event contract, every delivered SKU audit record is billable, including clear, needs_review/unknown and synthetic simulations. The prefilled demonstration is a simulation, not a free-only fixture and not proof of a real store fault.
The proposed price is $0.005 per delivered record plus $0.00005 per run start at the supported 256–512 MB memory. One record costs $0.00505; 25 records cost $0.12505 in event fees. Invalid input rejected before results may still incur the startup event. CSV, BASELINE and SUMMARY carry no extra author event fee. Proposed PPE includes platform usage rather than adding a separate usage fee; taxes and the current live Pricing tab remain authoritative.
For the proposed PPE contract, $0.14 would be the minimum user-selected maximum spending cap, not a minimum billed fee. It reserves enough room for the complete batch of up to 25 records and another event's headroom. Companion CSV/baseline/summary are expected on a successful complete run; an unrelated crash or manual interruption can still prevent their completion.
Try the demonstration
The prefilled example is a synthetic simulation, with no network requests. It models an offer ending at 2026-10-06T07:00:00Z: the feed returns to GBP100 while the supplied JSON-LD still contains GBP80. A compatible earlier baseline makes the result new_issue. This demonstration is not evidence of a fault in any real store.
Select Start with the prefilled input, then open the dataset. For your own audit, replace the example with your declared feed and authorized markup. A real observed run requires a timezone-aware capture timestamp for each supplied snapshot; omit checkedAt when fetching a fresh public page.
Input
Supply exactly one feed array or feedCsv string. Use 1–25 unique string SKUs and declare price, three-letter currency, price_basis (tax_inclusive or tax_exclusive) and product url. Optional sale_price, sale_start and sale_end describe the promotion; both timestamps need an explicit timezone. Sale start is inclusive and end exclusive.
Supply static html on the feed row or a snapshots array keyed by SKU. For mode: "observed", each supplied capture needs timezone-aware captured_at; comparisons use capture time, not when processing finishes. For a hypothetical boundary test, use mode: "simulation" with explicit checkedAt. Every simulation row is labelled hypothetical.
Optional baseline is the complete BASELINE array returned by a strictly earlier compatible run. Do not use a partial object or reevaluate one saved capture as two real observations. Changed product identity, market, variant, currency or declared feed terms can make a baseline incomparable.
CSV headers: sku,price,currency,price_basis,url; optional sale_price,sale_start,sale_end,market,variant. The currently supported variant contract is an exact match to Product.size.
Output
One dataset row per supplied SKU contains classification, expected/observed prices, declared scope, reason, recommended action, evidence provenance, capture/evaluation times, exact JSON-LD script/pointer and markup SHA256. The key-value store also contains SUMMARY, reusable BASELINE, and spreadsheet-safe audit.csv.
| Classification | Meaning |
|---|---|
new_issue | A new or changed difference against an earlier compatible known baseline |
existing_issue | The same difference existed previously |
unbaselined_issue | A difference exists, but its age cannot be established |
resolved | An earlier difference now matches |
clear | Supported declared static fields match in the labelled evidence mode |
needs_review | Evidence is missing, ambiguous, malformed or incomparable |
baseline_incomparable | Declared identity/feed scope changed, or the baseline is not strictly earlier |
Uncertainty never becomes a green price verdict. Multiple offers, missing SKU/currency, conflicting tax declarations, unsupported variants and invalid offer validity timestamps require review. Changes in decimal formatting or JSON-LD position alone do not create a new issue.
Optional bounded public fetch
fetchPublicUrls is off by default. Enable it only for public pages you are authorized to access. It attempts at most 3 product pages / 6 HTTP requests total, including robots checks. Each HTTP worker has a full 10-second deadline; page responses are limited to2MB and robots to100KB. Only standard HTTP(S) ports and validated public IP addresses are accepted. There are no redirects, cookies, proxies, browser rendering or anti-bot bypasses. Robots-unavailable, blocked and unsupported content remain uncertain.
For a larger catalog or a site requiring JavaScript, supply authorized snapshots or split a suitable workflow into bounded runs. This Actor does not automatically acquire a complete merchant feed.
Limits and interpretation
- Static JSON-LD and declared feed/promotion terms only. Visible page price, shipping, checkout, stock, customer discounts and geography are outside the check.
clearmeans supported static fields match; it does not mean Google has approved the product or that tax compliance is verified.- Simulation is hypothetical. Real before/after evidence needs fresh captures from separate runs.
- Missing or ambiguous data produces review records, not guessed prices.
- Input validation can reject the run before any dataset rows are produced.
Connect a workflow
Run from Apify Console, the Actor API, or your existing Apify integration. Retrieve the dataset and route new_issue/resolved rows into your review process. Save BASELINE for the next compatible observation. Use the CSV for a manual small-batch check.
Support
Open an issue on the Actor's Issues tab with a minimal anonymized example and expected classification. Do not include customer data, credentials or private URLs. This is an initial release; customer demand and savings are not claimed.