Ecommerce Pricing and Promotion Data Feeds
Executive Summary
A buyer's guide to pricing feeds that preserve list, selling, unit, coupon, member, subscription, bundle, and historical offer context.
The decision: what price can a shopper actually obtain?
Pricing teams rarely need another isolated number. They need a feed that distinguishes the shelf price from list price, coupons, loyalty or member pricing, bundles, unit economics, location, and time. The business decision is whether a competitor is truly cheaper for the same product and purchase conditions—and whether that difference is durable enough to act on.
A useful ecommerce pricing data feed preserves every displayed component rather than forcing all promotions into a guessed net price. If a coupon requires activation or membership, the feed should say so.
Set evaluation criteria before choosing a feed
| Criterion | Question to ask | Failure to avoid |
|---|---|---|
| Price semantics | Are list, selling, unit, member, and checkout prices separate? | A misleading single price field |
| Promotion structure | Are coupon, bundle, threshold, and subscription rules captured? | Parsing only the percentage |
| Context | Are seller, fulfillment, location, currency, tax, and account state retained? | Comparing unlike offers |
| History | Are observations append-only with timestamps and change events? | Losing short promotions |
| Quality | Are stale, partial, and ambiguous observations flagged? | False repricing triggers |
| Delivery | Can your warehouse ingest stable files or API deltas? | Manual dashboard exports |
Model the offer, not merely the displayed price
Google’s official Merchant API product schema separates regular and sale pricing and includes subscription, loyalty, availability, multipack, and bundle attributes. Its API reference also exposes distinct product, promotion, and inventory resources. Those are seller-submitted interfaces rather than a universal competitor-data source, but the separation is a useful design signal: price, promotion, and inventory are related records, not synonyms.
{
"marketplace": "example-market",
"listing_id": "L-94031",
"canonical_product_id": "CP-182",
"location_id": "store-560001",
"currency": "INR",
"list_price": 299,
"selling_price": 249,
"unit_price": {
"amount": 49.8,
"basis": "100 ml"
},
"promotion": {
"type": "coupon",
"text": "Save 10% with coupon",
"eligibility": "selected_accounts",
"price_after_promotion": null
},
"availability": "in_stock",
"observed_at": "2026-08-19T10:15:00+05:30"
}Leave price_after_promotion null when eligibility or arithmetic is uncertain. Preserve the promotion text and conditions for audit. For bundles, store both bundle price and contained quantities; for multipacks, calculate normalized unit price only when pack size is trustworthy.
Promotion types a production feed should distinguish
- Markdown: a displayed list or was price and lower selling price.
- Coupon: a clipped, entered, or automatically applied reduction, often with conditions.
- Member price: available only to a loyalty or paid-membership cohort.
- Subscription price: tied to repeat-delivery enrollment or cadence.
- Threshold offer: activated by basket value or quantity.
- Bundle or multibuy: multiple items or units sold under a combined rule.
- Payment offer: tied to a card, wallet, bank, or financing method.
Explore PLOTT’s marketplace coverage, pricing fields, promotion fields, and retailer use case when defining the requested output.
From observations to decisions
- Match exact product variants and sellers before comparing prices.
- Normalize currency and unit price, retaining the original values and conversion rate.
- Calculate an effective price only for promotions whose conditions are satisfied by the scenario.
- Compare time-aligned observations and report collection lag.
- Create alerts from validated changes, not every raw parser difference.
History should be append-only. A current-state table is convenient for applications, while an observation or event table preserves price duration, promotion cadence, and the evidence needed to correct errors.
Limitations and POC validation
Checkout-only discounts, taxes, delivery fees, personalized offers, geo-restricted stock, membership, and payment eligibility can make the final payable amount unknowable from a public product page. A crossed-out price is not automatically MSRP, and promotion text is not always machine-calculable. Marketplaces also change labels and merchandising modules.
In a POC, provide exact products, locations, sellers, collection times, and buyer states to test. Manually reconcile a sample against the visible source, test multipacks and coupons, measure freshness and missingness, and review how corrections flow downstream. Request a pricing-and-promotions sample datasetwith raw text, structured conditions, price history, location, seller, stock state, and explicit quality flags.
Related Articles
How to Track Competitor Prices: A Complete Guide for 2025
May 4, 2025
Step-by-step guide to tracking competitor prices across marketplaces. Compare price tracking software, learn best practices, and implement automated price monitoring for your business.
The Ultimate Guide to Price Intelligence Software
May 12, 2025
Complete guide to price intelligence software covering features, benefits, implementation, and ROI. Learn how dynamic pricing and pricing optimization drive profitability for brands and retailers.
Competitive Pricing Analysis: A Complete Tutorial
April 4, 2026
Complete tutorial on competitive pricing analysis. Learn data collection methods, analysis frameworks, pricing strategies, and how to use competitive intelligence to increase margins.
Show us the data you wish existed
Name the websites or apps, fields, locations, and frequency. We'll scope a representative sample and the production feed behind it.
Request a sample
Tell us the sources you need and what decisions the data should support