ML Problem Framing: From Business Goal to Label and ML Objective
How to frame an ML problem: turn a business goal into an ML objective, choose inputs, outputs and labels, pick the task type, and know when not to use ML.
ML problem framing is the step that turns a business goal like "increase sales" into something a model can learn: a precise input, output, label and task type, plus the metric that tells you whether the model helps. It is the most important step of any ML system design answer, because a wrong framing makes every later step, from data to serving, solve the wrong problem very well.
From business objective to ML objective
A business objective can't be trained on directly. You choose a proxy the model can predict, and you must argue that improving the proxy improves the goal.
| Business goal | Possible ML objective | Watch out for |
|---|---|---|
| Increase watch time on a video app | Predict expected watch time per (user, video) | Long, low-quality videos; need satisfaction signals too |
| Grow ad revenue | Predict click probability (pCTR) for the auction | Must be calibrated; revenue = bid × pCTR |
| Reduce fraud losses | Classify a payment as fraud before authorisation | Labels arrive weeks later via chargebacks |
| More friends added | Predict the probability a suggested connection is accepted | Spammy invites inflate sends, not accepts |
| Faster support resolution | Classify ticket intent and route it | Intent taxonomy changes; needs a fallback queue |
Defining input, output and label
- Input: what is known at prediction time, such as a user, a query, a candidate item and the context (time, device, location). Anything not known then can't be a feature.
- Output: a probability, a score, a class, a number, or a ranked list. Say how it is consumed: thresholded, sorted, shown to a human.
- Label: the ground truth you train on. Prefer natural labels that come from behaviour (a purchase, a chargeback). When none exist, plan human labelling.
- Unit of prediction: one row per what? Per user-item impression, per transaction, per query-document pair. This choice decides your training data shape.
Choosing the task type
Ranking can be framed several ways: as pointwise classification (predict click probability per item, then sort), pairwise (which of two items is better) or listwise (optimise the whole list). Pointwise is the usual starting point; see learning to rank. Retrieval with embeddings is covered in embeddings.
Single objective or several
Real products rarely optimise one thing. A feed wants clicks, but also likes, shares, long watches and few "hide" actions. Two common framings:
- Multi-task model: one network with a head per objective (p(click), p(like), p(hide)), combined at serving time with tunable weights:
score = w1·p(click) + w2·p(like) − w3·p(hide). Changing weights doesn't need retraining. - Separate models: simpler to own and debug, but more to serve and keep consistent.
Either way, say how the weights are chosen: by an A/B test on the business metric, not by offline loss.
When not to use ML
- A rule is good enough. "Block payments from sanctioned countries" is a rule, not a model.
- No data and no way to get labels. Start with heuristics and log what you need for a model later.
- Mistakes are unacceptable and unexplainable. Some regulated decisions need transparent logic.
- The pattern doesn't repeat. ML learns from history; one-off decisions don't have any.
Saying "I'd launch with a heuristic baseline, log impressions and outcomes, and move to a model once we have a few weeks of data" shows judgment interviewers reward.
A framing checklist
- What business metric should move, and by how much would matter?
- What behaviour drives it, and which part can a model influence?
- What exactly is predicted, for which unit, at what moment?
- What is the label, how is it obtained, and how long until it is known?
- What does a false positive cost compared to a false negative?
- How is the output used: sorted, thresholded, or shown to a reviewer?
- What's the simplest non-ML baseline to beat?
Where it’s used
Revenue is framed as predicting click and conversion probabilities that feed an auction, so calibration matters as much as ranking quality.
"More bookings" becomes predicting booking probability per search result, with guardrails for host fairness and cancellations.
"Fewer harmful posts seen" becomes per-policy classifiers whose thresholds are set by the cost of each error.
In an interview
- Restate the business goal, then propose a measurable proxy and argue why it tracks the goal.
- Define the unit of prediction and the label in one sentence each.
- Say how long labels take to arrive; delayed labels change training and monitoring.
- Compare the cost of false positives and false negatives before choosing a metric.
Frequently asked questions
What is ML problem framing?
Turning a business goal into something a model can learn: defining the input, the output, the label, the unit of prediction and the task type, and arguing that improving that prediction improves the goal.
When should you not use machine learning?
When a simple rule works, when there is no data or way to get labels, when decisions must be fully explainable and errors are unacceptable, or when the pattern does not repeat. Start with a heuristic and log data for a model later.
Further reading
- Introduction to Machine Learning Problem FramingGoogle for Developers
- Rules of Machine LearningGoogle for Developers