Promo and Discount Impact Review - E-commerce
Use this skill when
The user wants to know whether a promotion was worth running, or whether the next one should be.
Common requests:
- "Did Black Friday actually make us money?"
- "Should we run the same sale again?"
- "Revenue was up and profit was flat. Why?"
- "Our discount codes are leaking everywhere."
Required input
Minimum useful input:
- Orders or revenue by day covering the promo window plus a baseline before and after.
- Discount amount and mechanic: percentage, fixed, tiered, free shipping, bundle, or gift.
- Margin or COGS basis for discounted products.
Recommended additional input:
- Discount code usage export, including which codes were used and by whom.
- New vs returning customer split for the promo window.
- Ad spend during the promo.
- Promo calendar for the last 12 months.
- Site-wide traffic during the window.
Before analysis
- Define the baseline period explicitly and say why it was chosen.
- Confirm whether the promo goal was revenue, profit, new customers, clearing stock, or cash.
- Ask whether ad spend was increased during the promo. Lift from budget is not lift from discount.
- Check for seasonality overlap before attributing anything to the mechanic.
Analysis workflow
- Fix the three windows first, in code. With a daily revenue CSV, run
../scripts/promo_impact.py <file> --promo-start <date> --promo-end <date>. It computes baseline, promo and recovery on the same per-day footing, prices the trough, and refuses to stay quiet when ad spend also rose. Doing this comparison by hand is where the trough gets left out of the story.
- Compare promo window to baseline on: orders, revenue, AOV, units per order, gross margin, new customer share.
- Compute the margin actually given away: discount value plus incremental shipping and fee costs.
- Look at the days after the promo. A deep trough after the peak is pull-forward, not growth.
- Split the buyers: customers who would likely have bought anyway versus buyers new to the store or new to the category.
- Check discount leakage: codes used outside their intended audience, stacking, repeat use, codes on public coupon sites, sitewide codes applied to already-thin SKUs.
- Check whether the promo trained the list to wait. Compare full-price sell-through before and after repeated promo cycles.
- Give a verdict per mechanic, not per campaign, so the calendar can be rebuilt.
Decision and evidence standard
Tag every finding with evidence: export, margin_csv, cogs_export, promo_calendar, policy, support_ticket, hypothesis, or needs_data. Full vocabulary: ../references/output-standard.md.
Rank findings by margin given away rather than by revenue moved.
Incremental profit claims require a defensible baseline. Without one, the finding is hypothesis at low confidence.
Output format
Promo verdict
Did this promo add profit, move profit around, or destroy it. State confidence and the baseline used.
Promo economics
| Line |
Promo window |
Baseline |
Delta |
Note |
Pull-forward check
Trough depth after the window, and whether combined window plus recovery beats baseline.
Leakage findings
| Leak |
Evidence |
Severity |
Fix |
Effort |
Recommended promo rules
Three to five rules for the next calendar: what mechanic, what floor margin, what audience, what exclusions.
Missing data
The two inputs that most often turn this from a story into a measurement: ad spend by day across the same window, and margin for the discounted SKUs. Without the first, lift cannot be separated from budget. Without the second, the promo can only be judged on revenue.
Example input and output
Input:
- daily orders export, 90 days
- discount code usage export
- COGS for discounted SKUs
- promo calendar for 12 months
Good output excerpt:
| Finding |
Evidence |
Severity |
Confidence |
Business impact |
Effort |
Owner decision |
| Sitewide 20% applied to the two thinnest-margin SKUs, both sold below cost after fees |
export, cogs_export |
critical |
high |
margin |
XS |
do_now |
| Full-price sell-through fell in each of the three weeks before the last two promos |
export, promo_calendar |
high |
medium |
margin/revenue |
M |
investigate |
What not to do yet: repeat the calendar as-is because the promo week beat an unpromoted baseline week.
Guardrails
- Do not call revenue lift a profit win without margin data.
- Do not attribute lift to the discount when ad spend also rose.
- Do not ignore the post-promo trough.
- Do not recommend deeper discounts as the fix for a weak offer.
- Do not exclude SKUs from a promo without checking stock and cash goals first.
1---2name: promo-discount-impact-review-ecommerce3description: Reviews whether a discount, sale, or promo actually added profit or simply pulled forward demand and trained customers to wait. Use when a sale has just ended, when a promo calendar is about to repeat, when discount codes are leaking, or when revenue is up and profit is flat. Needs daily orders covering a baseline before and after the promo.4---56# Promo and Discount Impact Review - E-commerce78## Use this skill when910The user wants to know whether a promotion was worth running, or whether the next one should be.1112Common requests:1314- "Did Black Friday actually make us money?"15- "Should we run the same sale again?"16- "Revenue was up and profit was flat. Why?"17- "Our discount codes are leaking everywhere."1819## Required input2021Minimum useful input:2223- Orders or revenue by day covering the promo window plus a baseline before and after.24- Discount amount and mechanic: percentage, fixed, tiered, free shipping, bundle, or gift.25- Margin or COGS basis for discounted products.2627Recommended additional input:2829- Discount code usage export, including which codes were used and by whom.30- New vs returning customer split for the promo window.31- Ad spend during the promo.32- Promo calendar for the last 12 months.33- Site-wide traffic during the window.3435## Before analysis36371. Define the baseline period explicitly and say why it was chosen.382. Confirm whether the promo goal was revenue, profit, new customers, clearing stock, or cash.393. Ask whether ad spend was increased during the promo. Lift from budget is not lift from discount.404. Check for seasonality overlap before attributing anything to the mechanic.4142## Analysis workflow43440. **Fix the three windows first, in code.** With a daily revenue CSV, run `../scripts/promo_impact.py <file> --promo-start <date> --promo-end <date>`. It computes baseline, promo and recovery on the same per-day footing, prices the trough, and refuses to stay quiet when ad spend also rose. Doing this comparison by hand is where the trough gets left out of the story.451. Compare promo window to baseline on: orders, revenue, AOV, units per order, gross margin, new customer share.462. Compute the margin actually given away: discount value plus incremental shipping and fee costs.473. Look at the days after the promo. A deep trough after the peak is pull-forward, not growth.484. Split the buyers: customers who would likely have bought anyway versus buyers new to the store or new to the category.495. Check discount leakage: codes used outside their intended audience, stacking, repeat use, codes on public coupon sites, sitewide codes applied to already-thin SKUs.506. Check whether the promo trained the list to wait. Compare full-price sell-through before and after repeated promo cycles.517. Give a verdict per mechanic, not per campaign, so the calendar can be rebuilt.5253## Decision and evidence standard5455Tag every finding with evidence: `export`, `margin_csv`, `cogs_export`, `promo_calendar`, `policy`, `support_ticket`, `hypothesis`, or `needs_data`. Full vocabulary: `../references/output-standard.md`.5657Rank findings by margin given away rather than by revenue moved.5859Incremental profit claims require a defensible baseline. Without one, the finding is `hypothesis` at `low` confidence.6061## Output format6263### Promo verdict6465Did this promo add profit, move profit around, or destroy it. State confidence and the baseline used.6667### Promo economics6869| Line | Promo window | Baseline | Delta | Note |70|---|---|---|---|---|7172### Pull-forward check7374Trough depth after the window, and whether combined window plus recovery beats baseline.7576### Leakage findings7778| Leak | Evidence | Severity | Fix | Effort |79|---|---|---|---|---|8081### Recommended promo rules8283Three to five rules for the next calendar: what mechanic, what floor margin, what audience, what exclusions.8485### Missing data8687The two inputs that most often turn this from a story into a measurement: ad spend by day across the same window, and margin for the discounted SKUs. Without the first, lift cannot be separated from budget. Without the second, the promo can only be judged on revenue.8889## Example input and output9091Input:9293- daily orders export, 90 days94- discount code usage export95- COGS for discounted SKUs96- promo calendar for 12 months9798Good output excerpt:99100| Finding | Evidence | Severity | Confidence | Business impact | Effort | Owner decision |101|---|---|---|---|---|---|---|102| Sitewide 20% applied to the two thinnest-margin SKUs, both sold below cost after fees | `export`, `cogs_export` | critical | high | margin | XS | do_now |103| Full-price sell-through fell in each of the three weeks before the last two promos | `export`, `promo_calendar` | high | medium | margin/revenue | M | investigate |104105What not to do yet: repeat the calendar as-is because the promo week beat an unpromoted baseline week.106107## Guardrails108109- Do not call revenue lift a profit win without margin data.110- Do not attribute lift to the discount when ad spend also rose.111- Do not ignore the post-promo trough.112- Do not recommend deeper discounts as the fix for a weak offer.113- Do not exclude SKUs from a promo without checking stock and cash goals first.
mardab96