The hours cover a reproducible prototype and a written experiment plan. A retention trial needs real customers, permission to run the campaign, enough observations and time for outcomes to mature. Another afternoon with a public CSV cannot replace those.
The schedule assumes prepared histories, the earlier environment and a reused delivery boundary. Rebuilding source data or a new CRM integration needs its own time. Read the causal primer, finish the fixed-horizon baseline, and add survival or treatment-effect modelling when the question and evidence call for it. The reference lab gives a reproducible synthetic fallback and keeps simulated outcomes clearly apart from real campaign results.
| Session | Hours | Do this | Done when |
|---|---|---|---|
| 1 | 3 | Define customer, eligibility, event, prediction horizon, action and economic objective | Another person can label five example customers from your contract |
| 2 | 7 | Build dated snapshots, feature availability checks and matured labels; create chronological folds | A future event cannot change an earlier feature row |
| 3 | 5 | Compare a simple rule, logistic regression and one boosted tree; calibrate the selected model | A comparison table uses identical future cohorts and natural churn prevalence |
| 4 | 5 | Build capacity curves, a CRM export or API, and a retention experiment design | Every exported decision has an owner, timestamp, model version and expiry |
| 5 | 5 | Exercise late labels, missing features and rollback; write results, limits and next gates | One documented command reproduces the offline result; simulated campaign results are labelled as simulated |
If you only have a customer-level benchmark without dates, do the model-comparison exercise and report its limits. Avoid inventing prediction dates or claiming a temporal backtest. For the stronger project, use transaction or subscription histories.