Context-Aware Recommendations: Beyond “Customers Also Bought”

“Customers who bought this also bought” answers a question nobody asked: what do thousands of strangers purchase in aggregate? Context-aware recommendation answers the one that actually drives the click — what does this person want right now, given where they are, when it is, and what they’re trying to get done?

TL;DR

• “Customers Also Bought” is item-to-item collaborative filtering — an algorithm Amazon shipped in 1998 and published in 2003. Its achievement is industrial (it scales to hundreds of millions of items), not conceptual.
• Its failure is ambiguity: co-purchase statistics can’t tell a complement from a substitute or a one-off gift. A frying pan bought with a cookbook and a frying pan bought with another frying pan look identical to the algorithm.
• Context-aware systems fix this by conditioning recommendations on the user’s situation. The strongest production pattern isn’t adding context as a feature — it’s treating recommendation as a decision under uncertainty via contextual bandits, which Spotify has run on its Home page since March 2025.
• Context is also the best answer to cold start: for a brand-new user it’s often the only signal that exists automatically — though never the only one that matters once history exists.
• Offline gains of 4–15% (Recall@20, NDCG@20 — defined below) show up in peer-reviewed 2025 benchmarks, though those papers rarely say enough about their baselines to know how hard the bar was. And the same architecture that fixes co-occurrence’s blind spots has, in a 2011 academic attack, already been shown capable of leaking the private purchases co-occurrence was supposed to keep anonymous.

Buy a frying pan on a major e-commerce site and scroll to the recommendation carousel. There’s a decent chance you’ll be offered another frying pan — not a lid, not a spatula, not the high-heat oil the manual demands, but a near-identical competitor to the item you just bought, as if the system concluded your kitchen contains two identical burners and an appetite for redundancy.

That’s not a bug. It’s item-to-item collaborative filtering working exactly as designed — and, as you’ll see below, designed well enough that two decades later it’s still the thing running under most of the web’s carousels.

The “Customers Also Bought” module most of the web still runs on descends from an algorithm Amazon deployed in 1998 and published in 2003: Greg Linden, Brent Smith, and Jeremy York’s “Amazon.com Recommendations: Item-to-Item Collaborative Filtering”, one of the most-cited papers in applied recommender-systems research. It spread well beyond retail — by some accounts, YouTube was running a version of it for video recommendations as early as 2010 — for the same reason it’s lasted this long: it’s simple, it scales, and its output is usually just useful.

The problem is what the algorithm can’t see. It knows items are purchased together. It doesn’t know why, for whom, or in what situation. Context-aware recommendation is the family of techniques built to attack exactly that blindness, and the last three years have turned them from academic curiosities into production infrastructure at the largest personalization platforms on earth. Here’s how each approach actually works, where each one breaks — including a documented case where the fix creates a new failure of its own — and how to decide what your system actually needs.

Why the incumbent refuses to die

Classic user-based collaborative filtering finds users similar to you, then recommends what they liked that you haven’t seen. Online, that’s brutal: with M customers and N catalog items, it costs roughly M×N work per request, against purchase histories too sparse for reliable similarity estimates.

Item-to-item CF precomputes the expensive part. Offline, for every item, it finds the items most frequently co-purchased with it and stores a similar-items table. Online, the system looks up matches against your recent purchases — compute scales with what you’ve bought, not the size of the customer base. Linden and colleagues put the offline build at roughly N²×M in the worst case, closer to N×M in practice, since most customers buy few items. Push the expensive part offline, keep serving nearly constant — that’s the whole reason this pattern conquered the web.

Specifically, it gets four things right that are easy to take for granted until you try to replace them:

• Latency and scale. Serving is table lookups — no model inference, no re-scoring at request time.
• Immediate updates. A new purchase reshuffles the lookup inputs instantly, no retraining cycle in the way.
• Explainability. “People who bought X bought Y” is a reason a customer can evaluate.
• Item cold-start resilience. A new item accrues co-occurrence counts the moment transactions happen.

“Replace your recommender with AI” oversells what’s actually wrong here. Nothing above is obsolete — it’s why item-to-item CF is still running, unglamorously and correctly, under a large share of the web’s carousels. What context-aware systems replace isn’t that engineering; it’s one specific, well-defined failure: the lossy compression of every purchase into a single number. The algorithm records that A and B co-occur. It discards the event type (gift, restock, comparison shopping), the time gap, the session, the device — everything that made the co-occurrence meaningful. Statistically robust, semantically blind.

Three structural failures of co-occurrence

1. Complement/substitute ambiguity. A customer who bought a camera and, later, its lens looks identical in the raw co-purchase table to one who bought the camera and, two weeks on, a competing camera. Amazon’s 2003 paper builds its similar-items table purely from what customers tend to buy together, full stop — carousels full of near-duplicates aren’t a ranking bug, they’re the algorithm faithfully reporting that substitute-shoppers exist.

2. Temporal blindness. Preferences aren’t a fixed vector. Spotify’s own September 2025 paper on contextual-bandit recommendation notes that historical listening data skews heavily toward music, and that appetite for music versus podcasts versus audiobooks shifts with time of day, day of week, even device. A system estimating your taste from a fixed trailing window is averaging across several different people you happened to be. Netflix hit this years earlier and built temporal dynamics into its models; preferences drift on timescales shorter than the windows most systems use.

3. Intent mixing across sessions. History mixes unrelated tasks — gifts, work purchases, things bought for someone else entirely. Intent within one session is usually coherent; intent across sessions usually isn’t, which is why the field moved from treating “the user” as a stable vector to treating “the session” as the unit of prediction. Hidasi and colleagues’ 2016 recurrent-network work on session-based recommendation, and most of what followed, rests on this. A gift-buying session can permanently distort a profile-based recommender; a session-aware one forgets it by Friday.

None of this makes item-to-item CF obsolete — Amazon still runs it as load-bearing infrastructure two decades in, and its explainability is genuinely hard to replicate. The modern move is demotion, not deletion: co-occurrence becomes one candidate-generation channel among several, while context-aware machinery takes over ranking and slate construction.

One session, traced end to end

No real system logs a session this cleanly, and this one isn’t drawn from any company’s data — it’s a constructed walkthrough, built to make the mechanics of Spotify’s approach concrete rather than a claim about what a typical session looks like. Treat it as a worked example, not a case study:

The moment that matters is the second row. Two contradictory signals arrive at once, and the system’s job is to test its way to an answer rather than pick a winner in advance. That’s context as policy, not just as input — the distinction the rest of this piece keeps circling back to.

What “context” actually means

Anind Dey’s 2001 definition is the one the field keeps returning to: context, in short, is whatever tells you the situation someone is actually in — not just who they are, but where, when, and alongside what. Recommender-systems research has narrowed that down to a handful of recurring dimensions worth instrumenting: time, location, device, task, companion, environment.

A useful sharpening comes from Aliberti, D’Aniello, and Gaeta’s systematic review of situation-aware recommender systems, published online January 2026 and covering 2009 through 2025. Context is elementary data; situation is interpretation. “12:00, location X” is context. “The user is commuting and wants audio, not video” is a situation — a fusion of signals into a state that changes what a recommendation should do. Across the literature the review surveyed, most systems equate higher predictive accuracy with better awareness, while rigorous measurement of whether the user actually understands their options better — what the authors call Human Situation Awareness — stays rare.

That distinction predicts architecture. If context is data, you bolt it on as extra model inputs. If situation is state, you need a component that infers the state and condition recommendations on it. Adomavicius and Tuzhilin’s foundational taxonomy offers three integration patterns:

Panniello, Tuzhilin, and Gorgoglione’s comparative study (User Modeling and User-Adapted Interaction, 2014) is the cautionary case for row one: pre-filtering can underperform non-contextual approaches on accuracy and diversity, because sparsity eats the gains once data is split across context slices. This table isn’t a menu where you pick the fanciest option — every row has a documented failure condition, and the most powerful pattern’s is data volume.

Terms, defined once. Recall@20: of the items a user actually engaged with later, what share showed up anywhere in the top 20 — a blunt coverage measure. NDCG@20: the stricter version — did those items land near the top, not just somewhere on the list. NP-hard: no known method guarantees the exact best answer quickly; practical systems settle for a good approximation. Inverse propensity weighting / doubly robust estimation: techniques for estimating how a new policy would have performed, using only data logged under the old one — because you usually can’t test a new policy on real users just to check.

The modern default: sequence models

Through most of the 2010s, “contextual modeling” meant tensor factorization — extend the user–item matrix into a user–item–context tensor and factorize that. It worked, and InCarMusic (music preferences under driving conditions) became a standard benchmark. But the center of gravity has moved to session-based and sequential recommendation: model recent behavior as a sequence and predict the next item, with context entering through position, timestamps, device embeddings, and side features. Attention-based architectures read the sequence the way a language model reads tokens — context is no longer a side table but the immediate behavioral history of the interaction itself.

A 2025 study proposing CARA — Vaghari, Hosseinzadeh Aghdam, and Emami’s context-aware model combining hierarchical attention with enhanced positional encoding over item attributes — reports Recall@20 gains of 4% on MovieLens-100K and 6% on Yelp, and NDCG@20 gains of 10% and 15% respectively, against prior state-of-the-art baselines. Those are real, peer-reviewed results on public datasets, and worth knowing about — but notice what’s missing from that sentence: which baselines, and how strong they actually were. A double-digit NDCG gain over a weak or dated baseline is a much smaller claim than the same number over a well-tuned recent one, and this is where small-benchmark recsys papers routinely go soft — MovieLens-100K and Yelp are standard because they’re convenient, not because state-of-the-art on them predicts anything about a live system with a different catalog and different users. Read results like this as “worth testing on your own data,” not as evidence the technique will transfer.

Context as policy: the bandit turn

The most interesting recent development isn’t a better feature — it’s a reframing. A recommender isn’t only a prediction engine; it’s a sequential decision system: choose an action (a slate of items), observe a reward (a click, a listen, a purchase), update the policy, repeat. Framed that way, contextual bandits — algorithms that learn which actions pay off as a function of current context — become the natural tool, because they solve a problem no offline model can: exploration. To learn that a user in context C wants podcasts, the system has to sometimes show them podcasts and see what happens. Static recommenders never run that experiment; bandits run it continuously.

Spotify’s deployed system is the cleanest public example. Its September 2025 paper — Feijer, Abdollahpouri, Gupta, and colleagues — describes a neural contextual bandit that learns the optimal mix of music, podcasts, and audiobooks for each user’s Home page slate, using a modified Maximum Marginal Relevance framework: a slate-building method that scores each candidate partly on how much it overlaps with items already chosen, trading a little individual relevance for a more balanced list. Per Spotify’s research page, the system deployed in March 2025 and now powers content-type calibration on the Home page across the platform’s several-hundred-million-user base, with the clearest gains landing on under-represented content types like podcasts.

The MMR detail is worth sitting with, because it’s doing more work than a single clause suggests. Classic Maximum Marginal Relevance was built for search results: rank each candidate document by its relevance to the query, discounted by how redundant it is with documents already picked, so the result list doesn’t just return ten versions of the same answer. Spotify’s adaptation repurposes that same redundancy penalty across content types rather than documents — a candidate podcast episode gets scored partly on how much “podcast-ness” is already in the slate, so a user with a strong music history doesn’t get buried in music picks the model is confident about, at the cost of never surfacing the podcast they’d actually try. That’s the mechanism behind the paper’s headline result: the clearest gains land on under-represented content types, not because the model got better at predicting podcast affinity in the abstract, but because the slate-construction step is explicitly built to make room for exactly the content a pure relevance-ranker would starve out.

Two details generalize past Spotify’s specific case. Slate construction is combinatorial — choosing the best list jointly, rather than the best items independently, is NP-hard in general, which is why the paper uses greedy, MMR-based construction instead of exhaustive search over possible slates. And rewards are delayed and partial — a user engages with the slate minutes or hours later, and a skip is weaker evidence than a session that continues, so the reward signal itself has to be engineered, not just measured. The feedback pipeline is as much a part of the system as the model.

When the fix creates its own failure

Context-aware machinery doesn’t just improve on co-occurrence’s blind spots — it can inherit privacy risks the industry already knew about.

In 2011, researchers from Princeton and the University of Texas — Calandrino, Kilzer, Narayanan, Felten, and Shmatikov — showed that the public output of a recommender, the plain “customers who bought this also bought that” list, can leak what a specific person bought, even though the list never names anyone. By watching how a site’s public similar-items list shifted over time, combined with modest outside knowledge about a target, they built passive inference attacks — executable by any ordinary internet user, no account access required — that recovered individual transactions on real sites including Amazon, Hunch, and LibraryThing.

That’s not a hypothetical risk attached to some future context-aware system. It’s a demonstrated property of the plain co-occurrence architecture already running today. Layering situation inference on top — time, device, session state — doesn’t introduce privacy risk into an otherwise-safe system. It adds a second, different kind of leakage to one the industry already had and mostly didn’t fix. Privacy review belongs in the architecture from the start, not as due diligence tacked on after launch.

The cold-start inversion

Ask engineers where “Customers Also Bought” fails and they’ll say cold start. Item-to-item CF actually handles item cold start fine — co-occurrence counts accumulate transaction by transaction. It’s the brand-new user with zero history where the lookup has nothing to look up. The standard fallback playbook — popularity defaults, onboarding quizzes, demographic guesses, content-based matching — is well documented, and none of it requires the user’s own history either.

What’s specific to context is timing. Those other fallbacks have to be built ahead of time — someone tags the catalog, designs the quiz, gathers demographic data. Context signals exist automatically, the instant a stranger’s browser opens: time of day, device, referral source, landing page, first click, city-level location. A context-aware system treats the first session not as an empty profile but as a rich situation from second one. The practical consequence, visible across the literature: hybrid designs win — serve popularity or content-based candidates as the prior, condition their ranking on live context, and let bandits explore aggressively in early sessions, when each impression’s information value is highest.

The honest limitation: context is weaker than history once history exists. The situation-aware review notes that unsupervised discovery of contexts nobody hand-engineered remains underused — most deployed systems only exploit the dimensions a human thought to instrument. If your situation isn’t in the feature spec, your recommender is blind to it, cold user or not.

Why most context-aware claims should be distrusted

The offline–online gap is the default outcome, not the exception. CARA’s numbers above are offline. Spotify’s paper is more credible than most precisely because it reports results from a system that actually shipped — and even there, the measured reward is short-term engagement, with long-term satisfaction left as a harder, separate question. A vendor or paper reporting NDCG lifts with no online validation should be read as “unproven in production,” not as a finding.

Human Situation Awareness is rarely measured. Across sixteen years of literature, the systematic review found rigorous measurement of whether users better understand their options — as opposed to whether models predict clicks — methodologically rare. The field optimizes the computer’s situation awareness and assumes the human’s follows. That assumption hasn’t been checked.

Accuracy and diversity trade off. The pre-filtering sparsity result isn’t an isolated artifact — context-driven accuracy gains have repeatedly cost diversity, and diversity is a large part of what makes recommendations feel right rather than merely predictable. A recommender that learns you perfectly is one that never surprises you; whether that’s a win is a product decision, not a model output.

Off-policy evaluation is genuinely hard. Bandit systems are usually evaluated with inverse propensity weighting or doubly robust estimators on logged data, and both carry their own bias–variance trade-offs. Deploying a new policy on offline estimates alone is a known source of production regressions.

What to actually build

1. Keep item-to-item CF as candidate generation. Cheap, robust, explainable. Demote it, don’t delete it.
2. Instrument context before modeling it. Timestamp, device, session boundaries, referrer, and cart state are the highest-value signals and nearly free to log. Context you didn’t capture can’t be learned later — this is the one step with no shortcut.
3. Add a context-conditioned ranker before any bandit machinery. A sequence or attention model over the session, with context features, gives the best ratio of accuracy gain to operational risk. This is where most teams should stop for the first 6–12 months.
4. Move to bandits only once exploration is the actual bottleneck — meaning you have enough daily traffic on the surface in question for the feedback loop to converge in weeks, not months, and a reward signal (not just a click) you’re willing to optimize against for quarters. Spotify runs this at several hundred million users; a catalog or surface with a few thousand daily sessions doesn’t have the volume for a bandit to learn faster than it thrashes. Building bandit sophistication before you have bandit-scale feedback is how teams ship a system that learns the wrong thing quickly and confidently.
5. Engineer the explanation layer on purpose. “Because you watched X” is something a user can evaluate; leave it as an afterthought and trust erodes as the model gets harder to interpret.

Skip contextual modeling and bandits entirely if any of these apply: a sparse catalog (modeling needs data volume you don’t have), a low-traffic surface (bandits won’t converge), a regulated domain (situation inference carries the same class of privacy exposure documented above — review isn’t optional), or no ability to run honest online A/B tests (in which case most of this literature’s claimed benefits are, for you, unverifiable).

Where this goes next

The arc is visible in the sources above: context as features (tensors, 2010s), context as policy (bandits, deployed at scale by 2025), situation as state (situation-aware systems, and the first LLM-based recommenders reading reviews and session text natively). The field’s vocabulary is converging on situation-awareness — and its unmeasured frontier is whether these systems make people better at knowing what they want, rather than merely better at predicting what they’ll click.

“Customers Also Bought” summarized the crowd. The next generation is judged by something harder: whether it understands the situation well enough to be useful to the one person actually in it — without becoming, in the process, a new way to expose that person to everyone else.

Sources

• Linden, Smith & York, “Amazon.com Recommendations: Item-to-Item Collaborative Filtering,” IEEE Internet Computing, 2003.
• Feijer, Abdollahpouri, Gupta, et al., “Calibrated Recommendations with Contextual Bandits,” Spotify Research / arXiv:2509.05460, September 2025; deployment date per Spotify Research.
• Vaghari, Hosseinzadeh Aghdam & Emami, “Context-aware recommendation using hierarchical attention and positional encoding based on multiple item attributes (CARA),” Signal, Image and Video Processing, 19, 1172 (2025).
• Aliberti, D’Aniello & Gaeta, “Situation-aware recommender systems: a systematic review and framework for trustworthy recommendations,” published online January 2026 (PRISMA review, literature 2009–2025).
• Calandrino, Kilzer, Narayanan, Felten & Shmatikov, “‘You Might Also Like:’ Privacy Risks of Collaborative Filtering,” IEEE Symposium on Security and Privacy, 2011.
• Dey, “Understanding and Using Context,” Personal and Ubiquitous Computing, 5(1), 4–7, 2001.
• Hidasi, Karatzoglou, Baltrunas & Tikk, “Session-based Recommendations with Recurrent Neural Networks,” 2016.
• Panniello, Tuzhilin & Gorgoglione, “Comparing context-aware recommender systems in terms of accuracy and diversity,” User Modeling and User-Adapted Interaction, 24:35–65, 2014.