Why Your Adobe Commerce Recommendation Engine Is Leaving Revenue on the Table And How to Fix It
Why Your Adobe Commerce Recommendation Engine Is Leaving Revenue on the Table And How to Fix It
为什么您的 Adobe Commerce 推荐引擎正在流失收入，以及如何修复它
You’ve set up “Customers Also Bought” and “Related Products” in your Adobe Commerce store. But customers still aren’t clicking those recommendations. Conversion rates stay flat. This is one of the most common pain points in enterprise Commerce stores and the fix is simpler to understand than you might think. 您已经在 Adobe Commerce 商店中设置了“购买此商品的客户也购买了”和“相关产品”功能。但客户仍然没有点击这些推荐，转化率也停滞不前。这是企业级电商商店中最常见的痛点之一，而其解决方案比您想象的要简单得多。
When Adobe Commerce recommends products to a shopper, it usually does it with fixed rules: “If someone buys X, show Y.” These rules are written manually or based on very basic logic. That works fine when your store is small. But as your product catalogue and customer base grow, these rules can’t keep up: 当 Adobe Commerce 向购物者推荐产品时，通常使用固定规则：“如果某人购买了 X，则显示 Y。”这些规则是手动编写的，或者基于非常基础的逻辑。当您的商店规模较小时，这运行良好。但随着产品目录和客户群的增长，这些规则就无法跟上步伐了：
- They don’t learn from new customer behaviour
- They show the same suggestions to everyone
- They slow down or break when you have millions of products and customers
- They can’t handle the traffic spike on Black Friday
- 它们无法从新的客户行为中学习
- 它们向所有人展示相同的建议
- 当您拥有数百万种产品和客户时，它们会变慢或崩溃
- 它们无法应对“黑色星期五”期间的流量激增
A research study published in Discover Computing confirmed exactly this: when stores tried to scale their recommendation engines on a single server, performance collapsed. But stores using a distributed system (spread across multiple servers) could handle 15.6 times more data with only 3.5 times more processing time. That’s a massive difference. 发表在《Discover Computing》上的一项研究证实了这一点：当商店试图在单台服务器上扩展其推荐引擎时，性能会崩溃。但使用分布式系统（分布在多台服务器上）的商店在处理 15.6 倍数据量的情况下，处理时间仅增加了 3.5 倍。这是一个巨大的差异。
The Solution: A Smarter, Two-Part Recommendation Engine
解决方案：更智能的双部分推荐引擎
The fix combines two types of recommendation logic working together. 该修复方案结合了两种协同工作的推荐逻辑。
Part 1: “What Do Similar Customers Buy?” (Behaviour-Based) 第一部分：“相似的客户买了什么？”（基于行为）
This part looks at patterns in your customer data: who bought what, what they viewed, what they added to their wishlist. It groups customers with similar tastes and uses that to predict what a shopper is likely to want next even if they’ve never seen that product before. In Adobe Commerce terms, it learns from: 这部分着眼于客户数据中的模式：谁买了什么、浏览了什么、将什么添加到了愿望清单中。它将品味相似的客户归为一组，并利用这一点来预测购物者接下来可能想要什么，即使他们从未见过该产品。在 Adobe Commerce 中，它学习的数据源包括：
- Past orders (the strongest signal)
- Product page views
- Cart additions and abandoned carts
- Wishlists
- 历史订单（最强的信号）
- 产品页面浏览量
- 加入购物车和弃购行为
- 愿望清单
The catch: this only works once a customer has done at least 5 things on your store. Brand new customers have no history, so this part can’t help them yet. 难点在于：这仅在客户在您的商店中至少完成 5 次操作后才有效。全新的客户没有历史记录，因此这部分暂时无法为他们提供帮助。
Part 2: “What Products Are Similar to This One?” (Product-Based) 第二部分：“哪些产品与此产品相似？”（基于产品）
This part looks at the products themselves—their names, descriptions, categories, materials, brands—and finds products that are genuinely similar. It doesn’t need customer history at all. It works the moment a product is added to your catalogue. In Adobe Commerce, it reads from native product attributes: name, description, category path, and custom attributes like size, colour, or material. 这部分着眼于产品本身——它们的名称、描述、类别、材质、品牌——并找到真正相似的产品。它完全不需要客户历史记录。产品一添加到您的目录中，它就能立即生效。在 Adobe Commerce 中，它读取原生的产品属性：名称、描述、类别路径以及尺寸、颜色或材质等自定义属性。
The catch: it doesn’t know what an individual customer personally prefers, it just knows what’s similar. 难点在于：它不知道个人客户的偏好，它只知道什么是相似的。
Combining Both: The Hybrid Score
两者结合：混合评分
The real power comes from using both together: 真正的威力来自于将两者结合使用：
Final Score = 60% behaviour signal + 40% product similarity 最终评分 = 60% 行为信号 + 40% 产品相似度
This balance was tested and validated. When both signals are combined, the recommendations are better than either one alone. How much better? Here’s the proof from the research: 这种平衡经过了测试和验证。当两种信号结合时，推荐效果比单独使用任何一种都要好。好多少？以下是研究证明：
| Recommendation Type | Accuracy Score (lower = better) | 1-in-10 Precision |
|---|---|---|
| Behaviour-based only | 1.02 | 70% |
| Product similarity only | — | 64% |
| Combined (hybrid) | 0.94 | 74% |
| 推荐类型 | 准确度评分（越低越好） | 1/10 精准度 |
|---|---|---|
| 仅基于行为 | 1.02 | 70% |
| 仅基于产品相似度 | — | 64% |
| 混合（组合） | 0.94 | 74% |
That 74% precision means: out of every 10 products recommended, about 7 or 8 are genuinely relevant to that customer. That’s what moves your “add to cart from recommendation” numbers. 74% 的精准度意味着：每推荐 10 个产品中，大约有 7 到 8 个是与该客户真正相关的。这就是提升您“从推荐中加入购物车”数据的关键。
What About Brand New Customers?
那么全新的客户怎么办？
This is the question every Commerce architect asks first. If a customer just landed on your store for the first time, you have zero history on them. Here’s how the hybrid approach handles it: 这是每位电商架构师首先会问的问题。如果客户是第一次访问您的商店，您对他们没有任何历史记录。混合方法是这样处理的：
- For a new visitor: Show products similar to whatever they’re currently looking at (product similarity kicks in immediately).
- If they’re on the homepage: Show globally popular or trending products.
- Once they’ve done 5+ things: (viewed, added to cart, purchased), start personalising for them specifically.
- 对于新访客： 展示与他们当前正在查看的产品相似的产品（产品相似度立即生效）。
- 如果他们在首页： 展示全球热门或趋势产品。
- 一旦他们完成了 5 次以上操作：（浏览、加入购物车、购买），就开始为他们进行个性化推荐。
For a newly added product:
- Product similarity works straight away, it just reads the product’s attributes.
- After the product gets 10+ purchases, the behaviour-based engine picks it up too.
- No manual rules needed. The system handles it automatically. 对于新添加的产品：
- 产品相似度立即生效，它只需读取产品的属性。
- 在产品获得 10 次以上购买后，基于行为的引擎也会将其纳入考量。
- 无需手动规则。系统会自动处理。
Why You Need More Than One Server
为什么您需要多台服务器
This is the part most people skip and it’s where most recommendation engines fall apart at scale. The research tested this on a small 3-server setup (1 coordinator + 2 workers, each with 2 processors and 8GB of memory). Even on that modest setup, the results were striking: 这是大多数人忽略的部分，也是大多数推荐引擎在规模化时崩溃的地方。该研究在一个小型 3 服务器设置（1 个协调器 + 2 个工作节点，每个节点配备 2 个处理器和 8GB 内存）上进行了测试。即使在如此简陋的配置下，结果也令人震惊：
| Number of Products Processed | Time to Train the Model |
|---|---|
| 60,000 | 12.8 seconds |
| 160,000 | 18.5 seconds |
| 360,000 | 32.3 seconds |
| 945,000 | 45.4 seconds |
| 处理的产品数量 | 模型训练时间 |
|---|---|
| 60,000 | 12.8 秒 |
| 160,000 | 18.5 秒 |
| 360,000 | 32.3 秒 |
| 945,000 | 45.4 秒 |
Going from 60K to 945K products—nearly 16× more data—only made training take 3.5× longer. On a single server, that gap would be far worse. 从 6 万个产品增加到 94.5 万个产品（数据量增加了近 16 倍），训练时间仅增加了 3.5 倍。在单台服务器上，这个差距会严重得多。
What happens if a server goes down? The research tested this too. They deliberately switched off one of the three servers mid-process. The other two servers had enough copies of the data to continue without missing anything. The job finished. When the third server came back online, the system recovered on its own. For a Black Friday environment, this is the difference between a slow recommendation widget and a completely broken one. 如果服务器宕机了怎么办？研究也测试了这一点。他们在处理过程中故意关闭了三台服务器中的一台。另外两台服务器拥有足够的数据副本，可以继续工作而不会丢失任何内容。任务顺利完成。当第三台服务器重新上线时，系统自动恢复了。对于“黑色星期五”的环境来说，这就是推荐组件“变慢”与“彻底崩溃”之间的区别。
How This Fits Into Your Adobe Commerce Setup
这如何融入您的 Adobe Commerce 设置
You don’t need to rip out your existing store. This sits alongside it as a separate service. 您无需拆除现有的商店。它作为一项独立的服务与您的商店并存。
Step 1: Collect the data Adobe Commerce already tracks orders, views, and wishlists. You export this data out of MySQL (Commerce’s built-in database) into a separate data store designed for large-scale processing. MySQL isn’t built for this kind of analysis at scale. Each interaction becomes a simple record: customer ID, product ID, and a signal strength (purchase = strongest, view = weakest). 第一步：收集数据 Adobe Commerce 已经跟踪了订单、浏览和愿望清单。您将这些数据从 MySQL（Commerce 的内置数据库）导出到专为大规模处理而设计的独立数据存储中。MySQL 并非为这种规模的分析而构建。每次交互都成为一条简单的记录：客户 ID、产品 ID 和信号强度（购买 = 最强，浏览 = 最弱）。
Step 2: Train the models Once a day (or twice a day for faster-moving catalogues), you run the training process. It reads the interaction data, runs the behaviour model and product similarity model, and produces a list of top recommendations for each customer. This happens in the background — not while customers are on your site. 第二步：训练模型 每天（或对于更新更快的目录，每天两次）运行训练过程。它读取交互数据，运行行为模型和产品相似度模型，并为每个客户生成一份最佳推荐列表。这是在后台进行的，而不是在客户访问您的网站时进行的。
Step 3: Serve the recommendations fast The pre-calculated recommendation lists get stored in Redis, the fast in-memory cache that most Adobe Commerce production stacks already use. 第三步：快速提供推荐 预先计算好的推荐列表会被存储在 Redis 中，这是大多数 Adobe Commerce 生产环境堆栈已经在使用的高速内存缓存。