Dynamic pricing & offers
On this page
Which promotion applies to this cart? Does this customer get the loyalty price? Is this bundle eligible for free shipping? Pricing and offers are a stack of eligibility rules, evaluated fresh on every page view.
⚡ Where speed pays for itself
Pricing is computed on the page-load critical path, and page latency is conversion. Amazon measured every +100 ms at about −1% of sales. Microsecond evaluation keeps pricing and promotion rules off the render budget even at peak traffic, so you capture the upside of dynamic pricing without paying for it in lost conversions or a pricing-service fleet sized for Black Friday.
The stakes🔗
Getting this right moves real money. By McKinsey's conservative benchmarks, dynamic pricing delivers roughly 2–5% sales growth and 5–10% margin improvement (McKinsey); some studies report margin gains as high as ~25% in travel and e-commerce. More broadly, personalized offers lift revenue by 5–15%, and 71% of consumers now expect personalized interactions while 76% are frustrated when they don't get them (McKinsey).
How it works🔗
Pricing and promotion eligibility is encoded as rules over the basket and the customer; the engine returns which offers apply, and the app picks the best one. For example, "members in tier 2 or 3, shopping in region 5, spending $100 or more on category 88, qualify for this promotion." Because rules are plain text, a merchandiser can launch a flash sale or a regional campaign by adding rules, not by waiting on a software release.
🤖 With AI in the loop
AI pricing only ships inside rule guardrails. Airbnb's Smart Pricing models suggest a nightly price for each of 4 million+ listings, but a suggestion is adopted only if it falls inside the host's own minimum/maximum; the host's rule, not the model, has the final say on every published price. Airline pricing at PROS (400 million+ prices a day) applies rule-based adjustments and guardrails around its forecasting models; insurer Warta runs ML price models inside a governed rating-rule process that gets updated prices to production within hours. In Winnow those floors, ceilings, and eligibility bounds are ordinary rules checked against every model output, on every page view, and changed as fast as the market moves. More patterns: Deep Dive: AI + Rules Engines.
The render budget🔗
Pricing is not a background job; it happens while the page is being built and the shopper is watching. The budget is therefore the one already quoted above: Amazon measured every +100 ms of added latency at about −1% of sales, which makes 100 ms a useful unit of account — it is the amount of delay that costs a percent of revenue. Winnow is one step inside a page render: deciding which offers apply, not fetching the catalogue, not rendering the HTML.
The 100 ms that costs ~1% of sales, and the slice a 250,000-promotion check takes
Pricing the whole promotion book is free at page-render scale. Checking a basket against 250,000 live offers costs ~3 µs, roughly one thirty-thousandth of the 100 ms that would cost a percent of sales — so a merchandiser can keep adding offers without a conversation about page speed. Even the exhaustive cross-check, 134× slower, spends 0.4% of it. The row that would actually show up in conversion data is the service hop, which running in-process removes. Both µs figures are ours, measured in the run below; the round-trip band is the industry's.
Why Winnow fits🔗
- Basket and customer attributes map directly: cart value and quantity are number checks; loyalty tier, region, and category are category checks; "any of", "between", and and/or/not combinations are all native.
- The question runs in reverse at checkout: given one basket, which of thousands of promotion rules apply? (Answered in microseconds at page render.)
- Promotions change constantly. Rules are plain text and update live, so pricing teams launch and retire offers on a running store with no downtime.
- On every page, for every shopper, the engine evaluates the whole promotion book in one pass, so the cost per page view stays negligible even at peak traffic.
🧪 In simulation — 250,000 live promotions, 1.5 million page views
To put numbers on the above, we loaded a promotion book of 250,000 live offers in six families — per-product price breaks, brand-and-segment offers, store clearance, loyalty pricing, category campaigns, and cart-total tiers — and priced 1.5 million page views against all of it, each view taking the best offer it qualified for. That run evaluated $418.1 million of basket value and decided $49.5 million of discount, 11.8% of the total; 43.4% of baskets qualified for at least one offer.
What this is: a test run on a generated promotion book and a generated stream of page views, not a customer deployment — the offers and traffic are invented, the speeds and costs are measured. It ran on one ordinary 16-core desktop computer, priced at a standard cloud rate of $0.043 per processor-hour running around the clock, the same basis as the Deep Dive: Cost Savings. Prices and basket totals are held as exact money amounts rather than approximate ones, so no rounding drift can creep into a discount, and every basket's offers were double-checked against a slow, exhaustive pass over all 250,000 promotions before any stopwatch started — that slow way takes about 134 times longer. Treat the speeds as approximate, moving by about a fifth with machine load, and the money and counts as exact; the test ships with Winnow for your team to re-run on your own promotions.