Unite x TUM.ai Data Mining Hackathon: Core Demand Prediction

I took part in the Unite x TUM.ai Data Mining Hackathon (March 6–8, 2026, Munich). Our team chose Challenge 2: Core Demand Prediction & Value Optimization: predict which recurring procurement needs to put into a “Core Demand” portfolio to maximize net economic benefit (savings minus fixed fees).

Prediction with a price tag

Every recommended item incurred a fixed monthly fee (€10 in the scoring setup), while savings applied only when that item recurred. Too many predictions let fees dominate; too few left savings on the table. The task was therefore an economic portfolio problem, with cold-start buyers (buyers with no purchase history in the training data), duplicate SKUs, missing attributes, and inconsistent descriptions complicating the predictions.

Challenge setup and scoring

Objective: For each buyer, recommend a set of “Core Demand” elements (recurring needs). Submissions are scored as Net Score = Total Savings − Total Fees across all buyers.
Savings: When a recommended (buyer, product) pair matches actual core demand in the holdout period, savings are generated (in the provided setup, 10% of historical spend on matched items; the exact formula was a black box).
Fees: €10 per predicted element per month, regardless of correctness.
Levels: Level 1 = E-Class only (the product category under the eCl@ss classification standard); Level 2 = E-Class + Manufacturer; Level 3 = methodology-focused (clustered feature combinations). We optimized for Level 1 and Level 2.

The scoring therefore made leaving items out as important as catching the recurring ones: an item was only worth recommending if its expected savings beat the €10 monthly fee.

Data and pipeline

We had anonymized procurement line items (PLIs): order date, buyer, eclass, manufacturer, quantity, unit value, NACE code (the buyer’s industry in the EU’s NACE classification) and company metadata. Cold buyers had all PLIs removed from training; warm buyers used a temporal split (lookback for features, post-cutoff for targets and evaluation).

The pipeline was staged:

Candidate generation (warm): Restrict to eclasses (Level 1) or eclass+manufacturer (Level 2) from the buyer’s history that met minimum order frequency and spend in a lookback window. No history-based candidates for cold buyers.
Feature engineering: Per (buyer, eclass) or (buyer, eclass, manufacturer) we built frequency, recency, spend, tenure-normalized (e.g. average monthly orders/spend), calendar, and buyer-context features—all strictly pre-cutoff to avoid leakage.
Cold path: Cold buyers received a fixed number of recommendations from industry-informed rankings (NACE hierarchy with fallback to global), not from a learned per-buyer model, to control fee exposure.

Modeling strategy

We used several approaches and tuned selection (threshold + per-buyer cap) on the online leaderboard.

Baseline (v1): Hand-crafted score: activity/frequency + √(spend) − recency penalty, then threshold and top-K per buyer.
Two-stage (v2) — main workhorse: Stage A: classifier for recurrence probability; Stage B: regressor for expected future spend given recurrence. Combined expected value ≈ P(recur) × E(spend | recur); then subtract fee and apply threshold + top-K. Implemented with LightGBM.
Heuristic (phase3_repro): Score from lookback orders, recency decay, and spend (optionally divided by the buyer’s months of history so newer buyers aren’t penalized), useful as a fallback and in the hybrid.
Hybrid: Primary portfolio from the two-stage model, backfilled from phase3_repro up to a target per-buyer size when we were under-submitting.

Selection depended on the score threshold (including negative thresholds to allow more predictions), a per-buyer top-K cap, and guardrails (min orders, min months, high-spend exception). We swept the threshold and top-K values, then archived runs to compare total score, fees, hits, and spend capture.

What worked and what didn’t

Fee-aware framing helped. Treating the problem as portfolio optimization (expected utility minus fee) kept us from blindly maximizing recall.
Cold start: Using NACE-based rankings and a separate cold_start_top_k cap kept cold recommendations sensible and fee-controlled.
Under-submission was the main bottleneck. Our two-stage model was conservative; leaders had higher spend capture (e.g. 76–79% at Level 1). Our best runs came from relaxing the score threshold and/or increasing top-K and from the hybrid when we needed more breadth.
Tuning and ops: Reusing existing scores and running selection-only sweeps (Snakemake from portfolio through submission) let us iterate quickly. Archiving runs and comparing metrics (total score, savings, fees, spend capture, prediction volume) made it clear that we were submitting too few of the candidates we already had, not generating too few candidates.

Results

On the final leaderboard:

Level 1 (E-Class): Our team (AAD) placed 5th with Net Score €1,327,614.87, 64.7% spend captured (17,661 hits). Top teams were in the €1.44M–€1.51M range with 76–80% capture.
Level 2 (E-Class + Manufacturer): We placed 3rd with €423,553.47, 25.5% spend captured (7,701 hits). The top two had higher fees and 32–33% capture.

Our Level 2 result was stronger relative to the field. At Level 1, we were clearly under-submitting, so our follow-up notes focused on negative-threshold sweeps and hybrid backfill.

Takeaway

Our main lesson was that selection policy mattered as much as model quality. Reproducible threshold and top-K sweeps exposed under-submission, while separate warm- and cold-start paths kept the fee budget under control. The same principle applies to other recommendation systems where every prediction has a cost: optimize the portfolio against that cost, not accuracy or recall in isolation.