When we started building the Curated For You model, one of the first decisions was which signals to train on. The obvious answer, at first, seemed to be "everything." Collect clicks, page views, time-on-page, cart additions, search queries, and purchase events. Feed all of it in. Let the model sort out what matters.
We tested that approach early. The results were worse than training on purchase history alone.
This surprised me at first. More data is usually better in machine learning contexts. But in retail personalization specifically, the signal-to-noise ratio of browse data is low enough that it actively degrades model quality when mixed indiscriminately with purchase data. Understanding why helps explain a lot of what's wrong with most recommendation systems built today.
What Browse Data Actually Captures
When a shopper clicks on a product page, what does that click mean? It could mean: they're interested in buying this item. It could also mean: the thumbnail looked interesting. The price seemed surprisingly low or high. They're comparison shopping. They accidentally clicked. They're browsing because they're bored. They're checking whether a gift idea is available.
A click is an attention event. It tells you something about what caught this person's eye at this moment. It says very little about what they're likely to buy.
Browse session data compounds this problem. A ten-page browsing session leaves a long trail of items viewed, but in many cases only one of those items, if any, was ever a genuine purchase candidate. The rest were curiosity, comparison, or navigation noise. A model trained on this data learns to associate a shopper with products they looked at once and never thought about again.
Time-on-page is even worse as a signal. Dwell time on a product page could indicate serious purchase consideration, or it could mean the shopper walked away from their laptop while the tab was open.
What Purchase Data Actually Captures
A completed purchase is a different kind of event. The shopper found the product, considered it, decided it met their needs, entered payment information, and confirmed the order. That's a multi-step commitment that costs real money. It's the highest-quality behavioral signal available in retail.
Purchase history tells you: what price ranges this shopper consistently commits to, which product attributes they keep buying (materials, sizes, colorways, styles), which categories they return to versus those they bought from once, which brands they've demonstrated loyalty to, and the cadence of their buying behavior.
These patterns are stable over time in a way that browse patterns are not. A shopper's click behavior on any given visit is noisy and session-specific. Their purchase history over 12 months is a reliable indicator of who they are as a buyer.
The Signal Contamination Problem
When you train a recommendation model on a blend of browse and purchase data, you face a weighting problem. Browse events outnumber purchase events by a large margin in most retail datasets. In typical mid-size retailer data, the ratio is somewhere between 15:1 and 50:1. That means if you treat all events with equal weight, the model is trained primarily on attention signals, not intent signals.
The response to this is usually to weight purchase events more heavily in the training data. This helps. But it introduces a new problem: you're now manually tuning a weight ratio rather than letting the data speak for itself. The right ratio varies by retailer, by category, and by shopper behavior patterns. Maintaining it over time as data distributions shift is ongoing work that requires someone to monitor it.
Training exclusively on purchase data sidesteps this problem. The model learns from intent signals only. There's no contamination from attention events. The weighting question doesn't arise because there's only one kind of signal.
We're not saying browse data has no value. For certain problems, it's useful: aggregate demand forecasting, detecting new product interest, identifying search intent gaps. But for per-shopper product ranking at the storefront level, purchase history is the cleaner foundation.
The Cold Start Question
The objection to purchase-first modeling is almost always the same: "What about new visitors? They have no purchase history." This is a real constraint, and it's worth being honest about.
For first-time visitors, the model cannot personalize because there is no purchase history to draw from. The fallback in this case is a sensible default sort: recency-weighted bestsellers, or a category-specific bestseller list, or a seasonally adjusted default. This is what every retailer is already showing every visitor. A first-time visitor gets the same experience they would have gotten without personalization at all.
But "new visitor" is not the same as "no purchase history." Many shoppers who visit your site for the first time this month have been customers for two years. They're returning buyers accessing the store from a new device or a private browsing window. If they log in, their purchase history is available and the model can personalize immediately. If they don't log in, the session is treated as a new visitor until they do.
For retailers with strong repeat-buyer bases, the share of sessions that genuinely have no recoverable purchase history is smaller than it might seem. In practice, we've seen the "no history available" rate run between 35-55% of sessions, depending on how strong the retailer's login adoption is. The other 45-65% of sessions can be personalized from purchase history on the first page load.
How Sparse Purchase Data Performs
Another common concern is about small purchase histories. If a shopper has only made two or three purchases, is there enough to model on?
The answer is yes, if you're modeling the right things. Three purchases don't give you a complete picture of a shopper's taste profile, but they do give you reliable signal about price range preference, which categories they've committed to, and sometimes attribute patterns if the items have enough in common. A model that uses this sparse signal appropriately will outperform a model that ignores it in favor of population-level bestsellers.
The key is building the model to work with sparse data gracefully: using purchase history where it exists, falling back to population-level signals where it doesn't, and being precise about which shopper signals are strong enough to influence the sort order versus which are too thin to rely on.
Why Most Recommendation Systems Get This Wrong
Most third-party recommendation engines are built on browse data because browse data is abundant, easy to collect via JavaScript tracking, and produces high recommendation volume. You get a large enough dataset quickly enough to build a working model without waiting for purchase events to accumulate.
The business consequence of this choice is that the recommendations reflect what shoppers paid attention to, not what they bought. For cross-sell widgets on product detail pages, this is sometimes acceptable: "customers who also viewed" is a coherent use case for attention data. For category page sort order, it's the wrong signal entirely. You're not trying to surface what this person has looked at before. You're trying to surface what they're most likely to buy next.
The infrastructure required to use purchase data at the category sort level is different from what a browse-event tracker requires. You need access to order history, not just session events. You need to run a scoring model against the full product catalog for each visitor at page load time. You need that process to complete in under 200ms or the user experience degrades. These constraints are why most recommendation systems don't go there.
That's the gap Curated For You was built to close. Not because purchase data is a novel idea, but because the infrastructure that makes it usable at the category level for mid-size retailers hadn't been packaged as something you could connect in a day.