Adobe Commerce Product Recommendations render on a Hyva storefront through the Hyva Enterprise Sensei compatibility module, installed with the hyva-themes/magento2-hyva-enterprise-product-recommendations package. The recommendation units are powered by Adobe Sensei, fed by the Data Services module that tracks product views and purchases. You create units in the Admin, place a component once per page type, and Sensei fills them based on shopper behavior.
Recommendations are one of the highest-return features on an ecommerce site because they raise average order value without raising acquisition cost. But on a Hyva theme they need the right compatibility layer, and a careless implementation can add the exact JavaScript weight that Hyva was chosen to remove. This guide covers what renders, which recommendation types belong on which pages, and how to keep the units fast.
How recommendations reach a Hyva storefront
Adobe Product Recommendations is a SaaS service, like Live Search. Your storefront sends behavioral events, product views, add-to-carts, and purchases, to Adobe through the Data Services module. Adobe’s Sensei models analyze those events and decide which products to recommend for a given context. The storefront then requests and renders those recommendations.
On a default Luma store, Adobe ships frontend widgets that assume the Luma JavaScript stack. A Hyva theme does not run that stack, so the recommendation units need a Hyva-native rendering layer. That is the Hyva Enterprise Sensei module for Product Recommendations, installed alongside the broader Hyva Enterprise package. The practical requirements match the rest of Hyva Enterprise: Adobe Commerce, a supported Hyva theme version, and the Hyva Enterprise license.
The setup flow is straightforward once the modules are in place. You configure Adobe Product Recommendations and Data Services first, create recommendation units in the Admin UI, then place the Hyva rendering component on each supported page type once. After that, Sensei fills the units automatically.
The recommendation types, and where each belongs
Sensei supports several recommendation logic types. Choosing the right type for each page is what separates a recommendation strategy that lifts revenue from one that just fills space.
| Recommendation type | What it does | Best placement |
|---|---|---|
| More like this | Products visually or categorically similar | Product detail page |
| Frequently bought together | Items commonly purchased in the same order | Product page, cart |
| Customers who viewed this viewed that | Behavioral co-view associations | Product detail page |
| Recently viewed | The shopper’s own recent history | Home, category, product |
| Trending and most viewed | Popular items across the store | Home, category |
| Most purchased | Best sellers by real purchase data | Home, category landing |
| Recommended for you | Personalized to the individual shopper | Home, account |
The pattern experienced merchandisers follow: use similarity and co-view units on product pages to deepen the session, frequently-bought-together in the cart to raise order value, and trending or personalized units on the homepage to guide discovery. Placing a generic best-seller row on every page wastes the personalization the model is capable of.
The behavioral data engine, and why it needs traffic
Sensei recommendations are only as good as the behavioral data feeding them. The Data Services module must be capturing product views and purchases correctly, or the models have nothing to learn from. This is the single most common failure: units render, but they show weak or generic products because the event pipeline was never verified.
Two implications follow. First, always confirm events are firing after install, in staging and again in production, before you judge recommendation quality. Second, low-traffic stores get weaker personalization because the model has a thinner signal, the same constraint that applies to Live Search ranking. A store doing serious volume will see sharper recommendations than a boutique with a few orders a day. Set that expectation with stakeholders early.
Keeping recommendations fast on Hyva
The reason a merchant runs Hyva is speed, and recommendations can undermine it if implemented carelessly. Each recommendation unit makes a request and renders a row of products with images. Done wrong, that means layout shift, extra blocking requests, and heavy images that hurt the Core Web Vitals you migrated to protect.
The disciplines that keep units fast:
- Reserve space to prevent layout shift. Give each recommendation row fixed dimensions so it does not push content when it loads, protecting your Cumulative Layout Shift score.
- Lazy-load below-the-fold units. A recommendations row at the bottom of a product page should not load until the shopper scrolls near it.
- Size the product images. Use correctly sized, compressed images with width and height set, the same rule that governs every image on a fast Hyva theme.
- Limit units per page. Two well-placed units beat five competing for attention and bandwidth. More rows rarely means more revenue.
This is where the broader Magento development discipline matters: the feature is only worth adding if it stays within the performance budget that makes Hyva valuable in the first place.
Measuring whether recommendations earn their place
Do not judge recommendations on whether they look good. Judge them on revenue attribution. Track the click-through rate on each unit, the revenue attributed to recommendation-influenced orders, and the effect on average order value. Adobe’s reporting shows unit-level performance, and you should prune units that do not convert.
A healthy recommendation program shows a measurable lift in average order value from cart and product-page units, and steady click-through on personalized homepage rows. If a unit gets impressions but no clicks after a few weeks on a store with real traffic, change the recommendation type or move it, rather than leaving dead space on the page.
Consent, tracking, and the data pipeline
Because recommendations run on behavioral tracking, they intersect with privacy compliance. The Data Services module sends product-view and purchase events, and in regulated markets that data collection has to respect the shopper’s consent choices. If your store honors a consent banner, confirm that recommendation event tracking is gated behind consent the same way your analytics are, so a shopper who declines tracking is not silently profiled.
In practice this means wiring the Data Services events into your consent-management setup and testing that events stop firing when a shopper opts out. It is easy to overlook because the recommendations still render from aggregate models, but the individual tracking must respect the choice. Getting this right protects both compliance and shopper trust, and it is far cheaper to build in than to retrofit after a complaint.
Sensei recommendations versus manual related products
Magento has always let merchants set related products, up-sells, and cross-sells by hand in the product admin. Sensei recommendations do not make that feature useless, but they change when you reach for it.
Manual related products make sense for editorial or merchandising intent: a deliberate bundle, a brand story, a launch you want to steer. They do not adapt, and they take staff time on every product. Sensei units adapt automatically and scale across a large catalog with no per-product effort, but they follow behavioral patterns rather than merchandising intent.
The strongest stores use both. Sensei drives the high-volume, behavior-led rows on product and category pages, while a small number of hand-curated placements carry the merchandising message on hero products and campaign pages. Trying to hand-curate a ten-thousand-SKU catalog is the mistake; so is assuming the AI knows your launch strategy.
A/B testing recommendation placements
Because recommendations touch revenue directly, they are worth testing rather than guessing. Run a structured comparison before committing a layout across the store: test one recommendation type against another in the same slot, or test a placement on versus off, and measure the effect on average order value and revenue per session, not just click-through.
Give each test enough traffic and time to reach a real result, which on a mid-market store usually means a couple of weeks minimum. Keep the winners, remove the losers, and re-test when your catalog or audience changes materially. Recommendations are not a set-and-forget feature; the stores that get the most from them treat unit placement as an ongoing optimisation, the same way they treat checkout or search.
Common mistakes to avoid
Three errors recur on Product Recommendations builds.
The first is skipping event verification. Teams install the modules, see units render, and assume it works, without confirming the Data Services events actually reach Adobe. Weeks later they wonder why recommendations feel random. Verify the pipeline first.
The second is over-placing units. A page with five recommendation rows dilutes attention and slows load. Pick the two or three placements that map to a real shopper decision and stop there.
The third is ignoring the Hyva compatibility version after a theme upgrade. Because rendering depends on the Hyva Enterprise Sensei module, upgrading the theme ahead of the compatibility module can break the units. Check compatibility before any theme upgrade and test on staging.
Frequently asked questions
Do Adobe Product Recommendations work on a Hyva theme?
Yes, through the Hyva Enterprise Sensei Product Recommendations module, installed with the hyva-themes/magento2-hyva-enterprise-product-recommendations package. It renders Sensei-powered units in the Hyva frontend. You need Adobe Commerce, a supported Hyva theme version, and a Hyva Enterprise license.
What powers the recommendations?
Adobe Sensei machine-learning models, fed by behavioral events, product views, add-to-carts, and purchases, that the Data Services module sends to Adobe. The quality of recommendations depends on that event data being captured correctly and on having enough traffic to learn from.
Which recommendation type should I use on the cart page?
Frequently bought together is the strongest cart-page unit because it targets add-on purchases at the moment of checkout, raising average order value. Reserve similarity and co-view units for product detail pages where they deepen the browsing session.
Will recommendations slow down my Hyva store?
They can if implemented carelessly. Reserve space to prevent layout shift, lazy-load below-the-fold units, size images correctly, and limit the number of units per page. Done with discipline, recommendations stay within the performance budget Hyva provides.
How many recommendation units should a page have?
Usually two or three, each mapped to a real shopper decision. More units dilute attention and add load without a matching revenue gain. Prune units that get impressions but no clicks.
Where this fits
Product Recommendations on Hyva is a high-return feature when three things are true: the Data Services event pipeline is verified, the recommendation types are matched to the right pages, and the units respect the performance budget. Get those right and recommendations lift average order value without undoing the speed you built.
Bemeir is the first US-based Hyva partner and a full Adobe Commerce agency, with a broad technology partner ecosystem across personalization, search, and analytics. We implement Product Recommendations and Live Search on Hyva, and we build on Shopify, Shopware, and BigCommerce when those platforms fit better. Read more about Bemeir and how we ship enterprise features without sacrificing speed.
External references: the Hyva Enterprise Product Recommendations documentation, the Hyva Enterprise getting-started guide, and Adobe’s Product Recommendations integration overview.
