Caps from your order history

Offers with caps designs a new offer with the cap built in, derived from your average order value. This playbook is its mirror: the discounts you’re already running have a year of redemption history, and that history knows better than any rule of thumb what each cap should be. PromoLock computes it for you — the job here is reading the number and acting on it.

The situation

A percentage discount has no price of its own — every cart sets it. On most orders, 10% off is what you expected. Then a $2,000 cart comes through the same code and takes a $200 discount you never consciously approved. One order like that outweighs twenty normal redemptions, and nothing about it looks wrong in the order list: the code worked exactly as configured.

The tell is the gap between a code’s typical redemption and its largest. When those are close, the discount is behaving. When the largest is ten times the typical, you have a tail — and a tail is exactly what a per-order cap removes.

The moves

1. Find the tails

Open Analytics → report Discount given → time Last 365 days. The list is ranked by total amount given, so your expensive discounts are already on top. Expand the biggest rows and read the first line of each panel: typical order gets $12.40 off · the largest single order took $184.00.

Close together → leave that discount alone, it’s doing what you designed. Far apart → keep reading.

2. Read what a cap would have saved

The expanded panel shows the what-if, computed from your actual orders:

If capped at / order	You’d have saved	Orders affected
$25	$1,940	214 (6.1%)
$40	$610	48 (1.4%)
$60	$95	6 (0.2%)

Two things to notice about any of these tables. Every suggested cap sits above the typical order — even the strictest row leaves the promotion itself untouched. And the savings drop fast as the cap loosens: the first row usually carries most of the money. Chasing the last row is rarely worth it; the decision is between the first rung (most savings, a few percent of orders trimmed) and the middle (nearly invisible, still real money).

Pick the number where the Orders affected column stops feeling like customers and starts feeling like outliers. For most stores that’s the row touching 1–5% of orders.

3. Set that exact number

For a discount built in PromoLock, open it and set Max discount amount on the offer (or Cap total discount amount in SafeGuards for multi-part offers) to the number you picked.

For a native Shopify code, recreate it as a PromoLock discount with the cap attached — same code style, same percentage, plus the ceiling.

Then update the promotion’s wording wherever it appears: “10% off, up to $40.” This isn’t just politeness. Advertising rules in most markets — the FTC’s truth-in-advertising standard in the US, the unfair-commercial-practices regimes in the UK and EU — expect an advertised offer to say what it actually pays, and a percentage that quietly stops at a ceiling can cross from “annoying” into “misleading.” Up to $X is the standard, safe wording; put it wherever the percentage appears, not just in fine print. (If you sell into markets with stricter promotion rules, check locally — this page isn’t legal advice.)

Finally, check Combines with is off. A cap only holds if a second code can’t stack on top of it — the stacking lock is the store-wide guarantee.

4. Treat the first cap as an experiment

Be clear about what the table does and doesn’t know. You’d have saved is measured from real orders — that part is fact. What no report can measure is how customers respond to the capped offer going forward: whether the “up to $X” wording dents conversion, whether the big-cart buyers shrug or walk. That part is a hypothesis until you test it.

So don’t cap everything in one afternoon. Pick the one discount with the ugliest tail, cap it, and leave a comparable discount untouched as your reference point. After 30 days, compare the two in Discount given: if the capped code’s Discounted orders held steady while the untouched one behaved as usual, the cap cost you nothing and kept the tail money — roll the approach out to the next discount. If its orders sagged and the reference didn’t, the cap (or its wording) is pushing customers away, and you’ve learned that on one code instead of ten.

What a cap can’t fix

Be honest with yourself about three rows you’ll see:

• A fixed-amount discount ($15 off) has no tail — the panel says so directly. A cap changes nothing; skip it.
• A Campaign row (unique codes minted by a referral, loyalty, or verification app) can’t have a cap edited into its existing codes — they belong to that app. But going forward you often can take over the supply: if the app accepts an imported code list (Klaviyo and most email/SMS tools do), generate a capped bulk set in PromoLock, Download codes, and feed the app your CSV — every code it sends from then on carries your cap. Only apps that insist on minting their own codes (verification services, some referral platforms) are out of reach; there the levers are the Controller: pattern blocks, stacking rules, sale-item locks.
• A code whose big orders you want — a wholesale-style code used by your best repeat buyers, say. The table tells you what a cap saves, not whether those customers would mind. That call is yours; the biggest discounted orders often come from people who were buying anyway, which cuts both ways.

What to watch in Analytics

Come back in 30 days on the same report. For each discount you capped, the typical and largest numbers should have converged — the largest now sits at your cap. Discounts applied falls while Discounted orders holds steady; that difference is margin you kept without losing a sale. If Discounted orders dropped too, your cap is biting real customers — loosen it one rung.

Pitfalls

• Capping below the typical order. That’s not trimming the tail, that’s gutting the promotion — every redemption hits the ceiling and the discount stops feeling like what you advertised. Stay above typical, always; the suggested rows already do.
• Leaving marketing at the bare percentage. Once capped, say “up to $X” wherever the offer appears — it’s what advertising rules expect (see move 3), and a customer who first learns about the cap at checkout won’t redeem twice.
• Reading “You’d have saved” as guaranteed profit. It’s what those orders would have paid at the cap, assuming they’d still have happened — a strong assumption for buyers who were shopping anyway, a weaker one for deal-hunters. The experiment in move 4 is how you find out which kind yours are; the table alone can’t tell you.
• Doing this once and never again. Discounts drift — a code shared in a big-cart community develops a tail it didn’t have in spring. The report refreshes daily; expanding your top five rows takes a minute a month.
• Trimming a tail that stacking created. If the same discount also tops the Stacked discounts report, the monster orders may be stacking artifacts — fix the stacking flags first, then re-read the cap table on fresh data.