Amazon Discount Data Audit

Checks whether the discount claims in your existing Amazon offer data are supported by the list and current prices in the same rows, and flags implausible claims. It works only on data you supply. It does not visit Amazon, fetch prices, log in, or use proxies.

What it does

For each row it compares the claimed discount (percent and/or savings amount) with the discount computed from the list price and current price, then assigns a verdict:

Verdict	Meaning
supported	Claim matches the arithmetic within your tolerance
unsupported	Claim does not match the prices (percent and/or amount gap)
implausible	Inverted prices, zero or negative price, claim of 100% or more, or a discount above your plausibility limit
no_claim	Prices present, but no discount claim to verify
incomplete	Missing, unparseable or mixed-currency data, so no arithmetic verdict was possible

Each row also gets machine-readable flags (for example PERCENT_MISMATCH, AMOUNT_MISMATCH, EXTREME_DISCOUNT, INVERTED_PRICES, CONFLICTING_DUPLICATE, CURRENCY_MISMATCH) and a 0-100 severity score for sorting. A SUMMARY record in the key-value store gives verdict counts, flag counts, the problem rate and sample-size notes.

Price parsing handles $1,299.99, 1.299,99 €, plain numbers and nested objects such as {"value": "19.99", "currency": "GBP"}.

Sample input

{
  "items": [
    {"asin": "B0SAMPLE01", "title": "Sample kettle", "listPrice": "$100.00", "price": "$75.00", "discount": "25%"},
    {"asin": "B0SAMPLE02", "title": "Sample headphones", "listPrice": "$80.00", "price": "$60.00", "discount": "40%"},
    {"asin": "B0SAMPLE03", "title": "Sample cable", "listPrice": "$10.00", "price": "$12.00", "discount": "20%"},
    {"asin": "B0SAMPLE04", "title": "Sample lamp", "listPrice": "$1,000.00", "price": "$50.00", "discount": "95%"},
    {"asin": "B0SAMPLE05", "title": "Sample mug", "price": "$8.00", "discount": "30%"}
  ],
  "percentTolerance": "1.0",
  "maxPlausiblePercent": "90"
}

Expected behavior for this sample: row 1 is supported, row 2 is unsupported (computed 25%, claimed 40%), row 3 is implausible (list price below current price), row 4 is implausible (95% exceeds the limit), and row 5 is incomplete (no list price).

Input

• items: array of offer objects. Default field names are detected automatically (asin/id, title, listPrice/originalPrice, price/salePrice, discount/discountPercent, savings, currency).
• sourceDatasetId: optional ID of an Apify dataset in your own account; rows are read after inline items.
• fieldMap: rename fields, with dotted paths allowed, e.g. {"listPrice": "pricing.was", "currentPrice": "pricing.now"}.
• percentTolerance, amountTolerance: rounding allowances.
• maxPlausiblePercent: discounts above this are flagged even when arithmetic matches.
• maxItems: row cap (hard limit 50,000). onlyFlagged: write only problem rows to the dataset.

Output

One dataset row per input row: sourceIndex, id, title, listPrice, currentPrice, currency, claimedPercent, claimedAmount, computedPercent, computedAmount, percentDifference, verdict, flags, severity.

Pricing model

The Actor is written to emit one audited-offer event per row that received an arithmetic verdict. Rows that are incomplete, invalid input, and failed runs are not charged. The event is only charged after the row has been written to the dataset. Pricing availability depends on how the Actor is configured on the platform.

Limitations

• It verifies internal arithmetic consistency only. A row can be consistent and still wrong, because the Actor cannot confirm real Amazon prices, coupons, or the history behind a "list price".
• A list price that looks inflated cannot be detected without price history, which this Actor does not use. The plausibility limit is a heuristic you set, not a rule.
• Ambiguous number formats are guessed: 1,234 is read as 1234 and 12,5 as 12.5; 1.234 is read as 1.234. Use fieldMap plus clean numbers if your data is unusual.
• A bare number in a percent field is read as a percent (0.25 means 0.25%, not 25%).
• Rows with several currencies are marked incomplete rather than converted.
• Duplicate detection is by ID within one run and compares only list and current prices.
• Small samples (under 30 auditable rows) give problem rates that are not statistically meaningful; the summary says so.
• Results depend entirely on the quality and freshness of the data you provide. You are responsible for having the right to process it.

Development

Tests are offline: python -m unittest discover -s tests.