Core Use Cases: Prediction, Classification, Clustering, and Recommendation

Why These Four Use Cases Matter

Many real-world AI projects can be described using four “core use cases”: prediction, classification, clustering, and recommendation. They are not the only things AI can do, but they cover a large portion of practical applications in business and everyday products. The key skill is learning to recognize which use case matches your problem, because that choice influences what data you collect, how you evaluate success, and how you deploy the system.

In this chapter, you will learn what each use case means in plain language, what typical inputs and outputs look like, and how to approach each one step-by-step. You will also see common pitfalls (for example, mixing up prediction and classification) and how to avoid them.

1) Prediction (Estimating a Number)

What “Prediction” Means

In AI practice, “prediction” often means estimating a numeric value. You provide information (features) about a situation, and the system outputs a number. This is sometimes called regression in machine learning, but you can think of it as “predicting a quantity.”

Typical examples include:

• Predicting next month’s electricity usage (kWh) for a household
• Estimating the delivery time (minutes) for an order
• Forecasting demand (units sold) for a product next week
• Predicting the price of a used car given its attributes

How to Recognize a Prediction Problem

It is a prediction problem when:

Continue in our app.

You can listen to the audiobook with the screen off, receive a free certificate for this course, and also have access to 5,000 other free online courses.

Or continue reading below...

Download the app

• The output is a number on a scale (e.g., 0–100, dollars, minutes, temperature).
• “Closer is better” describes success (being off by 2 minutes is better than being off by 20).
• You care about the size of the error, not just whether it is right or wrong.

Practical Step-by-Step: Building a Simple Prediction Workflow

The steps below describe a practical workflow you can apply even before you choose specific tools.

Step 1: Define the target number and the decision it supports

Be explicit about what the number will be used for. For example: “Predict delivery time so the app can show an ETA and the dispatch system can prioritize late orders.” This helps you decide how accurate you need to be and what errors are acceptable.

Step 2: List candidate inputs (features)

For delivery time, inputs might include distance, time of day, restaurant preparation time estimate, driver availability, weather, and traffic indicators. A good habit is to separate inputs into:

• Available at prediction time (safe to use)
• Only known later (must not be used, or you will accidentally “cheat”)

Step 3: Choose a baseline you can beat

Before any AI model, create a simple baseline such as:

• Use the historical average delivery time for that restaurant
• Use distance multiplied by a constant speed plus a fixed preparation time

If your AI system cannot beat a baseline consistently, it is not ready.

Step 4: Decide how you will measure error

Common ways to measure numeric error include:

• Mean Absolute Error (MAE): average of absolute differences (easy to interpret)
• Root Mean Squared Error (RMSE): penalizes large errors more heavily
• Percent error (useful when values vary widely)

Pick a metric that matches your business pain. If being very wrong is especially harmful (e.g., underestimating delivery time causes many complaints), a metric that penalizes large errors can be appropriate.

Step 5: Handle outliers and special cases

Prediction tasks often have unusual events: extreme weather, road closures, holidays, system outages. Decide whether to:

• Include them so the model learns to handle them
• Exclude them and treat them as exceptions with separate rules

For example, you might keep holiday data but add a “holiday” indicator feature.

Step 6: Deploy with guardrails

In production, numeric predictions should have guardrails:

• Reasonable bounds (e.g., delivery time cannot be negative)
• Fallback behavior if inputs are missing (use baseline)
• Monitoring to detect drift (if errors rise over time)

Common Pitfalls in Prediction

• Confusing prediction with classification: “Will the customer churn?” is classification (yes/no). “How many days until churn?” is prediction.
• Using future information: for example, using “actual preparation time” when predicting delivery time at order placement.
• Ignoring uncertainty: sometimes you need a range (e.g., 25–35 minutes) rather than a single number. Even if your model outputs one number, you can still communicate uncertainty by showing a window based on typical error.

2) Classification (Choosing a Category)

What “Classification” Means

Classification means assigning an input to one of several categories (classes). The output is a label such as “spam” vs “not spam,” “fraud” vs “legitimate,” or “cat” vs “dog.”

Typical examples include:

• Email spam detection
• Fraud detection for payments
• Sentiment analysis: positive/neutral/negative
• Quality control: defective vs acceptable
• Medical triage: low/medium/high risk

Binary vs Multi-Class vs Multi-Label

• Binary classification: two categories (approve/deny).
• Multi-class classification: one of many categories (choose exactly one), such as “billing issue,” “technical issue,” “account issue.”
• Multi-label classification: multiple categories can be true at once, such as tagging a photo with “beach,” “family,” and “sunset.”

Practical Step-by-Step: Designing a Classification System

Step 1: Define the classes and their meaning

Write down clear definitions and examples for each class. Ambiguous classes lead to inconsistent results. For customer support tickets, define what counts as “billing” vs “account,” and what to do when both apply (multi-label) or when one must be chosen (multi-class).

Step 2: Decide the cost of mistakes

Not all errors are equal. In fraud detection:

• False negative (missed fraud) can cost money.
• False positive (blocking a real customer) can harm trust and revenue.

This decision affects thresholds and evaluation metrics.

Step 3: Choose evaluation metrics that match the goal

Accuracy alone can be misleading, especially when one class is rare. Common metrics:

• Precision: when the model says “fraud,” how often is it correct?
• Recall: of all real fraud cases, how many did it catch?
• F1 score: balances precision and recall.
• Confusion matrix: shows counts of each type of error.

Example: If only 1% of transactions are fraud, a model that always predicts “not fraud” has 99% accuracy but is useless. Recall becomes critical.

Step 4: Set a decision threshold (when probabilities are available)

Many classifiers output a probability (e.g., 0.0 to 1.0). You then choose a threshold to convert it into a decision. For instance:

• Flag as fraud if probability > 0.9 (high precision, lower recall)
• Flag as fraud if probability > 0.6 (higher recall, more false alarms)

Threshold selection is a business decision informed by testing.

Step 5: Plan for “unknown” or “needs review”

Real systems often need a third outcome:

• Auto-approve (very confident legitimate)
• Auto-block (very confident fraud)
• Send to manual review (uncertain zone)

This is a practical way to manage risk and improve user experience.

Step 6: Monitor class balance and concept drift

In classification, the distribution of classes can change over time. Fraud patterns evolve; customer issues shift after a product update. Monitor:

• Rate of each predicted class
• Precision/recall on recent labeled samples
• Changes in input patterns (new devices, new locations)

Common Pitfalls in Classification

• Unclear labels: if humans cannot agree on the correct class, the model will struggle.
• Imbalanced classes: rare events require careful metrics and often special handling.
• Over-automation: forcing a hard decision when uncertainty is high; add a review path.

3) Clustering (Grouping Similar Things)

What “Clustering” Means

Clustering groups items based on similarity. Unlike classification, you do not start with predefined categories. Instead, the system finds structure: “these items look alike, those items look different.”

Typical examples include:

• Customer segmentation (group customers by behavior)
• Grouping news articles by topic
• Detecting unusual patterns by finding points far from clusters
• Organizing a photo library by visual similarity

What Clustering Outputs Look Like

Clustering usually outputs:

• A cluster ID for each item (e.g., Cluster 1, Cluster 2, Cluster 3)
• Sometimes a “distance” or similarity score
• Cluster summaries (centroids or representative examples)

Clusters are not automatically meaningful. You typically interpret them and assign human-friendly names like “budget shoppers” or “power users.”

Practical Step-by-Step: Using Clustering for Customer Segmentation

Step 1: Choose the items to cluster

Decide what each row represents. For segmentation, each row might be one customer. For document clustering, each row might be one article.

Step 2: Choose features that represent behavior or content

For customers, features might include:

• Purchase frequency
• Average order value
• Discount usage rate
• Categories purchased
• Time since last purchase

A common mistake is to include identifiers (like customer ID) or features that dominate the scale (like raw lifetime spend without normalization), which can distort similarity.

Step 3: Scale and normalize where appropriate

Clustering is sensitive to feature scales. If one feature ranges from 0 to 1 and another ranges from 0 to 10,000, the large-scale feature can overwhelm the others. Practical approaches include standardization (making features comparable) or using ratios and log transforms for heavy-tailed values.

Step 4: Pick a clustering approach and a number of clusters (if needed)

Some clustering methods require choosing the number of clusters (k). In practice, you often try several values and evaluate:

• Are clusters stable when you rerun the method?
• Do clusters differ in meaningful ways?
• Can the business act on these segments?

The “best” k is not just a mathematical choice; it is also about usability. Five segments might be manageable for marketing; fifty might not.

Step 5: Validate clusters with sanity checks

Because clustering does not have predefined labels, validation is partly qualitative:

• Inspect sample items from each cluster
• Compare cluster averages (e.g., average spend, average frequency)
• Check whether clusters correlate with known outcomes (e.g., churn rate differs by cluster)

If clusters do not differ in any interpretable way, revisit features and scaling.

Step 6: Operationalize: turn clusters into actions

Clustering is only useful if it drives decisions. Examples:

• Create tailored onboarding for “new but high-potential” users
• Offer retention incentives to a segment with high churn risk
• Adjust product recommendations by segment

Often, you will store the cluster ID in a database and refresh it periodically (weekly or monthly) as behavior changes.

Common Pitfalls in Clustering

• Assuming clusters are “real” categories: clusters are a lens on data, not a law of nature.
• Over-interpreting noise: forcing a story onto clusters that are not stable.
• Using clustering when you actually need classification: if you already know the categories you want, clustering may be the wrong tool.

4) Recommendation (Suggesting What to Choose Next)

What “Recommendation” Means

Recommendation systems suggest items a user is likely to want: products, videos, songs, articles, friends to follow, or even actions (like “enable two-factor authentication”). The output is typically a ranked list, such as “top 10 items for this user right now.”

Recommendations are often built from patterns in user behavior (views, clicks, purchases, ratings) and item information (category, price, text description). The system tries to predict relevance: “How likely is this user to engage with this item?”

Common Types of Recommendation Approaches (Conceptual)

• Popularity-based: recommend what is trending or most purchased. Simple and strong as a baseline.
• Content-based: recommend items similar to what the user liked before (similar genre, similar features).
• Collaborative filtering: recommend items liked by similar users (patterns across many users).
• Hybrid: combine multiple signals (often the most practical approach).

Practical Step-by-Step: Creating a Recommendation Feature for an Online Store

Step 1: Define the recommendation surface and goal

Where will recommendations appear?

• Homepage: “Recommended for you”
• Product page: “Customers also bought”
• Cart: “Frequently bought together”

Define the goal metric: clicks, add-to-cart, purchases, revenue, or long-term retention. Different surfaces may optimize different goals.

Step 2: Decide what counts as a positive signal

Recommendations rely on feedback signals. Examples:

• Strong signals: purchase, subscription, long watch time
• Weak signals: click, view, short dwell time

Choose signals that reflect real value. If you optimize only for clicks, you may recommend “clickbait” items that do not lead to satisfaction.

Step 3: Build a baseline recommender

Start with something you can implement quickly:

• Top sellers in the last 7 days (optionally per category)
• Top items among users in the same region

This baseline is useful for new users and new items and provides a benchmark for improvement.

Step 4: Handle cold start (new users and new items)

Cold start is a central challenge:

• New user: no history yet. Use popularity, onboarding questions (“What are you interested in?”), or context (location, device, time).
• New item: no interactions yet. Use content-based similarity (category, description, attributes) and controlled exposure (show it to a small audience to gather signals).

Step 5: Generate candidates, then rank them

Many real recommenders work in two stages:

• Candidate generation: quickly produce a few hundred plausible items (similar items, popular items, items from favorite categories).
• Ranking: score and sort candidates to produce the top N list.

This structure keeps the system efficient and allows you to mix different sources of candidates.

Step 6: Add diversity and business rules

A purely relevance-based list can become repetitive. Practical improvements include:

• Diversity: avoid showing 10 nearly identical items
• Freshness: include newer items
• Constraints: exclude out-of-stock items, respect age restrictions, avoid recommending items the user already purchased (unless replenishment makes sense)

These rules often matter as much as the underlying model.

Step 7: Evaluate recommendations properly

Offline evaluation (using historical data) is useful for iteration, but it does not fully capture real user behavior. In practice, you often need online testing:

• Offline metrics: how well the system ranks items the user actually interacted with in the past
• Online metrics: A/B tests measuring click-through rate, conversion, revenue, retention, or satisfaction signals

Also watch for unintended effects: recommending only expensive items might raise short-term revenue but reduce trust.

Common Pitfalls in Recommendation

• Optimizing the wrong metric: clicks instead of satisfaction or long-term value.
• Filter bubbles: showing only what the user already likes; add diversity and exploration.
• Ignoring constraints: recommending unavailable or inappropriate items damages credibility.

Choosing the Right Use Case (A Quick Decision Guide)

When you face a new problem, use these questions to identify the best fit:

• Do you need a number? Use prediction (e.g., “How many units will we sell?”).
• Do you need a category? Use classification (e.g., “Is this message spam?”).
• Do you want to discover natural groupings? Use clustering (e.g., “What types of customers do we have?”).
• Do you need a ranked list of items per user? Use recommendation (e.g., “What should we show next?”).

Some applications combine multiple use cases. For example, an e-commerce platform might cluster customers into segments, classify support tickets, predict delivery times, and recommend products—all at once. The important part is to keep each component’s goal and evaluation clear, so you can improve them independently.

Mini Case Study: One Product, Four Use Cases

Imagine a subscription meal-kit service. Here is how the four use cases can appear in one product without being the same thing:

• Prediction: estimate how many boxes to prepare next week to reduce waste.
• Classification: label incoming customer emails as “delivery issue,” “billing,” or “recipe question” to route them faster.
• Clustering: group customers by cooking preferences and ordering patterns to design better meal plans.
• Recommendation: suggest recipes a customer is likely to choose based on past selections and similar customers.

Notice how each use case has a different output type (number, label, group, ranked list) and different success measures. Keeping these distinctions clear prevents confusion during planning and helps stakeholders understand what the AI system will actually deliver.

Practical Checklist Before You Start Any of the Four

• Define the output clearly: number, class, cluster ID, or ranked list.
• Define the decision: what action will be taken based on the output?
• Pick a baseline: a simple method you can implement now.
• Choose evaluation metrics: aligned with real costs and benefits.
• Plan for edge cases: missing data, rare events, new users/items, uncertainty.
• Design monitoring: track performance over time and detect changes.