Run a safe sitewide sale
A sitewide sale is the highest-leak week of the year: hundreds of products get compare-at markdowns, live codes are floating in inboxes and coupon sites, and every one of them is a potential discount-on-a-discount. This playbook sets the guardrails before the prices drop.
Before the sale
Section titled “Before the sale”1. Decide the code policy — one deliberate sentence
Section titled “1. Decide the code policy — one deliberate sentence”Complete this sentence before touching settings: “During the sale, discount codes should ___.” The three honest answers, and their setup:
| Policy | Setup |
|---|---|
| Not work at all — the sale price is the deal | Discount Lock → Block all codes. One switch on sale day, one switch off after. Set the error message to something graceful: “Prices are already reduced for the sale — codes resume afterwards.” |
| Work only on full-priced items | Sale-items lock, trigger Block if cart has any sale item — or the percentage trigger with a low threshold (10–20) if you’ll allow mixed carts. |
| Only specific codes work (e.g. VIP early access) | Discount Lock → Block all codes except → your allowed list. VIP# patterns keep the list short. |
2. Sweep the stragglers
Section titled “2. Sweep the stragglers”Old campaign codes don’t know your sale is on. Check Analytics → Top discounts by loss (last 90 days) for codes you’d forgotten were alive, and kill anything that shouldn’t survive into the event — deactivate the discount, or add it to Blocked codes.
3. Lock stacking, if it isn’t already
Section titled “3. Lock stacking, if it isn’t already”The stacking lock should be on year-round, but sale week is when it earns its keep — that’s when the most codes are in circulation at once.
4. If the sale itself is a PromoLock discount
Section titled “4. If the sale itself is a PromoLock discount”Running the sale as an automatic discount instead of price edits? Give it guardrails like any other offer: Cap total discount amount for a ceiling per order, Combines with all off, and Active dates set to the sale window so it shuts itself off on time.
During the sale
Section titled “During the sale”Glance at Analytics with Last 7 days once mid-event, checking both report views. You’re looking for one thing: Lost on sale items and Lost to stacking staying near zero. A rising sale-item number means a code is getting past your policy — the top-discounts list names it, and Blocked codes ends it in one save.
After the sale
Section titled “After the sale”- Reverse the temporary policy (turn Discount Lock off, restore your usual threshold).
- A week later, pull Last 30 days in both reports. The sale week should show as higher revenue, not higher unintended loss. If loss spiked anyway, the top-discounts list tells you exactly which door was open — close it before the next event, and this playbook gets shorter every time you run it.
Pitfalls
Section titled “Pitfalls”- Setting the policy during the sale, not before. The first hours are the leak window — traffic peaks exactly when the old rules are still live.
- Forgetting the reversal. “Block all codes” left on after the event quietly kills your next campaign. Put the switch-off in your post-sale checklist next to the price restores.
- Letting the sale discount combine. If the sale is an automatic discount with Combines with left on, every live code stacks on top of sale prices — the exact double-dip this playbook exists to prevent.
