[Always Projected]
Executive Margin Cockpit
A live P&L down to contribution margin per order line, for leadership only — where net is always projected.
Leadership noticed that a quarter with lower ROAS had made more money than one with higher ROAS. The difference was refunds and costs that the existing “net” didn't project.
Built the backend and the dashboard end to end, from the epic's hypotheses to the reconciliation checks, with finance reviewing every rule.
The old net mixed refunds-so-far with constants nobody could trace, so recent days always looked better than they would end up.
01 · Net is always projected
A “net with refunds so far” column anywhere is a bug. Each order line's net equals its contribution margin.
02 · A refund curve you can backtest
From a 90-day chain-ladder to a Bornhuetter–Ferguson-style 180-day curve: daily head, a tail borrowed from older cohorts with a measured ratio, plateaus with a floor — and a backtest per platform as a merge gate.
03 · No dead constants
Every factor — unit cost from the finance ERP, call-center take rate, media cost, gateway fees, dispatch cost — lives in a factors table with formula, window and warning.
04 · Hypothesis-sized stories
H0…H8, each with acceptance numbers. H0 was a business decision, not code: agreeing what “net” means and on one unit-cost base.
05 · Checks as a gate
Eight critical checks (perimeter, copy, reconciliation, refunds, backtest) must pass before a rebuild publishes.
what you're seeing
A waterfall from revenue to contribution margin, one bar per cost factor. Below, refund curves by cohort with the 180-day projection, a backtest of projected vs realized refunds, and the factors table that feeds every bar.try this
- 1.Switch to “net with refunds so far” and set the sale age to 7 days — the margin looks much better than it will be.
- 2.Drag the age toward 180 days and watch the gap close.
- 3.Click a row of the factors table to highlight where it enters the waterfall.
real vs simplified
The rule (net is always projected), the curve's shape and the factors-table idea are real. The cost structure and every number are synthetic.days since sale: 7
contribution margin: $15,000
refund development · cumulative % by day since sale
cyan: observed cohorts · dashed: 180-day projection with a floor
backtest · projected vs realized refund %
factors table — click a row to see where it enters
| factor | formula | window | warning |
| Gateway fees | per-order fee + % of collected | per order | ⚠ fee table missing for one gateway → fallback rate |
| Affiliate cost | commission on list price (not on collected) | per order line | |
| Product cost | units × unit cost from the finance ERP | monthly cost table | |
| Shipping | orders × average label cost | trailing 30 days | |
| Media | ad spend by niche (fallback: trailing ratio) | daily | ⚠ spend feed late → fallback + warning |
| Dispatch | SMS + e-mail + messaging volume × unit price | daily | |
| Projected refunds | collected × 180-day curve − realized | 180-day curve, backtested | ⚠ tail borrowed from older cohorts |
[synthetic data · fictional cost structure]
! brokeThe checks ran inside the transaction that rolled back, so the screen showed 14 hours of green while every rebuild failed.
→ changedChecks report outside the rollback, and freshness is measured on the data.
! brokeTwo copies of the same sale used different FX rates for one platform (up to about 5% apart) and no check saw it — in a ratio, the rate cancels out.
→ changedOne shared conversion module, an 18-month backfill and a check on absolute mass in dollars.
! brokeThe plateau calibrated on cohorts “mature” by age, which in practice meant one old month.
→ changedEligibility by completeness (≥ 0.85) instead of age. An alternative estimator was measured and rejected: it erred 3× more at 30 days.