Why Most Recommendation Blocks Underperform — and Retailers Don't Know It
Most platforms measure recommendation performance as attributed revenue: any purchase where a recommendation widget was present in the session gets counted toward the custom recommendation engine retail total, whether or not the customer would have bought that product anyway. It's the easiest number for a dashboard to show, and it consistently overstates what the system actually contributed.
McKinsey's research is pretty sobering in its numbers. The study says that personalization usually only increases business revenue by 5-15%. It is a small amount that can hardly reach two digits. This figure is far from what a great number of vendors claim. Moreover, the company clearly explains that this gap comes from the fact that you need a lot of incrementality testing and standardized measurement to determine the real ROI of such personalization. If such testing isn't performed, the retailer is basically measuring the correlation: shoppers who are engaged and at the same time clicking on recommendations. However, it's not an actual effect of the recommendation. (McKinsey & Company, 2025)
That distinction is precisely what most retailers neglect. It is also the main point of the rest of the article: it's not about how complex the algorithm is, but how many different customer-intent signals the product recommendation system retail is serving, and whether each one's contribution can be identified separately rather than being all added up into a single, inflated total.
What This Article Covers
Why generic "customers also bought" logic fails complex catalogs — low purchase frequency, extreme price variance, and compatibility constraints that global co-purchase data can't account for.
Nine recommendation block types in ecommerce — from individually recommended products built on real-time behavior, to co-purchase, co-view, and category/brand fallbacks for visitors with no history at all.
When the algorithm should be manually overridden — seasonal campaigns, new launches, supplier agreements, clearance, and regulatory pulls where a human needs the final say.
How to measure which block actually worked — tracking each block separately and attributing revenue at the transaction level instead of the impression level.
Extending recommendations into push notifications — abandoned cart, price drops, repurchase timing, and back-in-stock s built on the same behavioral recommendation signals.
What data the system needs to run on — the five prerequisites, and what breaks when one of them is missing.
Why Electronics Retail Breaks Generic "Customers Also Bought" Logic
The typical collaborative filtering recommendations that are used by SaaS apps as a default feature to "recommend a product based on who bought this also bought that" will not work for catalogs where product substitution is not allowed, and purchases happen over a long period of time. The electronics retail space falls into that category of product catalogs. And, a combination of five key characteristics of the industry explain why.
Reason 1: Purchase Frequency Is Low and Uneven
Major appliances get bought every three to five years, while accessories turn over more often but come with compatibility constraints that co-purchase data simply doesn't track. This uneven rhythm means a recommendation model trained mostly on frequent, low-consideration purchases will systematically underperform on the big-ticket items that matter most to revenue.
Reason 2: Price Variance Is Extreme
A budget accessory and a flagship appliance can sit side by side in the same catalog, treated as equally valid "similar items" by an algorithm that only looks at purchase frequency, not price context. Consumer research on electronics purchasing shows quality is the top decision factor for 85% of shoppers, with ease of use and price equally important to 78% — meaning the criteria that actually drive a purchase decision vary by price tier in ways a single similarity score can't capture. (Market News, 2026)
Reason 3: Compatibility Matters More Than Popularity
Recommending an accessory because "others also bought it" will be of very little use if such an accessory is not compatible with the customer's device. The only way to make a recommendation useful is to find the correct accessory for that customer, not by popularity, but by compatibility, and purchase-pattern data cannot replace actual knowledge of what fits which device.
Reason 4: Customer Segments Behave Differently
A customer with the company for ages needs suggestions based on buying records over years, whereas a newcomer expects something different. A single algorithm is very unlikely to handle both adequately, because one relies on extensive behavioral data while, in comparison, the other has absolutely nothing to base it on.
Reason 5: Consideration Cycles Vary Wildly by Category
A low-cost accessory is typically an impulse add-on, while a major appliance or high-end device can involve days or weeks of comparison research before purchase. A recommendation logic built for one kind of moment misreads the other — the signals that matter for an impulse purchase, like price and availability, are not the signals that matter for a considered one, like specifications and comparisons.
Overall, these five features converge on a common problem: a catalog of this type presents several different, yet competing shopping scenarios at the same time, and the same similarity function cannot be adjusted to cover only one of them.
Interpreting "similar, " "popular, " and "compatible" as one single, homogeneous piece of data is actually what's making generic recommendation strategies perform poorly; this is why the only architectural solution for the problem would be to actively isolate these signals instead of letting one model guess them all. The decomposition of these signals is the topic of the next section.
Nine Recommendation Block Types — and Why Each One Exists
If a recommender system works on a large and complicated catalog, it is not a single algorithm; it includes a variety of blocks that each have their own purposes and are designed to answer different questions related to what the customer is looking for today. This is the functional schema: there are nine types of blocks, with each providing a unique information that none of the others can duplicate, in addition to the others.
1. Individually Recommended Products
Built from a customer's own recent behavior: items recently purchased, added to cart, favorited, viewed but not bought, or categories recently browsed. This is the most personalized block in the system, since it requires a full behavioral history for that specific customer rather than aggregate data from everyone else.
2. Similar Products
A pre-built list of the most similar items, generated by comparing characteristics, properties, and price. It doesn't require any purchase history at all, which makes it useful for comparison shopping and general catalog discovery regardless of who's browsing.
3. Bought With These Products
A pre-constructed list of items with the highest co-purchase correlation to the product being viewed. This is computed in advance rather than in real time, which keeps it fast even across a catalog with tens of thousands of SKUs.
4. People Who Searched for X Were Also Interested In
Unlike methods that rely on co-purchase, correlation here is co-view; it follows a user's browsing behavior through the products they've looked at together, rather than which items they've bought together. This method records the intent to browse even though no purchase has finally been made, something that is most important for high-consideration products in their long research phase.
5. Bestsellers
Global purchase statistics across the entire catalog, with no personalization applied. Its main job is serving as a fallback for anonymous visitors with no behavioral history at all — the cold-start case every system eventually has to handle.
6. Category Bestsellers
Top sellers shown only in the category the customer has selected. It's a more specific and reliable signal than global bestsellers, because it's reflecting category-level popularity without needing any personal behavioral data.
7. Top Producers or Brands Within Category
The performance of a brand at the level of a single category can be summarized and shown on a chart. This chart is suitable for people who are loyal to a particular brand; for example, electronics consumers usually choose a single brand and stick to it, and this trend is exactly what the graph captures most straightforwardly.
8. Top Brands and Producers Globally
The same brand-level logic, but aggregated across the entire catalog rather than one category. It's used mainly in homepage and navigation contexts, where the goal is broad brand visibility rather than category-specific intent.
9. Top Categories
Category-level aggregated performance data to support product search through a catalog. This is the recommended block for users who are not sure of their needs; they aren't expected to know what they are getting; only that they are browsing.
Each of these nine panels gives a different response to the same question: what does this particular visitor, at this very moment, truly need to see? None of them work by themselves; a bestseller list cannot offer personalization, while a fully personalized block cannot cope with a new visitor who comes to you having no previous history with you. The whole structure operates on the principle that the nine blocks are the very complement of each other, but that a general plugin by itself does not beat them.
Individual Merchandising: When the Algorithm Gets Overridden
After some time of using it, the recommendation architecture will encounter situations where the product recommended is not at all aligned with what the business expects to feature on the page.
For that reason, there has to be another manual layer to override the algorithm's decisions, which can also be used by the merchandising team to create recommendation combinations manually rather than having to rely entirely on the model. In essence, it is, for example, pairing a given product with another product, a product with a category, a category with a category, or matching by shared product attributes, whichever it is that the user needs at that time.
Five scenarios arise frequently enough that one has really no other option but a manual intervention; it's an integral part of the system, not an afterthought.
Seasonal Campaigns
On occasion of shopping events similar to Black Friday, salespeople will be advised on which product lines the company intends to promote through various promotional campaigns but not on any list the algorithm would generate based solely on prior consumer activity. A promotional schedule runs the show, and the model will not get to know its new features until they become a part of it as well.
New Product Launches
A newly listed product has no purchase history yet, which means an algorithm trained on historical co-purchase or co-view data literally cannot recommend it. Manual placement is the only way a new product gets visibility until enough behavioral data accumulates on its own.
Supplier Agreements
Some retailer-brand arrangements are so binding that the former is literally contractually obligated to feature the latter's products in specific placements, which no algorithm is likely to figure out, and the only way that a supplier contract can be respected is that it has to be done manually, regardless of where the model would have wanted to put that product for that brand and that product on which day, if they were in fact the same supplier-contracted brand-product.
Inventory Clearance
When there are no more products to be sold in the inventory, the algorithm recommends the same products over and over again through popularity data. However, clearing out the slow-moving stock is a business priority that the algorithm isn't actually optimizing for at all, and it takes manual overriding to direct customers to purchase those stocks.
Regulatory or Safety-Driven Substitutions
If a product recall or restriction occurs, the product should be immediately removed from every recommendation block so that it is not detected even by the retraining cycle of an algorithm. Here is exactly the place where a manual override is not the merchandising preference but actually a regulatory requirement to keep compliance level up.
Manually placing items here and there, while being a nice touch, is not a good enough reason for a manual change all the time, is it? The rule should be that if you decide to change what an algorithm recommends for a slot, then, to be sure that you're making a good move, you need to A/B test your manual change vs. the algorithm's suggestion, not just theoretically, but the actual results of which change wins click-through or conversion. And it is these facts that make the difference between an arbitrary 'the merchandising team knows best' approach vs. a real 'override which has its roots in factual testing'.
It all comes down to a business factor, i.e., a situation that a regular algorithm knows nothing about, such as a promotional timetable, a legal requirement, or a product recall that will cause the change. Any system whose behavior can't be changed from the outside without manual intervention will not be more clever simply because it performs tasks on its own. It will stay in the dark for all the things that the training examples will not capture.
The Measurement Layer: Knowing Which Block Actually Worked
Attributed revenue tells a retailer that recommendations are on the page. It doesn't tell them the real recommendation engine ROI in retail — which block earned the sale, which one is dead weight, or which one is just stealing clicks from another. It doesn't tell them which block earned the sale, which one is dead weight, or which one is just stealing clicks from another. Closing that gap starts with one foundational choice, and everything else in this section depends on it.
The Foundation: Transaction-Level Attribution
Impression-driven reporting is a method that labels a sale as "a recommended purchase" each time the page visitor was exposed to the corresponding widget. That implies if the customer was going to buy the product anyway, he would be seen as having a "recommendation-driven" purchase just by scrolling past an irrelevant block. Only when it can be shown that from a particular block, via a particular product, a purchase was made, transaction-level attribution is done to a sale. Get this wrong, and nothing built on it means anything.
What This Foundation Unlocks
Block-level performance: metrics like click-through rate, add-to-cart rate, and conversion rate are monitored for each block individually and compared against all blocks on the page, allowing a retailer to know that it was indeed not one of the two, four, five, or other blocks together, but the specific blocks that generated the sale
Category breakdown: a single block type can yield different results when connected to different items. A co-view block generally deserves a spot in high-consideration categories and underperforming commodity ones only after the money from a specific block and category is tied becomes visible.
Seasonality: when seasonal changes cause a drop in performance for some blocks and a peak for others, it is possible to know which blocks to focus on without such information by merchandisers just relying on guesses.
Identifying competing blocks: one block could have a higher conversion rate than another and yet contribute nothing, since customers may have been diverted from a block that would have converted them anyway. To detect cannibalisation, one should look at the conversion rate at the page level both with and without the block, or hold back the new block from a portion of the traffic and watch if the overall conversion rate moves.
A Real, Narrowly Scoped Example
In one Evinent e-commerce engagement with an Eastern European retailer, a six-plus-year collaboration, the conversion rate for search results increased by 23% following improvements to search functionality and AI product recommendations ecommerce, as validated through A/B testing against the legacy platform. The number is worth citing for one reason: it was tested, not attributed. It says nothing about the nine-block architecture, electronics retail, push notifications, or manual merchandising — it's evidence that testing a specific, scoped change against a baseline is what turns a claimed improvement into a measured one.
None of measuring things for the sake of being able to present facts is the issue. Rather, the merchandising team obtains a concrete answer rather than a general one that says this block in this category during this time period is justifying its placement and this one isn't. This is the decision manual overrides in the next section rely on being able to make confidently, and not via intuition.
Push Notifications as the Recommendation Channel Beyond the Site
It is possible that architecture not only refers to the website. Besides individually recommended products and re-targeting of products that have been viewed but not purchased, the same behavioral signals that feed the on-site blocks of content can also push a message to the customer off-site, for example via a text message or an e-mail. In this way, it's possible to present the customer with relevant offerings in a channel that they are actively using most of the time; it just has to be their phones.
Abandoned Cart Reminder
Triggered when a customer adds an item (or items) to the cart and leaves the site without completing a purchase. A notification shows up with the items in the cart, and a suggestion for an accessory that would go well with the items in the cart. The idea is not just to remind a customer to complete the purchase, but to also increase sales by a little bit as a secondary benefit.
Price Drop
Triggered by repeat views of the same product captured in behavioral history — the same signal that feeds the "viewed but not purchased" segment of block 1. When the price on a product a customer has returned to multiple times finally drops, the fires at the moment it becomes relevant, not on a fixed schedule.
Repurchase Trigger
Built for consumables, cables, batteries, ink, that historical purchase cycle can be used to guess roughly when the customer will need to purchase again. However, rather than sending out an indiscriminate "you might also like" message, the app gives a warning well in advance, and the timing is aligned with the actual usage pattern instead.
Deal-of-the-Day
The recommendation should be tailored more precisely according to a customer's category of browsing history rather than being a general promotion. A customer browsing headphones would receive a headphone offer, not a storewide day's discount.
Back-in-Stock
Triggered when a customer views or attempts to add an out-of-stock item — captured by the same "viewed but not purchased" signal from block 4. The notification fires the moment inventory syncs back, catching interest at the point it was originally expressed rather than hoping the customer checks back on their own.
None of these five features can stand on their own as a communication tool. Each of them takes the same signal from block 1, which is a customer's past purchase and viewing behavior, and instead of attaching a different system afterwards, they channel that via a different medium but at a different moment each time.
What Makes This Work: The Data Requirements Behind the Architecture
None of the design mentioned so far nine modules, manual bypasses, or transaction-level metrics would function without the right flow of data into it. These five conditions are not just helpful; they are essential; the entire mechanism relies solely on them.
Requirement | Feeds | What Breaks Without It |
Transaction history depth | Co-purchase and time-dependency models (e.g., "bought with these products") | Recommendations default to broad, catalog-wide correlations instead of category-specific ones |
Real-time behavioral tracking | Individually recommended products | The most personalized block quietly degrades into a bestseller list |
Loyalty program integration | Personalization depth, customer segment | System can't distinguish a first-time visitor from a loyal customer |
ERP and catalog sync | Similar products, stock/pricing accuracy | Recommends out-of-stock, discontinued, or mispriced products |
Identity resolution | Linking anonymous sessions to loyalty profiles | A loyal customer's browsing gets treated as anonymous, disconnected from purchase history |
Evinent Analytics is the platform that unifies these five data sources and powers the block architecture, the manual override layer, and the push notification triggers described earlier in this article. Evinent GmbH is certified under ISO 9001:2015 for software product development and development services, and has built and maintained production retail recommendation analytics systems for retail clients over a multi-year track record — the kind of operational discipline this architecture depends on to run reliably at scale.
From Theory to Production: Evinent's Retail Engagement
The complex architecture mentioned in the article, consisting of nine segments, manual overrides, transaction-level performance metrics, and notification systems based on changes or updates, will need to be developed and supported by someone. The system does not work alone, and it cannot maintain its precision if there are major changes, sudden rushes of customers, or if there is a product launch. One company that has successfully implemented a system of this type is Evinent.
Evinent works across retail, e-commerce, healthcare, and HR technology, with a focus on modernizing legacy systems and staying on projects long-term rather than delivering code and moving on. The company states it has over 15 years of software development experience.
Evinent Analytics: The Platform Behind the Architecture
Evinent Analytics is the product that ties this article's architecture together. It unifies the five data sources this system depends on behavioral tracking, loyalty data, ERP and catalog sync, and identity resolution and uses them to power both the on-site recommendation blocks and the push notification layer described earlier. It isn't a separate tool bolted alongside the recommendation system; it's the data layer the whole architecture runs on.
The Case: Six Years, One Retailer, A Measured Result
The clearest real-world example of this in production is a six-year-plus dedicated development engagement with an Eastern European e-commerce retailer. The project covered a full-scale digital transformation: auto-scaling cloud infrastructure to handle peak traffic, an overhaul of the catalog and order management system, two mobile applications — one for customers, one for store managers and the rollout of Evinent CMS and Evinent Search.
The search and recommendations component was specifically tied to a measured 23% increase in search result conversion rate, validated through A/B testing against the legacy platform. That result demonstrates a working search-and-recommendation layer in production and the kind of measurement discipline this article has argued for throughout — it is not presented as proof of the full nine-block system described earlier, which is a separate, broader architecture.
Why This Holds Up in Regulated and High-Traffic Environments
Certified for software product development and development services according to ISO 9001:2015
Combination of healthcare and retail engagements, each having its own data security and compliance rules that have to be strictly followed
Constant working team approach: the one team works with you constantly, not like with the typical handing over post-launch, which is why the retail project mentioned above has run for more than six years, not only initially
History of production in both regulated and high-traffic environments, not only one industry sector
FAQ
1. How many types of recommendation blocks should a retail ecommerce site use?
There is no one-size-fits-all number, but a system that relies on a single block like the standard "customers also bought" widget can only interpret one kind of intent signal. The nine-block model discussed in this article is different from the other blocks in the sense that it is not limited to only one thing: the block of "individually recommended products", and it also covers similarity, co-purchase, co-view, and category/brand aggregates at various levels because each one addresses a need the others cannot. Catalogs of lesser size may even not need all nine blocks, but if we rely only on one or two, the majority of customer intent remains unaddressed.
2. What is the difference between co-purchase and co-view recommendation logic?
Co-purchase logic is based on the things customers were buying together, while co-view logic includes the products the customers were also viewing when the one product is being bought. Co-view reveals the customer's purchase intention earlier, even if they end up not buying the product. For the products where a long research period takes place before the buying decision, this aspect (the intention revealed by co-view) is very important.
3. When does a custom ecommerce recommendation engine enterprise outperform a SaaS solution in retail?
Generally, once a catalog has enough complexity that standard collaborative-filtering plugins start breaking down — extreme price variance, compatibility constraints, low purchase frequency, or customer segments that need very different treatment. Below that complexity threshold, an off-the-shelf plugin is usually a faster and cheaper way to get most of the value. Above it, a custom system's ability to separate distinct blocks and override them manually starts to matter more than convenience.
4. How do you measure the real ROI of product recommendations without overattribution?
By attributing revenue at the transaction level instead of the impression level — counting a sale only when a customer's path can be traced from a specific block to a specific product to a completed purchase, not simply because a widget was visible somewhere in the session. Testing changes against a holdout or control group is what separates a real lift from a number that just looks good on a dashboard.
5. What data does a retail recommendation system need to personalize at the individual level?
Five things, at minimum: enough transaction history to make co-purchase patterns meaningful at the category level, real-time behavioral tracking of browsing and cart activity, loyalty program data tied to purchase history and segment, ERP/catalog sync so recommendations reflect current stock and pricing, and identity resolution to connect an anonymous visitor's session to their existing profile once they log in. Missing any one of these doesn't break the system outright, but it quietly degrades the most personalized blocks back into generic ones.
Key Takeaways
Attributed revenue isn't incremental lift. Most dashboards count a sale as recommendation revenue any time a widget was visible, not because it changed behavior. That overstates what the system is worth.
Complex catalogs break generic logic. Standard "customers also bought" plugins work on simple catalogs but fail where purchase frequency is low, prices vary widely, and compatibility matters more than popularity.
A single algorithm won't fulfill each purpose. Nine-block architecture functions because each block covers a different area that the other blocks don't, as opposed to being smarter than a plugin.
The algorithm shouldn't always win. Seasonal campaigns, new launches, supplier agreements, clearance, and regulatory pulls all need manual override, tested against the algorithm rather than applied on authority.
Transaction-level attribution starts everything off. Performance at the per-block level, category breakdown, and cannibalization checks will be meaningful only when revenue is associated with a specific block and purchase.
The same behavior patterns trigger notifications off-site too. It's the cart abandonment, checkout prices, purchasing again, and stock s that trigger notifications get fired. These signals are also the data that drive the on-site blockages.
None of this works without the right data. Transaction history, real-time tracking, loyalty integration, ERP sync, and identity resolution are prerequisites. Missing one quietly degrades the system's most personalized blocks.
Share
