Delivered

Inventory prediction, and the courage to delete it

A clustered regression engine for advertising inventory scenarios - evaluated honestly, found no better than a simple baseline, and replaced by a query-based approach with fewer anomalies and simpler extensions.

Context
Advertising technology
Period
2021 - 2025
My role
Data Platform Lead (designer and builder)
Stack
  • Python
  • scikit-learn
  • AWS ECS
  • Athena

The problem

Advertisers on in-game inventory want specific availability across broad dimensions, dates, and durations, and internal teams need to workshop scenarios against real constraints. Game inventory is fluid in a way retail shelves are not, so the estimate has to be accurate enough to stake campaign commitments on. This is, structurally, a regression problem - with the complicating factors of data volume, dimensionality, and margins (where many campaigns target) that punish anomalous predictions.

The approach

The first system took the problem at face value. A scikit-learn linear regression solved the core fit; to reduce error at the margins, an unsupervised clustering model split the training data into 500 clusters, each with its own regression. Productionalized, it was a proper distributed pipeline: Lambda ran the Athena query building the training set, a container clustered with k-means and queued cluster IDs through SQS, and a dozen ECS containers consumed the queue, fit their cluster’s model, and wrote results back to Athena - all orchestrated through Step Functions.

It worked, mechanically. The results were mediocre, honestly measured. Model diagnostics showed R-squared approaching zero across clusters - the classic signature that a plain mean would perform nearly identically.

So I tested exactly that: recreated the prediction as a series of SQL queries - seasonal ratios, conversion adjustments, subtle corrections - with no ML infrastructure at all. The results were nearly identical to the clustered system, with fewer anomalous predictions at the margins, and extending it (a new seasonality factor, a changed conversion ratio) was a query change rather than a retraining cycle.

I decommissioned the Lambda/SQS/ECS pipeline and shipped the query-based version.

The outcome

The replacement produced more usable predictions (fewer margin anomalies), simpler seasonal and conversion adjustments, and deleted a distributed system’s worth of moving parts from the platform. The scenario tooling internal teams used kept working, now on a base everyone could read.

Tradeoffs and lessons

Evaluate honestly before the architecture impresses you. The distributed pipeline was the most sophisticated thing in the stack; R-squared near zero meant it was an expensive mean. The measurement mattered more than the machinery.

Simplicity is a result you have to test for. “Would a baseline work?” is a hypothesis, and in this case the honest answer was yes.

Deleting a system is a deliverable. The win was not just the simpler model; it was the removed operational surface.

Diagram: the original path trains clustered regression models across ECS containers orchestrated by Step Functions; the replacement path is a series of SQL queries over Athena applying seasonal ratios and conversion adjustments directly.
Architecture diagram. A text description is included in the section above.