Product Recommendations for a First Purchase Are a Fallback, Not a Model

Product recommendations shown to a first-time visitor are not the output of a personalization model, because every major engine publishes a minimum amount of behavioral data before its personalized models will train, and one anonymous session clears none of it. What that shopper sees is the vendor's documented fallback. Which means the work that moves first-purchase conversion sits in your catalog and your popularity window, not in algorithm selection, and it connects directly to how onsite and lifecycle messaging get built.

The guides written for this topic say something softer. They advise a "hybrid approach" that blends collaborative filtering, content similarity, and popularity, as though the three were interchangeable dials you set. An earlier version of this post said exactly that. The problem with the advice isn't that it's wrong, it's that it hides the only decision you actually get to make. Collaborative filtering is off the table for a visitor with no history. Popularity and content similarity are what's left. So the interesting question was never which family of algorithm to pick. It's how good your two fallbacks are.

Here's the part that settles it, from the vendor least likely to undersell machine learning. In Google's table of minimum data requirements for AI Commerce Search recommendation models, one row lists its user event requirement as "None required." That row is Similar Items, and Google describes it as a model that "requires only information from the product catalog." The zero-data recommendation model already exists, it ships from Google, and what it reads is your product copy.

The short version

• Amazon Personalize won't create a recommender below 1,000 unique item interactions and 25 unique users with at least two interactions each.
• Its own quality bar is higher: 50,000 item interactions from at least 1,000 users with two or more interactions each.
• Google's floor for "Others You May Like" optimized on click-through rate is 100 unique catalog items with detail-page-view events plus 10,000 of those events in the last 90 days.
• Google's floor for "Recommended for You" adds 10,000 home-page-view events in the same window.
• Google's floor for Frequently Bought Together is 100 unique items with purchase events and 1,000 purchase-complete events, measured over a full year.
• Google's floor for Similar Items is "None required" for events, and 100 product SKUs in a branch.
• Similar Items "works best when there are at least 10 description words on average," which makes catalog copy a ranking input.
• Amazon Personalize defines a cold item as an item with fewer than five interactions.
• Its SIMS recipe needs three or more users who interacted with both items before it will score a pair as similar, by default.
• When either co-occurrence recipe can't find enough data, both fall back to popular items. That fallback is documented, not accidental.
• Trending-Now falls back to popular items outright if zero interactions arrive over the last two trend intervals.
• Shopify's algorithm ignores orders imported from another platform, so a migrated catalog starts cold on purchase history.
• Shopify associates up to 10 products per product and advises showing four.
• Click-through rate is Google's default optimization objective on two of its three main recommendation models, and the objective can't be changed after training.
• The one recent benchmark with a published method, from Wisepops in July 2026, puts a typical store at a 9.1 percent click rate with about 4 percent of clicks becoming orders. That's roughly four orders per 1,000 shoppers shown a recommendation.
• Correction: the McKinsey 10 to 15 percent revenue lift figure this post used as a target is from November 2021, describes company-wide personalization, and carries no source on McKinsey's page.

Cold start is a data floor with a published number on it

"Cold start" gets written about as a modeling puzzle. In practice it's an eligibility check, and the vendors publish the thresholds. Below the floor the platform either refuses to train or quietly serves you something simpler, and knowing which number you're short of tells you what to fix.

Two lines in Google's documentation kill the obvious workarounds. On backfilling: "The data collection window represents the period for user events; importing more historical data has no effect on model quality." Three years of clickstream doesn't buy you a shorter path, because the model only reads the window. And on faking it: "Make sure to use real user events and real catalog data. Good quality models can't be built on synthetic data." So the floor is a floor, and the only two ways through it are traffic and time.

Read the table by column instead of by row and the shape of the problem changes. Everything that needs purchase events needs a year. Everything that needs view events needs 90 days and five figures of volume. Exactly one row needs neither. For a store that just launched, or a catalog that just doubled, or a visitor who arrived 40 seconds ago, that one row is the whole product.

The fallback ladder every recommender lands on

Sort the recommendation types by what identity and history each one requires and they form a ladder, not a menu. A first-time visitor starts on the bottom rung and can climb at most two rungs inside one session. Nothing about that is a limitation of your vendor. It's arithmetic about what has happened so far.

The ladder explains a failure mode worth naming. Teams buy a rung-five product, deploy it to traffic that's mostly first-time, and evaluate it on a metric the vendor computes from widget clicks. What that setup actually measures is the quality of rungs one and two, because that's what most sessions received. The model was never the variable.

Rung one: your product copy is the model

When there are no events, similarity is computed from catalog text and attributes, so catalog quality is model quality. Google states the requirement in two sentences on the same page as the model description: descriptions "should be explanatory for each product and contain unique information or words separate from the title," and the feature "works best when there are at least 10 description words on average."

Shopify's version of the same rule is a fallback chain. Its documentation lists purchase history and product description as the criteria used for all merchants, then adds a third: related collections, used by "all merchants when purchase history and product description recommendations aren't available." So on a new Shopify store the recommendation engine is your collection structure, and on a store with thin product copy it's your collection structure again. Fixing the copy is the cheapest recommendation upgrade available.

The honest limit, from the same Google page: Similar Items "can neither be tuned nor personalized," and Google advises creating only one such model per project because duplicates on the same events produce identical results. This rung is a good floor, not a growth lever. You get it working and then you stop touching it.

Rung two: popularity is a window, not a list

Bestsellers are the default first-session recommendation everywhere, and the decision inside them is the time window, not the ranking. Amazon Personalize exposes that choice directly in its Trending-Now recipe, where you set a trend discovery frequency of 30 minutes, one hour, three hours, or one day, and the model surfaces items with the greatest rate of increase in interactions since the last evaluation.

Two documented behaviors matter more than the ranking math. First, the fallback: "If you import zero interactions over the last two time intervals, Amazon Personalize recommends only popular items instead of trending items." Pick a 30 minute window on low overnight traffic and your trending block silently becomes an all-time bestsellers block. Second, the flatness: Popularity-Count "returns the same popular items for all users," which Amazon frames as a baseline for comparison rather than a strategy. If your rung-five model can't beat it on your own holdout, you learned something expensive.

The practical version for a first-purchase block is two windows side by side. A short one, 24 hours to seven days, catches what's moving now and keeps seasonal items from going stale. A long one, 90 days, keeps the block stable on low-traffic days. Which one wins is a test, and it's a cheaper test than swapping engines.

Rung three: co-occurrence needs three people, not three thousand

"Frequently bought together" feels like it needs enormous data. The per-pair threshold is small and the catalog-wide threshold is large, and confusing the two is why this block underperforms on long-tail items. Amazon Personalize's SIMS recipe exposes the per-pair number as a hyperparameter, min_cointeraction_count, defaulting to three: "a value of 3 means that you need three or more users who interacted with both items for the algorithm to calculate their similarity."

Google's threshold sits at the other end. Frequently Bought Together needs 100 unique catalog items with purchase events, 1,000 purchase-complete events, and 10 purchases per item on average, all measured across a full year rather than 90 days. So the pair is cheap and the model is expensive, and until the model qualifies, the pair-level logic you can hand-build from your own order data will outperform an untrained recommender.

Both engines document what they do when they come up short, and it's the same thing. Personalize's Similar-Items recipe: "If Amazon Personalize can't find the item ID that you specify in your recommendation request or batch input file, the recipe returns popular items as recommendations." SIMS: "If there isn't sufficient user behavior data for an item or the item ID you provide isn't found, SIMS recommends popular items." Personalize also defines the boundary numerically, calling an item with fewer than five interactions a cold item.

One more default worth reading before you blame the model for ignoring your new arrivals. SIMS ships with min_item_interaction_count_percentile at 0.01, which excludes the bottom percentile of items by interaction count from training, and Amazon's own note on it says "items with a short history often are new items." The tool is doing what it was configured to do. Amazon's counterweight is exploration, on by default at a weight of 0.3, with an item age cutoff of 30 days, which deliberately mixes in items with little interaction data. Both facts are in Amazon's docs, and they pull in opposite directions on purpose.

Rung four: the session is the only personalization you get

A first-time visitor gives you one visitor-specific signal, and it's a sequence rather than a profile. Three product views inside one category, two minutes on a size guide, a click into shipping terms. None of that is enough to train anything, and all of it is enough to filter and re-rank what rungs one to three already produced.

Treat it as plumbing, not modeling. The signals that mean something in a first session are narrow: repeated views inside one category, a price band the visitor keeps returning to, time on a size or fit page, a shipping or returns page view before any add to cart, and a comparison or bundle page view. Each of those maps to a filter on an existing block. Category concentration sets the candidate pool. The price band sets a floor and ceiling. A returns-page view is a trust signal, and the right response is a fit guide or a review snippet next to the block, not a different product.

The identity plumbing underneath has to hold up, and Google's data-quality docs are specific about how it fails. They ask for a consistent visitor ID tracked across events and search requests, want more than a 10 percent match rate of visitor IDs between requests and events, and warn against caching personalized results, which they detect when multiple events with different visitor IDs share one attribution token. A block that looks personalized and is actually a cached page is the most common version of this bug, and it reads as a model failure.

Where to put them, and what each surface already tells you

Placement isn't a layout preference. Each surface hands you a different amount of intent, and the block should match what's known at that point rather than repeat the same carousel four times. Homepage knows nothing. A product page knows one product. A cart knows a commitment.

• Homepage, anonymous: trending now, bestsellers, new in. Rung two only, and keep the count low so the block reduces choices instead of adding them.

• Product page: similar items, complete the look, frequently bought together, top rated in category. Rung one always works here. Rung three works only on items past the co-occurrence threshold, so check coverage before you ship it site-wide.

• Cart and checkout: low-cost complements, on-sale add-ons, and a free-shipping threshold nudge. Constrain the price band here. An expensive suggestion at checkout reopens a decision the shopper already closed.

• Category page: top sellers and trending inside the current category, filtered to it. Dynamic Yield's guide claims case studies show over 70 percent of products purchased by category-page browsers appear in the first two rows, which is a vendor claim with no named study attached, so treat it as a reason to test row order rather than a number to quote.

Shopify puts a hard ceiling on the product-page block that's worth knowing: the algorithm associates up to 10 products with each product, in relevance order, and Shopify's own advice is to show four. It also excludes out-of-stock items, items priced at zero, gift cards, and anything already in the visitor's cart. That last exclusion is free logic most custom implementations forget.

Carry the same ranking into email and onsite messages

A browse-abandon email that recommends different products than the onsite block the visitor just left is two systems disagreeing in front of a customer. The ranking should be computed once and reused, which is the actual argument for keeping catalog, events, and messaging in one place rather than stitching a recommendation vendor to an email vendor.

For a first-time visitor there's a consent constraint too, and it decides the channel order. No email address means the only reachable surface is onsite, so the first-session play is an onsite message and the email play starts at the point an address exists. Getting that sequence backwards is how browse-abandon programs end up with high open rates and no first orders. The same logic runs through cart abandonment work, where the reachable channel changes the whole plan.

The numbers everyone quotes, and what they measure

Three figures circulate in every article on this topic. All three are real quotes. None of them measures incremental revenue from a recommendation block shown to a first-time visitor, and the gap between what they measure and what you need is the whole problem with benchmarking this work from other people's data.

The Wisepops figure is the most useful of the three because the method is published, and it's worth finishing the arithmetic they leave open. A 9.1 percent click rate with 4 percent of clicks converting is about four orders per 1,000 shoppers who saw a recommendation. That's a real number and it isn't a lift number. Read the rest of their page for the full picture: it opens with "22 percent of online revenue influenced by product recommendations" for one brand, and "influenced" is carrying the weight there, since a shopper who clicks a recommendation for the item they were already going to buy is counted. Their own strategy advice agrees with the ladder above, incidentally: "Show best sellers to first-time visitors, since you have no history yet."

Recommendations optimize for whatever you told them to

A recommendation block can raise clicks, raise revenue, and lower gross profit at the same time, and the setting that causes it is a default. Google names click-through rate as the default optimization objective for both "Others You May Like" and "Recommended for You." Out of the box, those models maximize the odds a shopper interacts with the block.

Switching objectives helps and doesn't solve margin. Google's revenue-per-session objective "combines information from clicks, conversions, and item prices to help the model recommend items that have higher prices and a higher probability of being purchased." Higher price is not higher margin, and on most catalogs the two diverge sharply by category. The conversion-rate objective goes the other way, maximizing add-to-carts, which tends to favor cheap items. There's no objective on the menu called profit.

The commitment is real, too: "After you have trained a model, you cannot change the optimization objective. You must train a new model to use a different optimization objective." So margin has to enter the system somewhere you control. Two places work. Rank candidates by predicted profit rather than predicted revenue, using your own cost data, and enforce a price band per surface so a checkout block can't surface a higher-priced substitute for the item in the cart.

Measure it with a holdout or don't quote the number

Every number a recommendation vendor reports to you is computed from interactions with its own widget, which means it counts purchases the shopper would have made anyway. The correction is a holdout, and it's the same correction that makes any attribution number trustworthy. Without one, "revenue influenced by recommendations" grows every time you add another block.

1. 1Hold out a random slice of first-time sessions, 10 to 20 percent, and show them no recommendation blocks at all. Not a different block. None.
2. 2Measure revenue per visitor on both groups, not click rate. Click rate tells you the block was noticed, which you already knew.
3. 3Track first-order conversion rate separately from overall conversion rate, since returning-visitor orders will otherwise swamp the effect you're testing.
4. 4Watch gross margin per visitor alongside revenue per visitor. A block that shifts the mix toward cheap complements can raise one and lower the other.
5. 5Check coverage before you read the result. If rung three only has candidates for 20 percent of your catalog, you tested a block that was empty most of the time.
6. 6Re-run it after any catalog change large enough to move the popularity window. The result was true for one assortment.

This is ordinary experiment design, and the reason it gets skipped on recommendations specifically is that the vendor dashboard already shows a number that looks like the answer. Our write-up on what changes about conversion testing covers the holdout discipline in more detail, and revenue attribution failing on three clocks covers why the platform-reported version of the same number can't be compared across tools.

Blu Agent

Before you evaluate any recommendation engine, compute coverage. For each surface, what share of your catalog has enough co-occurrence data to fill the block, and what share falls through to popularity? On most catalogs under 5,000 SKUs the answer is that the fallback is serving the majority of impressions, which means the fallback is the product you're actually buying.

Where Intempt fits, and where it doesn't

Intempt is the agentic GTM platform, and on this topic it works the layer around the recommender rather than replacing one. The catalog, the web and product events, the identity graph, and the messaging all sit on one profile, so the ranking computed for an onsite block is the same ranking an email uses, and the first-order conversion you measure is a revenue event rather than a widget click. The first purchase cohort LTV curve report is what that shared foundation makes possible once catalog and events are connected, and ecommerce personalization software covers how the category splits if you're comparing tools.

What it isn't: a deep-learning recommender competing with Amazon Personalize on model quality at scale. If you're above Google's and Amazon's data floors and your bottleneck is genuinely model accuracy, those are the right tools and their documentation is the best free reading in the category. Below the floors, which is where first-purchase traffic lives, the bottleneck is catalog quality, window selection, and honest measurement, and those are not modeling problems.

Search demand for this topic, checked

The exact phrase this post used to target has no measurable search volume, and the demand pattern is worth knowing because it shows what buyers are actually stuck on. All figures are US monthly volume from DataForSEO, pulled in July 2026.

The cost-per-click column is the tell. "Cold start problem" gets 590 searches at $2.02, which is close to free, because it's a theory query that mostly attracts students and blog readers. "Shopify product recommendations" gets a quarter of that traffic at 17 times the click price, because someone with a storefront is trying to make a specific block work today. The money follows implementation, and implementation is where the vendor documentation matters more than the concept does.

What this post corrected

• Contextualized: the McKinsey "10 to 15 percent revenue lift" figure. It's a real quote from November 12, 2021, it describes company-wide personalization rather than first-purchase blocks, and the sentence begins "Research shows" with no citation on McKinsey's page. It's no longer presented as a target to aim at.
• Replaced: the "use a hybrid approach" advice, which described choosing among three algorithm families when a first-time visitor makes two of them unavailable. The fallback ladder replaces it with what's actually reachable at each stage.
• Added: the published data floors from Amazon Personalize and Google's AI Commerce Search, which were the missing fact in the earlier version. The post argued cold start was solvable with configuration without saying what the thresholds are.
• Added: Shopify's documented exclusion of imported orders, which changes the recommendation plan for any migrated store and appears in none of the competing pages checked for this rewrite.
• Fixed: currency symbols in four places, which were rendering as mojibake, and switched them to dollars to match the rest of the site.
• Added: a holdout requirement. The earlier version said to test for incrementality without specifying what the control group is, which is the one detail that makes the test meaningful.

The useful reframe is that a first-time visitor isn't a modeling problem waiting on a better algorithm. It's a shopper looking at a catalog you control, in a session you can read, and the two levers that move them are how well your products are described and how honestly you measure what the block changed. Get those right and product recommendations start converting first-time buyers with the tools you already have, which is the layer Intempt is built to run.