case study · customer value forecast

Estimating Future Customer Spend

Combine purchase activity and expected spend to support planning and prioritization.

← Systems we builtCase study

The question

How much might a repeat buyer spend over the next six or twelve months? Purchase history can help a team plan and prioritize, but a single customer’s future orders remain uncertain.

How the forecast works

One model estimates the probability of remaining active; another estimates monthly spend while active. Multiplying those estimates and adding the months produces a future-spend forecast. This example uses public wholesale transactions from Online Retail II, with values in pounds sterling.

Forecast a customer’s spend

Start with the prepared customer record. The result is an estimate, not a promise of future revenue. Changing inputs explores the model’s response; it does not establish the effect of an intervention.

Score a Customer

Customer 12352 is ready to score. Run the forecast first, then expand the purchase history to explore different inputs.

Adjust the customer’s purchase history

Customer 12352, a holdout record the model never trained on. Scores run against the live model API. Values are wholesale invoices in GBP.

How we judged usefulness

We compared the forecast with carrying prior spend forward and with a simple customer-segment average, using 1,295 customers held out of training. We checked forecasting error, customer ranking and predicted totals across groups.

Evaluation offline holdout

Lower forecasting error than a prior-spend baseline.

12-month WAPE: 68.8% vs 90.2% baseline; 1,295 held-out customers.

Customer-level forecasts remain noisy; use for aggregate planning and prioritization.

Evaluation data →

What the result means

The model reduced forecasting error against both selected baselines. Ranking improved only modestly over prior spend, and individual estimates remain noisy. The evidence supports evaluating it for aggregate planning and prioritization, with care around decisions about any one customer.

For a different question—when customers leave and which segments retain better—see the customer retention case study. That example uses a separate sample dataset.

Results and BaselinesHoldout accuracy, customer rankings and comparison tables

Results

Holdout Customers
1,295
WAPE, 6 Months
82.8%
WAPE, 12 Months
68.8%
Survival Model ROC-AUC
0.757 to 0.811

WAPE is weighted absolute percentage error on total spend, measured on customers the model never trained on: the sum of absolute errors divided by the sum of actual spend across the holdout customers. It is not the error of each customer. Customer-level spend on sparse wholesale buyers is noisy, so the measures that decide whether the model is useful are how well it ranks customers and how close predicted and actual spend sit by decile. The decile table and the baseline table below are that view. ROC-AUC is the survival model's range across the 12 forecast months. From metrics.json in the repo below. Spend is in GBP.

Where the Money Is: Predicted Against Actual by Decile, 12 Months

  • Across all 1,295 holdout customers, predicted 12-month spend totals £1.49M against £1.55M actual, a 3.9% gap.
  • The top two deciles by predicted value hold 70% of actual spend and are predicted within 1.3%. The small-buyer deciles are where the per-customer error lives; they hold little of the money.
Decile by Predicted ValueCustomersPredicted, GBPActual, GBPGap
1130£7,061£17,84260.4%
2129£13,302£24,78246.3%
3130£23,786£39,70640.1%
4129£35,284£29,88118.1%
5130£47,504£38,30024.0%
6129£61,409£60,2611.9%
7129£85,437£105,55419.1%
8130£141,622£148,0344.3%
9129£250,293£251,6110.5%
10130£828,030£838,7341.3%

Gap = absolute difference between the decile's predicted and actual totals, as a share of actual. From decile_table_12m in outputs/metrics.json.

The Model Against Two Naive Baselines, Same 1,295 Holdout Customers

  • Repeat carries each customer's spend in the twelve months before the cutoff forward. Segment mean assigns the training-set mean for the customer's buyer-size tercile.
  • The model improves over both selected baselines on every reported measure, but its absolute customer-level errors remain high. On 12-month WAPE it is 68.8% against 90.2% for repeat and 112.4% for the segment mean. On ranking, Spearman 0.612 against 0.600 and 0.573; the top predicted decile captures 53.9% of actual spend against 53.6% and 23.2%.
  • An earlier Tweedie objective applied only to the spend component of the two-curve model returned 70.4% WAPE on this holdout, versus 68.8% for the serving model. That is different from the direct-forecast Tweedie experiment below.
Measure, 12 MonthsModelRepeat BaselineSegment-Mean Baseline
WAPE, 12 months (lower is better)68.8%90.2%112.4%
WAPE, 6 months (lower is better)82.8%125.1%122.2%
Spearman, predicted vs actual (higher is better)0.6120.6000.573
Top-decile capture of actual spend (higher is better)53.9%53.6%23.2%

From baselines, ranking, and spend_model_variants in outputs/metrics.json (buyer-value-radar f69559e). Both baselines use training rows only.

Alternative Model Comparison

A separate, exploratory check on 604 validation customers drawn from the training pool. Both approaches were trained and compared on the same customer split. These results are not from the 1,295-customer final holdout, and neither model was promoted as a result.

Approach12-month WAPE ↓Top-decile spend capture ↑
Two-curve model, retrained reference64.9%69.1%
Direct Tweedie forecast, challenger57.7%68.4%

The direct Tweedie challenger had 7.1 percentage points lower WAPE on validation, but the paired-bootstrap 95% interval for the difference (Tweedie minus two-curve) runs from −14.4 to +4.7 points, so an improvement is not established. Top-decile capture was also slightly lower. This is a comparison of approaches, not a new production result. View the validation report →

Model and deployment details

How It Works

  1. Estimate ActivityProbability of remaining active
  2. Estimate SpendExpected spend while active
  3. Combine EstimatesActivity probability × monthly spend
  4. Sum Future ValueSix- and twelve-month forecasts

Code

The model, the training pipeline, and the scoring service: github.com/alphan-ml/buyer-value-radar

Where It Runs Data, deployment and checks
Where It Runs · Buyer Value Radar
ComputeAWS Lambda behind API Gateway, us-east-1. Function bvr-score-customer. Endpoint guijt78nlb.execute-api.us-east-1.amazonaws.com.
ModelTwo LightGBM models, one for activity and one for spend, that combine into the six- and twelve-month value estimates. Read from S3 (giggit-buyer-value-radar-models) at cold start.
DeployA merge to main runs the tests, swaps the handler in the Lambda, and checks /health. GitHub Actions with an AWS role; no stored keys.
ChecksEvery six hours a job scores 300 held-out customers against this endpoint and writes the result to a public ledger. Live Checks.