AI·June 2025·9 min read

AI-Curated Product Bundles Based on Individual User Behavior

A personalized bundle engine is two separate problems wearing one UI: candidate generation, finding which products are plausibly related to what a shopper is doing right now, and ranking, deciding which of those candidates to actually show and in what order. Most bundling failures come from treating it as one problem solved by one model.

What a product bundle recommendation system actually has to do

A static bundle, camera plus memory card plus bag, is a merchandising decision made once and shown to everyone. A personalized bundle changes per shopper, per session, based on what that specific person has actually done: browsed, searched, added to cart, or bought before.

That requires two things a static bundle doesn't: a continuously updated behavioral signal per user, and a serving layer fast enough to re-rank candidates within a single page load. Neither is optional if "personalized" is going to mean anything beyond a label.

The two-stage pattern

Nearly every production recommendation system, regardless of vendor, splits into the same two stages. Candidate generation narrows a full catalog down to a manageable shortlist using cheap, fast signals. Ranking then applies a more expensive model to that shortlist to order it by predicted relevance, and increasingly, by predicted margin.

Stage	Job	Typical inputs
Candidate generation	Narrow the catalog to a shortlist worth ranking	Co-purchase history, category affinity, session behavior
Ranking	Order the shortlist by predicted relevance and business value	Real-time session signals, price, margin, inventory, timing
Serving	Return the final list within the page's latency budget	Precomputed candidates, cached embeddings, a real-time API call

Where the behavioral signal actually comes from

Two categories of data feed a bundling system: item interactions, what a user clicked, added, or bought, and item/user metadata, category, price tier, stated preferences. Most of the predictive value sits in the interaction data, not the metadata, which is why systems built purely on catalog attributes tend to underperform.

Session-based signals versus long-history signals

A returning customer with two years of purchase history is a different modeling problem than an anonymous first-time visitor mid-session. The research behind session-based recommendation exists specifically because long-history collaborative filtering doesn't work for that second case.

GRU4Rec, one of the earliest and still widely cited approaches, applies a recurrent neural network to model the sequence of actions within a single session, predicting the next likely interaction without needing any prior history for that user (arXiv — Session-based Recommendations with Recurrent Neural Networks). BERT4Rec extended the same problem with a bidirectional Transformer, using masked-item prediction so the model learns from both the interactions before and after a given point in a sequence, not just what came earlier (arXiv — BERT4Rec: Sequential Recommendation with Bidirectional Encoder Representations from Transformer).

Wide & Deep Learning, an earlier and still-common production pattern, combines a linear "wide" component that memorizes specific frequent co-occurrences with a deep neural network that generalizes to combinations it hasn't seen before, which is close to how a real bundling ranker balances "customers who bought X also bought Y" against genuinely novel pairings (arXiv — Wide & Deep Learning for Recommender Systems).

A cold-start visitor with zero purchase history isn't a data problem to work around. It's the majority of the traffic a bundling system actually has to serve well, which is why session-based models, not long-history collaborative filtering, are the harder and more valuable half of this problem.

Managed platforms versus building it yourself

Amazon Personalize is a managed service that trains recommendation models on your interaction data and serves them through real-time and batch APIs, with preconfigured recipes for common cases like "customers who viewed X also viewed" and "frequently bought together," alongside fully custom configurations (AWS — What is Amazon Personalize?). It also supports next-best-action recommendations for things like loyalty enrollment prompts, which is closer to bundling-adjacent behavior than pure product recommendation.

Google's Vertex AI Search for commerce (the Retail API) covers the same territory: it ingests catalog data and user events, then serves personalized product rankings and recommendations, with the explicit caveat in Google's own documentation that data quality, not the platform, is the primary driver of result quality (Google Cloud — Vertex AI Search for commerce overview).

The build-versus-buy tradeoff, honestly

A managed platform gets a defensible baseline live in weeks, against the research-grade session models above that take a dedicated ML team months to reproduce correctly.
A managed platform's ranking logic is a black box you can tune with business rules, not retrain from first principles, which matters if your margin structure is unusual.
Both AWS and Google are explicit that the limiting factor is your interaction data volume and quality, not which platform you pick. A thin event stream underperforms on either one.

Bundling adds a constraint plain recommendation doesn't have

A single product recommendation only needs to be relevant. A bundle needs to be relevant, coherent as a set, and priced in a way that doesn't erode margin on the anchor item to move an accessory nobody wanted.

Ranking by margin, not just by relevance

A ranking model optimized purely for predicted click-through will happily bundle a high-margin item with a heavily discounted one if the co-occurrence signal is strong, without regard for what that does to blended margin. Production ranking layers need a business-rules pass after the ML ranking step: margin floors, inventory availability, and category exclusion rules that the model itself has no reason to know about.

Set a minimum blended margin threshold a bundle must clear before it's eligible to show.
Exclude out-of-stock or low-inventory items from candidate generation, not just from the final display.
Cap how often the same anchor item appears across different bundles in a session, to avoid an obviously repetitive experience.
Log every shown bundle and its outcome, so the ranking model has a real feedback signal to retrain against, not just the original training set forever.

A recommendation model has no concept of margin unless you give it one. Left alone, it will optimize for the co-occurrence pattern that clicks best, which is not the same thing as the pairing that's actually good for the business.

Evaluating whether it's actually working

Offline evaluation, measuring how well a model predicts held-out historical interactions, tells you whether the model learned something real from the data. It does not tell you whether showing that bundle in production changes behavior, because a customer who would have bought both items anyway isn't proof the bundle caused anything.

Online evaluation is the only evaluation that counts for launch decisions

An A/B test against a holdout group that sees no personalized bundling, or a simpler static/rule-based bundle, is what actually establishes causal lift. Offline metrics are useful for iterating on the model between test cycles; they're not a substitute for the test itself.

Serving recommendations inside the page's latency budget

A personalized bundle is worthless if it makes the page miss its own performance budget to compute it. Amazon Personalize's real-time recommendation API is built for exactly this constraint: a single call, keyed by campaign or recommender ARN and a user ID, returns a ranked list synchronously, fast enough to call during page render rather than precomputing everything in a nightly batch (AWS — Getting real-time recommendations).

Precomputed versus real-time, and when each earns its cost

Precomputing bundles for every known customer overnight is cheap to serve, since it's a simple key-value lookup, but it can't react to what a shopper is doing in the current session. Real-time inference reacts immediately but costs a network round trip on every page load. Most production systems land on a hybrid: precomputed candidates as a fast fallback, refreshed by a real-time re-rank once enough in-session signal exists to make it worth the call.

Retraining cadence matters more than model choice

A co-purchase graph built from last quarter's catalog recommends items that may be discontinued, restocked under a new SKU, or repriced entirely. Retraining on a fixed schedule, tied to catalog change events rather than a calendar date picked at launch and never revisited, is what keeps candidate generation matched to what's actually sellable today. Treat the retraining pipeline itself as production infrastructure, with monitoring and a rollback path, not as a one-off script someone runs manually when a bundle starts looking stale.

Explaining the bundle, not just showing it

A bundle that appears with no stated reason reads as an upsell attempt. A bundle labeled "often bought with the item in your cart" or "completes your setup" gives the shopper a reason that maps to something they can verify against their own intent, which is what separates a recommendation from a dark pattern.

This isn't a UI nicety bolted on after the model runs. The candidate generation stage already knows which signal produced each candidate, co-purchase history, category affinity, or session behavior, so the reason string can be generated directly from that signal instead of a generic label applied to every bundle regardless of why it was chosen.

FAQ

What's the difference between candidate generation and ranking?

Candidate generation narrows the full catalog to a shortlist using cheap signals like co-purchase history. Ranking applies a more expensive model, and business rules, to order that shortlist by predicted relevance and value.

Do I need a research team to build this, or can a managed platform work?

Managed platforms like Amazon Personalize and Google's Retail API cover the common recipes, "frequently bought together," "customers who viewed X also viewed," without requiring you to implement session-based models from research papers. The tradeoff is less control over the underlying ranking logic.

What handles a first-time visitor with no purchase history?

Session-based models, like the recurrent and Transformer-based approaches in the GRU4Rec and BERT4Rec research, are built specifically to recommend from within-session behavior alone, without requiring prior history.

Should bundling optimize purely for predicted relevance?

No. A ranking model with no margin awareness will surface whatever pairing has the strongest co-occurrence signal, regardless of what that does to blended margin. Margin, inventory, and category rules need to sit on top of the model's output, not be assumed inside it.

How do you know if personalized bundling is actually improving revenue?

Through a controlled online experiment against a holdout group, not through offline model accuracy metrics alone. Offline metrics tell you the model fits historical data; only a live test tells you it changes behavior.

Does more customer data always mean a better bundling model?

Both AWS's and Google's own documentation are explicit that data quality and volume, not the platform's algorithms, are the primary constraint on recommendation quality. Thin or noisy interaction data underperforms regardless of which system processes it.

References

From the Destm engineering archive. For current work on this topic, start at Solutions or the blog.