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.

---

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:

• 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.

---

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:

• 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.

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.

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

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:

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.

---

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:

1. Show products similar to whatever they're currently looking at (product similarity kicks in immediately)
2. If they're on the homepage, show globally popular or trending products
3. Once they've done 5+ things (viewed, added to cart, purchased), start personalising for them specifically

For a newly added product:

1. Product similarity works straight away, it just reads the product's attributes
2. After the product gets 10+ purchases, the behaviour-based engine picks it up too

No manual rules needed. The system handles it automatically.

---

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:

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.

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

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).

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.

When a shopper loads a product page, your storefront calls a simple API, gets their personal recommendation list from Redis and displays it.

Speed from the research:

• Median response time: 0.9 seconds
• 95th percentile: 1.2 seconds

Because the hard work is done in advance, serving recommendations is just a fast data lookup.

Where these recommendations appear in Commerce:

• Product detail page : "You might also like"
• Cart page : upsell and cross-sell
• Homepage : personalized "For You" section
• Post-purchase emails and abandoned cart emails

Adobe Commerce's layout system lets you add a custom widget that calls your recommendation API instead of the built-in module.

---

How It Compares to What You Probably Have Now

Worth being honest about: the built-in rules are faster because they serve the same list to everyone. The hybrid approach is slightly slower (0.9s vs. under 0.1s) because it's serving a unique list per customer — but 0.9 seconds is well within acceptable page load limits.

---

Where to Start: Three Phases

You don't need to build everything at once.

*Phase 1 : Product Similarity Only *
Start with just the product-matching part. No customer data needed. Replace your "Related Products" widget with similarity-driven suggestions based on product descriptions and attributes. Quick win, low complexity.

*Phase 2 : Add Personalization *
Export 1–2 years of order history. Train the behaviour model. Start showing personalized recommendations to logged-in customers. New customers and guests still see product similarity results as fallback.

*Phase 3 : Full Hybrid + Automation *
Combine both signals with the 60/40 weighted score. Set up automated nightly retraining. Add tracking so you can see which recommendations actually convert. Fine-tune the balance based on your specific store's data.