Configuring Magento's Native Product Recommendations Module

1. Scope: an Adobe Commerce feature, not an open source capability

The Product Recommendations module is part of Adobe Commerce and is not available in Magento Open Source, a distinction that project planning frequently overlooks. It is built on Adobe Sensei, Adobe's machine learning service, which runs outside the store's own infrastructure and communicates with the shop through an Adobe I/O connection.

That makes this feature fundamentally different from a custom built AI recommendation engine, covered in another article in this series, where training data, model and infrastructure stay entirely under a project's own control. Here, Adobe handles both training and serving the model, while the store only supplies catalog and behavioral data and fetches the finished recommendations.

For projects without an Adobe Commerce license, this module is simply irrelevant, but for projects that already hold a license, it is often the fastest way to ship recommendations without any custom model training effort.

2. Architecture and data flow at a glance

Data flows in two directions. A cron job regularly exports a catalog feed with product and category data to Adobe, while a tracking script embedded in the storefront sends events such as product views, cart additions and purchases to Adobe Sensei, so the model learns from actual user behavior.

The actual recommendations get served client side: a Page Builder widget or a layout block calls the Adobe Sensei API at runtime and renders the returned product IDs as a recommendation tile. The Magento server itself never computes any recommendations, it only supplies the raw training data and later embeds the result.

This architecture carries a direct performance advantage over a server side computed recommendation, since the additional API call happens asynchronously in the browser and does not block the actual page build, as long as the widget is embedded correctly.

3. Catalog feed export and cron configuration

The catalog feed gets generated through a dedicated cron job and carries basic data for every product, such as SKU, name, category assignment, price and image URL. The export runs per store, since assortment, pricing and language can differ per store and Adobe Sensei trains a separate model per store.

In practice, it is worth adjusting the cron schedule to the catalog's actual rate of change. A store with several price or assortment changes per day benefits from a more frequent export, while a stable B2B catalog with rare changes is served well enough by a daily export.

<!-- app/etc/crontab.xml (excerpt, default cron group for the feed export) -->
<job name="recommendations_update_feed" instance="Magento\ProductRecommendations\Cron\UpdateFeed" method="execute">
    <schedule>0 */6 * * *</schedule>
</job>

4. Configuring recommendation types in the admin

In the admin under Content, Elements, Product Recommendations, several types can be created, including related products, recently viewed products, best sellers, newly added products and several other Adobe Sensei computed variants such as frequently bought together. Each type can be activated independently and assigned to a specific page position, such as the product detail page or the cart page.

For every recommendation type, the number of displayed products and an optional title text, translatable per store view, can be configured. It matters not to activate too many types on the same page at once, since each recommendation widget triggers its own API call and those calls add up.

query ProductRecommendations($pageType: String!, $sku: String) {
  productRecommendations(pageType: $pageType, sku: $sku) {
    unit_id
    unit_name
    products {
      sku
      name
      image {
        url
      }
    }
  }
}

5. How this differs from a custom built AI recommendation engine

The key difference from a custom built AI solution lies in model control. Adobe Sensei is a black box, neither the training procedure nor the exact weighting of individual signals such as purchase frequency or category membership can be inspected or adjusted, only type, position and displayed count are configurable.

A custom built solution, for example based on a dedicated recommendation service with full control over features and training data, pays off mainly when specific business rules need to feed into the recommendation that Adobe Sensei cannot express, such as stock level prioritization or margin steering. For the standard case of related products or best sellers, the native module delivers comparable results without any development effort.

In practice, the two approaches are not mutually exclusive: some projects use the native module for generic recommendation types and add custom logic only for individual, business critical placements.

6. Data privacy implications of the tracking script

Since the tracking script transmits user behavior to an Adobe service outside the store's own infrastructure, this constitutes processing by a third party under GDPR, requiring user consent whenever personal or identifiable data such as IP address or a unique user ID gets transmitted.

In practice, that means the tracking script must be tied to the existing cookie consent management and must only load after consent has been given, not already on the first page view. A purely server side, anonymized evaluation without individual tracking is not supported by this module, since Adobe Sensei relies on individual behavior for model training.

In addition, a data processing agreement with Adobe should be in place, and the store's privacy policy should explicitly disclose the transfer to Adobe servers, including the processing location, since Adobe I/O services can partly process data outside the EU.

7. Performance and caching of the recommendation widgets

Since recommendations load client side through an API call, they run independently of the full page cache and can be placed on statically cached pages without any cache invalidation problems, a clear advantage over server side computed, personalized content such as dynamic blocks.

That additional API call should still happen asynchronously and as late as possible in the loading process, ideally only after the visible part of the page has rendered, so time to interactive does not suffer. A recommendation widget embedded too early and blocking, despite the asynchronous architecture, can still noticeably worsen perceived load time if it ends up placed synchronously in the critical rendering path.

8. Monitoring click through rate and separating it from internal analytics

Adobe Sensei only surfaces aggregated metrics about recommendation effectiveness in its own reporting, so for a fine grained evaluation inside a project's own analytics setup, every click on a recommended product should get tracked as a separate event, distinct from the Adobe internal interaction events that get sent to Sensei for model training.

A sensible approach is a data layer event per click that carries the recommendation unit ID, the clicked product SKU and the position within the recommendation list. That makes it possible to evaluate, in a project's own analytics tool, which recommendation types actually drive clicks and purchases, independent of whatever Adobe internally treats as success, and without any extra cost for a separate Adobe reporting package.

In practice, the recommendation types best sellers and frequently bought together often show noticeably different click through rates depending on placement, which makes simple A/B testing of positioning worthwhile before a type gets permanently anchored in a prominent spot such as directly below the buy button.

9. Pitfalls from real projects

A common mistake is a feed export that runs too infrequently on stores with frequent price changes, causing recommendations to display outdated prices until the next export completes. The feed export schedule should therefore be deliberately matched to the catalog's rate of change instead of being left on the default value without thought.

A second pitfall concerns new products without any interaction history, the so called cold start problem. Adobe Sensei needs a certain amount of tracking data before product specific recommendation types such as frequently bought together produce meaningful results, so new products often only appear in more generic types like newly added during their first few weeks.

10. Summary

11. FAQ: Recommendations module