Cross-sell and upsell "AI" is two separate systems wearing one name: a candidate generator that finds plausible complementary or upgrade items, and a ranker that orders them for a specific user in a specific context. Most underperforming implementations skip straight to a single black-box model and skip the parts that actually determine whether a recommendation helps revenue or just adds noise — cold start handling, margin-aware ranking, and honest evaluation.
"AI-powered recommendations" as a phrase hides a real architecture decision: are you generating candidates (which items could plausibly go with this one) or ranking a known set (in what order should we show these options to this user)? Cross-sell is mostly a candidate-generation problem — frequently-co-purchased or complementary items.
Upsell is mostly a ranking problem — reordering a known set of tiers or variants by predicted fit and value. Treating both as the same "recommendation engine" is where a lot of these systems go generic.
The two-stage architecture
Production recommendation systems, whether built on a managed platform or in-house, typically split into candidate generation and ranking rather than one end-to-end model, because the two stages optimize for different things: generation needs to be fast and broad (return a few hundred plausible items from a catalog of millions), and ranking needs to be precise and personalized (order those few hundred for this specific user, in this specific context, right now).
Candidate generation: the cross-sell layer
AWS Personalize's Similar-Items recipe is a clean illustration of this stage: it generates items similar to a specified item by combining co-occurrence in user interaction histories with item metadata similarity — the mechanism behind "customers who bought this also bought" and "frequently bought together" surfaces. Google Cloud's Vertex AI Search for commerce recommendations serves the same purpose from catalog and user-event data, and explicitly reuses the same ingested data for both recommendations and search rather than requiring a separate pipeline.
Ranking: the upsell layer
Upsell is closer to a reranking problem: you already know the candidate set (the product's variant or tier options), and the job is ordering or filtering them by predicted relevance to this user. AWS Personalize's Personalized-Ranking recipe is built for exactly this — it takes a curated or already-filtered list (search results, promotions, a set of tiers) and reorders it by predicted interest for a specific user, rather than generating new candidates from scratch.
If your cross-sell and upsell surfaces are backed by the same single model with no distinction between "find candidates" and "rank this known set," you're very likely underserving one of the two use cases — they have different data shapes and different failure modes.
Cold start: the problem every rollout underestimates
Every catalog has new items with no interaction history and, continuously, new users with no purchase history. A recommender trained purely on historical interactions has nothing to say about either, and naive fallback ("show the bestseller") is a real but blunt answer.
A 2025 survey on cold-start recommendation traces the evolution of approaches across four tiers of information: static content features, collaborative graph relations, domain-specific knowledge, and — most recently — world knowledge extracted from large language models, which can reason about a new item's likely audience from its description alone before any interaction data exists. An earlier survey on deep learning approaches to cold start and candidate generation catalogs the more established techniques: content-based fallback models, hybrid architectures that blend content and collaborative signals, and metadata-driven similarity as an interim substitute for interaction data.
In production, this usually means something more modest than an LLM-driven cold-start model: platforms like Amazon Personalize handle cold start by letting you attach item and user metadata (category, price tier, demographics) so a model can make an informed prediction even with sparse interaction history, rather than requiring pure interaction counts. AWS has moved away from its legacy HRNN-Coldstart recipe in favor of folding cold-start handling into the general-purpose User-Personalization recipe — worth knowing if you're referencing older AWS recommender-system material, since the standalone cold-start recipe it describes is no longer the recommended path.
Margin-aware ranking: optimizing for something other than clicks
The most consequential — and most commonly skipped — architecture decision is what objective the ranker actually optimizes for. A model trained purely to predict click or add-to-cart likelihood will happily rank low-margin, high-velocity items above higher-margin items that convert slightly less often, because it was never told margin exists.
AWS Personalize documents a direct mechanism for this: its User-Personalization and Personalized-Ranking recipes support an optional numerical objective column (price, margin, or any other numeric item attribute) with a configurable objectiveSensitivity (off, low, medium, high) that controls how much the model favors that objective versus pure relevance. Amazon's own documentation is explicit about the trade-off this introduces: over-weighting revenue or margin risks recommending only expensive items, which can make recommendations feel irrelevant and actually reduce engagement and conversion. That's not a hypothetical caveat — it's the platform vendor telling you the failure mode of the feature it just gave you.
This is the right way to think about "margin-aware" recommendations: not a separate business-rules layer bolted on after the AI ranks by relevance, but a tunable weight inside the same ranking objective, with an explicit dial for how far you're willing to trade relevance for margin.
Evaluating a recommender honestly
Two evaluation regimes matter, and conflating them is a common mistake:
- Offline metrics — computed by holding out a portion of historical interaction data and measuring how well the model predicts it. AWS Personalize, for example, documents a 90/10 train/test split by user for most recipe types, letting you compare recipes or hyperparameters before anything reaches production.
- Online metrics — the actual behavioral outcomes from real users seeing real recommendations in production, like click-through or conversion rate, which offline metrics can only approximate.
When you add a margin or revenue objective, the relevant offline signal changes too. AWS Personalize reports an average_rewards_at_k metric for objective-optimized solutions specifically, calculated as the share of a user's total reward (revenue, margin, whatever the objective column represents) coming from their top-ranked recommendations versus all recommendations shown — a direct measure of whether the ranking is actually surfacing high-objective items near the top, not just occasionally including them.
A minimal evaluation checklist before shipping a new ranking objective
- Confirm the objective column is genuinely numeric and populated for the large majority of your catalog — sparse or null values silently degrade the signal.
- Start at low or medium objective sensitivity, not high, and check offline reward metrics before increasing it.
- Run an online A/B test against the pure-relevance baseline — offline gains in a reward metric don't guarantee the same lift in real conversion.
- Watch conversion rate and average order value together, not just the reward metric — a model can maximize margin per recommendation while tanking overall click-through.
- Re-evaluate after any major catalog or pricing change — an objective column tied to price drifts in meaning after a repricing event.
Comparing the building blocks
| Component | Primary use case | Input shape | Key failure mode |
|---|---|---|---|
| Similar-Items / co-occurrence candidate generation | Cross-sell ("frequently bought together") | Interaction history + item metadata | Recommending near-duplicates instead of complements |
| Personalized-Ranking / rerank of known set | Upsell (tier/variant ordering) | A pre-filtered candidate list + user interaction history | Reordering options the user already rejected in a prior session |
| Metadata-driven cold-start fallback | New items/users with no history | Content and demographic metadata, no interactions required | Sticking with the fallback long after real interaction data exists |
| Objective-weighted ranking (margin/revenue) | Any of the above, tuned for business value | Base recipe output + a numeric item attribute column | Over-weighting the objective until relevance collapses |
Serving architecture: batch versus real time
Candidate generation and ranking also differ in how they need to be served. Similarity-based candidate sets (which items relate to this item) change slowly — they can be precomputed in batch and cached, since the underlying co-occurrence patterns don't shift meaningfully hour to hour. Personalized ranking for a specific user in an active session needs a real-time API call, because it depends on what that user just did in this session, not just their historical profile.
Getting this backwards is a common source of both cost and latency problems: recomputing full candidate similarity in real time for every page view is wasted compute for data that barely changes, while caching a personalized ranking response for more than a few minutes serves stale recommendations that ignore what the user just added to cart.
Batch-compute what changes slowly (item-to-item similarity). Serve in real time only what genuinely depends on the current session (personalized ranking, cart-aware upsell). Conflating the two either wastes compute or serves stale personalization.
Operational implications
A recommendation system is a live pipeline, not a shipped feature. Interaction and event data needs continuous ingestion — Google's Vertex AI Search for commerce documentation notes some models need 60 to 90 days of user-event data ingested before they're trainable, which means the ops timeline for a new recommendation surface starts months before the first recommendation ever ships. Budget for that lead time explicitly instead of promising a launch date that assumes the model can train on day one.
Own the retraining cadence deliberately: catalogs, pricing, and seasonal demand shift continuously, and a model trained once at launch degrades quietly rather than failing loudly. Decide upfront who monitors online conversion metrics against the offline baseline, and what triggers a retrain versus a rollback to the relevance-only baseline.
FAQ
Is cross-sell the same technical problem as upsell?
No. Cross-sell is closer to candidate generation from a large catalog (what else might fit); upsell is closer to reranking a known, smaller set (which tier or variant to show first). They call for different recipes/models even on the same platform.
How do you recommend a brand-new product with zero sales?
Through metadata-based similarity to existing items rather than interaction history — category, price tier, and descriptive attributes let a model make an informed guess before any purchase data exists. Recent research also explores using LLM-derived world knowledge about a new item's description for the same purpose.
Can you optimize recommendations for margin instead of just clicks?
Yes — platforms like AWS Personalize support attaching a numeric objective column (price, margin) with a configurable sensitivity level, so the ranker blends predicted relevance with your business objective instead of optimizing purely for engagement.
What's the risk of over-optimizing for margin?
The vendor's own documentation states it directly: over-weighting a revenue objective risks recommending only expensive items, which can reduce relevance, engagement, and ultimately conversion. Start at low sensitivity and increase gradually while watching online conversion, not just the offline reward metric.
How long before a new recommendation system has enough data to work well?
It varies by platform and event volume, but some managed recommendation services document needing 60 to 90 days of ingested user-event data before certain models are trainable. Plan the rollout timeline around that lead time, not around the engineering build time alone.
Do offline metrics guarantee real-world lift?
No. Offline metrics (computed on held-out historical data) are useful for comparing candidate models before launch, but only online A/B testing against a real baseline confirms the model actually improves conversion or order value in production.
References
- AWS Personalize — Similar-Items recipe
- AWS Personalize — Personalized-Ranking-v2 recipe
- AWS Personalize — Optimizing a solution for an additional objective
- AWS Personalize — Evaluating a solution version with metrics
- AWS Personalize — HRNN-Coldstart recipe (legacy)
- Google Cloud — Vertex AI Search for commerce overview
- arXiv — Cold-Start Recommendation towards the Era of LLMs: A Comprehensive Survey and Roadmap (2501.01945)
- arXiv — Deep Learning to Address Candidate Generation and Cold Start Challenges in Recommender Systems (1907.08674)
- arXiv — Wide & Deep Learning for Recommender Systems (1606.07792)