Ecommerce Product Recommendations: What They Return, and Build vs Buy

Most pages about ecommerce recommendations answer the wrong question. They explain how cosine similarity works, then quote a conversion uplift from a vendor case study, and never put the 2 facts side by side. The question a retailer is actually deciding is narrower and harder to find an answer to: is this worth 800 hours of engineering, or should we pay $556 a month and move on?

That question has an answer, and the arithmetic is not close.

What a recommender actually moves, and by how much

A good recommender is worth roughly 12 per cent of engagement against showing your bestsellers, and about 8 of those 12 points are available from a simple baseline. The last 4 points are what large teams spend years on. That is the honest size of the prize, and it should set your budget.

The number comes from the most useful recommender paper published in the last 2 years. In November 2025, a team of Netflix researchers and economists, Kevin Zielnicki, Guy Aridor, Aurelien Bibaut, Allen Tran, Winston Chou and Nathan Kallus, used the natural randomness inside Netflix's own ranking system to build a causal estimate of what their recommender contributes. They then asked what would happen if Netflix replaced it.

Swap the production system for plain matrix factorization, a technique from 2006, and engagement falls 4 per cent. Swap it for ranking by popularity, which is a bestseller list, and engagement falls 12 per cent.

Sit with that for a moment. Netflix runs one of the largest recommendation teams in the world against more than a decade of viewing data on 300 million members. The distance between all of that and a bestseller list is 12 per cent. The distance between all of that and a 2006 baseline any competent team can ship in 200 hours is 4 per cent.

Two things follow, and they point in opposite directions. The first is that recommenders are real. 12 per cent of engagement on a business of any size pays for a lot of engineering. The second is that the curve is steep early and flat late, so the money is in shipping something rather than in shipping something clever.

The paper has a third finding that matters more for a catalogue than for a streaming service. The gains came from targeting rather than from exposure, and the items that benefited most were the mid-popularity ones. Not the head, which sells anyway. Not the deep tail, which nobody wants. The middle, where you hold stock and have no good way to surface it. If you have 40,000 SKUs and 400 of them carry your merchandising attention, the other 39,600 are where this pays.

The 5 slots, and what each one can see

Recommendations live in 5 places, and the slot decides what the model is even allowed to know. Choosing the slot before choosing the model is the single cheapest decision in the project, and it is the one most often skipped.

The product page. You know exactly 1 thing with certainty: the item being viewed. This is the easiest slot to fill and the easiest to fill badly, because "similar item" and "item you would also buy" are different queries and the page usually shows the first while the merchandiser wanted the second. A phone case next to a phone is a complement. Another phone next to a phone is a substitute, and substitutes on a product page push people back into comparison.

The cart. You know the basket, which is the richest signal in the entire funnel, and you have the least room to use it. The documented average cart abandonment rate across 50 studies compiled by Baymard Institute, spanning 2006 to 2025, is 70.22 per cent. Anything you add to a cart page competes with finishing the order. Complements only, 2 or 3 of them, no discovery.

Search and category. Here you have a stated intent plus behaviour, which is the best combination available anywhere on the site. This slot is usually owned by a search vendor rather than by the recommendation project, and the 2 teams frequently ship competing rankings on the same page.

The home page. You know who they are, if you know who they are. For a signed out first time visitor you know nothing, so the home slot falls back to popularity and seasonality. Teams routinely build the home slot first because it is the most visible, then discover that most of the traffic hitting it is anonymous.

Email and push. The only slot with no latency budget at all, which makes it the cheapest place to run an expensive model. You can afford a batch job that takes 4 hours. You cannot afford that on a product page with a 50 millisecond budget. Email is also the only slot where you get a clean read, because the send list is a list you control and a holdout is trivial to arrange.

If you are building the first version, build email and the product page. Email gives you measurement, the product page gives you volume, and neither needs the identity resolution that the home page quietly depends on.

Business rules decide more of the output than the model does

In a working ecommerce recommender, somewhere between 20 and 40 per cent of what the model ranks never reaches a shopper, because a rule removed it. Teams that treat rules as an afterthought ship a system that merchandising switches off inside a month.

The rules are not exotic. They are the ordinary facts of running a shop.

Stock. Recommending an item with 2 units left across 3 warehouses is a returns problem dressed as a conversion. Margin. A model optimised for click through will learn to recommend your loss leaders, because that is what people click. Exclusions. Age restricted goods, pharmacy lines, anything with a shipping restriction by region. Vendor agreements, which on a marketplace are contractual rather than optional, and which no model will infer. Price banding, because recommending a $900 item beside a $40 item reads as a mistake even when the affinity is real.

Then there is the one nobody writes down until it bites. Do not recommend what they already own. For consumables that is wrong, because replenishment is the best recommendation in grocery. For a washing machine it is embarrassing. The rule is per category, it lives in your product data model rather than in the model, and getting it wrong is the most common reason a merchandiser loses confidence in the system.

Two design consequences follow. Over retrieve, then filter, then rank: pull 500 candidates when the slot needs 20, apply the rules to those 500, and let the ranker order whatever survives. Filtering after the final ranking is the mistake, because it punches holes in a slate that is only 20 items long to begin with, and nothing refills them. And give merchandising a manual override with an expiry date, because they will take one anyway and an override with no expiry becomes permanent.

Attribution is the argument you will actually have

Here is the part that decides whether the project survives its second quarter. Your dashboard will report revenue from recommendations, that number will be large, and most of it will be wrong. Not because the tracking is broken. Because the number is counting sales that would have happened regardless.

A shopper searches for a product, lands on it, sees it in a recommendation strip, clicks the strip, buys. Last click attribution credits the recommender with the full order value. The recommender did nothing except appear on the path. Every recommendation widget on every ecommerce site reports revenue this way, and the figure typically overstates the causal contribution by a wide margin.

The fix is cheap and almost nobody does it. Hold out 5 per cent of traffic and show them no recommendations at all. Compare revenue per session between the holdout and everyone else. That difference is the real number, and it is the only number worth taking to a board.

Expect it to be smaller than your dashboard says, by a lot. Expect the first honest read to be uncomfortable. And expect to need around 4 weeks at typical mid-market volume before the difference clears noise, because revenue per session is a high variance metric and a 2 per cent effect on it needs real sample size.

Run the holdout from day 1, before anyone has an opinion to defend. Arguing for one after 6 months of flattering numbers is a political problem rather than a technical one.

Build versus buy, at published prices

At 10 million recommendation requests a month, buying costs between $556 and $5,997. Building costs about 800 hours. At every published price except the most expensive, the build does not pay back inside 18 months even if you ignore what it costs to run. For most mid-market retailers the answer is buy, and that is not the answer a development agency is supposed to give.

The managed options, at their own published rates as of October 2026:

product	published unit price	10 million requests a month
Amazon Personalize, standard recipes	$0.0556 per 1,000 requests, first tier	$556
Amazon Personalize, v2 recipes	$0.15 per 1,000 requests	$1,500
Google Vertex AI Search for commerce	$0.27 per 1,000 predictions, plus $2.50 per node hour	$3,150
Algolia Recommend, Grow	$0.60 per 1,000 above 5,000 free	$5,997

The Google figure includes training and tuning using the volumes in Google's own worked example, 150 node hours of training and 30 of tuning a month, which is $450. Amazon adds $0.05 per GB of ingestion and $0.002 per 1,000 interactions used for training on the v2 recipes.

Now the build. Our rates are $40 to $100 per hour by role, published. A mixed team blends to $60 to $70, and $65 is the number to plan against. A 2 stage system with event capture, a vector store, online experimentation and a retraining pipeline runs 600 to 1,100 hours, and under 150 of those are modelling. At 800 hours and $65 that is $52,000.

Divide one by the other and you get the payback month:

against	monthly saving	payback	requests a month to pay back in 18
Algolia Recommend	$5,997	8.7 months	4.8 million
Google Vertex AI	$3,150	16.5 months	10.7 million
Personalize v2	$1,500	34.7 months	19.3 million
Personalize standard	$556	93.5 months	52.0 million

Read the right hand column, because it is the one that decides. If you are not serving several million recommendation requests a month, building to save money is a mistake, and the arithmetic above is generous to building: it ignores hosting, on call and the retraining that someone has to own after the project closes.

Most mid-market retailers are nowhere near 5 million requests a month. A site doing 200,000 sessions a month with 4 recommendation slots per session serves about 800,000 requests. On Personalize standard recipes that is $45.

When building is the right answer

Build when a product cannot express something your business depends on, or when request volume puts the payback inside a year. Volume is arithmetic and you have it above. The capability question is the one worth thinking about, and there are 4 recurring cases.

A 2 sided marketplace where supply can decline. A rental platform, a services marketplace, a freight board. The decline signal is the most valuable column you have and no catalogue product has a field for it. Recommending unavailable supply is worse than recommending nothing, because it burns trust on both sides.

Ranking on margin rather than on probability. Every managed product optimises some flavour of engagement. If your actual objective is contribution per session after returns, you are reweighting their output with your own rules until you are most of the way to building anyway.

A regulated catalogue. Pharmacy, alcohol, financial products, age restricted goods. The constraint is not that a vendor cannot filter, it is that you need the filter logic auditable and versioned next to the rest of your compliance evidence.

Latency or residency you cannot meet with an external call. A 20 millisecond budget or a hard requirement that behavioural data never leaves a jurisdiction.

Outside those 4, the honest recommendation is to rent the capability, spend the saved 800 hours on the catalogue data underneath it, and revisit in a year with real numbers. If you want the decision made on your actual volumes rather than on a generic table, that is a conversation worth having with our ecommerce app development team before anyone writes code.

What your data has to look like before any of this works

Three things decide whether a recommender can work on your site, and none of them is the model. Event volume, catalogue quality, and whether you can tell that 2 sessions were the same person. Every stalled project we have looked at failed on one of these rather than on the algorithm.

Events, and the right ones. Orders feel like the obvious training signal and they are the weakest, because orders are roughly 2 per cent of the volume of views. A site with 18 months of order history and no view logging has 18 months of nothing. You need view, add to cart, remove from cart, search with its result set, and search with no results, which is the most underrated event in ecommerce because it tells you what your catalogue is missing. Four to 6 weeks of properly logged behaviour beats 2 years of orders.

Catalogue quality, which sets your floor on day 1. Content based scoring over clean attributes works with zero behavioural history, which makes it the right first version almost every time. But it inherits whatever your product data actually is. If 30 per cent of your items have no category beyond the top level, or colour lives in the title as free text, the model surfaces that mess faithfully. Cleaning attributes is unglamorous and it is usually the highest return work in the first month. The same attribute discipline shows up in retail software development projects long before any machine learning does.

Identity, which is where the home page quietly fails. A signed out shopper on a phone and the same person on a laptop are 2 users to your system. Guest checkout makes it worse. Before funding personalisation on the home page, measure what share of your sessions you can actually link to a history. If it is under 30 per cent, the home slot is a popularity ranking with extra steps and you should spend the budget on the product page instead.

The 2 sibling posts on this site go deeper on what sits above this layer: the model families in which ML model to use, and the 2 traditions in collaborative filtering and content-based filtering.

Three catalogues, 3 different first versions

The same budget buys different first versions depending on what you sell. These are the 3 shapes we see most often, and in 2 of them the first version contains no machine learning.

Fashion, 25,000 SKUs, heavy seasonal turnover. Your catalogue is replaced faster than a model can learn it, so collaborative signal is permanently cold on new arrivals. Content based scoring over attributes, with visual similarity if your photography is consistent enough to support it. Recency and stock rules do the heavy lifting. Buy, do not build, because the thing that limits you is attribute quality rather than algorithm quality.

Grocery, 12,000 SKUs, repeat purchase. The best recommendation is what they bought 3 weeks ago, and it is a SQL query. Replenishment prediction from purchase interval beats every learned model in the first year, and it is perhaps 120 hours of work including the interval estimation per category. Build this one, because it is small, and because no managed product models replenishment the way grocery needs it. Forecasting the interval itself sits closer to predictive analytics development than to recommendation.

A marketplace, 20,000 vendors, both sides can decline. Vendor agreements, availability and geography are contractual constraints, so the ranking is constrained optimisation with a learned score inside it. Managed products cannot express the constraints. This is the case where building is right regardless of volume, and where the first version should be rules plus instrumentation, with the model arriving in quarter 2 once you have decline data.

The short version. A good recommender is worth about 12 per cent of engagement against a bestseller list, and most of that is reachable cheaply. Pick the slot before the model. Expect rules to remove a third of what the model ranks. Run a 5 per cent holdout from day 1 or you will never know what you built. And unless you are serving several million requests a month, rent the capability and spend the saved hours on your catalogue data, because that is the part no vendor can fix for you.