.svg){kind=logo}
In many Magento 2 projects, the topic of product recommendations starts with a simple assumption: you need to show the customer a few extra products on the product page, in the cart, or during checkout. The problem appears very quickly. Magento's standard related, upsell, and cross-sell mechanisms are useful, but in practice they often turn out to be too rigid for real implementation needs.
After all, a store does not want to display the same products in every place and in every case. One scenario is needed for a simple product, another for a configurable one, another for a seasonal campaign, and yet another for a cart containing several different products. From the perspective of agencies and implementation teams, this usually means one thing: exceptions start to pile up, custom conditions appear, and more layers of code are added that become harder and harder to maintain.
Kowal_RelatedProductsProfiles was designed precisely to solve this problem in a different way. Instead of building the logic around individual, manually linked product relations, the module introduces the concept of a recommendation profile. The profile defines where it should work, under what conditions it should run, how products should be selected, and how they should be rendered. As a result, recommendations become a configurable layer rather than another collection of one-off exceptions hardcoded into the project.
The module is available here: Automatic related products for Magento 2.
Why standard Magento lists are often not enough
Native related, upsell, and cross-sell lists work well in simple stores or in setups where merchandising is maintained manually by the e-commerce team. In real implementation work, however, scenarios very quickly appear that the standard model does not cover:
- showing recommendations only for a selected customer group,
- running a specific list only within a defined date range,
- linking products based on catalog attributes rather than manual relations,
- different behavior on the PDP, different in the cart, and different in checkout,
- placing a list in a specific part of the theme layout without rewriting the whole view,
- partially or fully replacing Magento's native lists with project-specific logic.
For agencies, this usually means two problems. First, the standard mechanism has to be wrapped with additional conditions. Second, every new business requirement starts generating a separate exception. At some point, instead of one coherent recommendation mechanism, you end up with a set of unrelated workarounds.
Profiles as a merchandising logic layer
The most important idea behind the module is moving away from thinking in terms of a single product list and replacing that model with a recommendation profile.
The profile is a separate configuration entity. It defines:
- where it should work,
- for which store and customer group it is active,
- which product should be used as context,
- when the profile should run,
- how to select candidates,
- how to narrow the result,
- how to sort products,
- how to display them,
- and whether they should also feed Magento's native lists.
From an implementation perspective, this is a major qualitative shift. Instead of preparing separate custom code for every placement, you can build a set of profiles corresponding to different business scenarios. This model is easier to maintain, simpler to extend, and much more readable for teams that will work on the project after go-live.
Where the module provides real implementation value
The most obvious place to use it is the product page. That is where we most often want to show products from the same collection, with a similar style, or from the same communication line. In practice, however, the PDP is rarely the only place where recommendations make sense.
The cart opens a completely different scenario. This is no longer the inspiration stage, but a moment when you can work on increasing basket value. Profiles suggesting accessories, add-ons, cheaper complements, or products from a different assortment base but still related to what the customer has already chosen work well here.
Checkout is another stage that requires caution. Not every store wants to expand merchandising there, but for some implementations it can be a good place for a short, simple product list supporting AOV, provided that both the logic and rendering are tightly controlled.
That is not where the module's capabilities end. A profile can also feed Magento's native blocks:
Related Products,Upsell Products,Crosssell Products.
Importantly, the integration is not limited to simply replacing the list. For each of these mechanisms, you can decide whether the profile results should be added to the native products (append) or fully replace them (replace). For agencies, this is very practical because it allows logic to be introduced in stages without having to rewrite the entire shopping experience immediately.
How the module logic works
Although the profile form is fairly extensive, the operating model itself can be described quite clearly. Each time, the module goes through several consecutive stages.
First, the placement is determined, meaning the place where the profile runs. One logic will work on the product page, and another in the cart. Then the contextual product is selected. On the PDP this is usually the current product, while in the cart and checkout you must decide which product from the quote becomes the point of reference.
Once the module already knows the context, it checks the activation conditions. This is the first filter, answering the question: should this profile run at all in the current situation?
If the conditions pass, the module moves to matching rules. That is where the actual matching happens. Attributes of the contextual product are mapped to attributes of candidate products in order to find products from the same collection, series, artwork, category, or any other business-relevant characteristic.
After matching, the result can still be narrowed using static target filters. This is a convenient place to limit the list to specific product types, visibility settings, statuses, or even selected product bases.
At the end, products are sorted, trimmed to the limit, and rendered either in a separate layout position or inside Magento's native blocks.
In practice, this means the module is not based on one product-to-product relation, but on a sequence of decisions that can be controlled from the admin panel.
Creating a new profile: what working with the form looks like
The module's biggest strength becomes visible only when you look at the profile form not as a list of fields, but as a tool for modelling a merchandising scenario.
The process begins with the general section. Name is the administrative label that helps the team find the profile in the panel. Code is the technical identifier. This is the value worth using in logs, project communication, and implementation documentation. Enabled lets you quickly disable a profile without deleting its configuration, and Sort Order decides the order in which profiles are evaluated within the same placement.
The second section is the scope of operation. This is where placements, store views, and customer groups are selected. From an implementation perspective, this is very important because it allows you to keep one mechanism while still differentiating behavior across stores, languages, or customer segments.
The Context Strategy field is particularly important. On the product page, the matter is simple because the module works on the current product. In the cart and checkout, however, you need to define which quote item becomes the context. In practice, this can be the first product, the most recently added product, or the highest-priced product. This seemingly small field has a huge impact on the final result, especially in carts containing several different items.
The From Date and To Date fields make it possible to limit a profile to a defined time window. Thanks to that, the same module can also handle seasonal campaigns and short-term sales actions without adding separate switches.
Activation Conditions, Matching Rules, and Target Product Filters
These three sections are responsible for the module's business logic.
Activation Conditions should be treated as the entry layer. This is where we define when a profile should activate at all. For example, if a profile should only work for products from a certain base, brand, or catalog visibility, those conditions belong here.
Matching Rules are the heart of the entire mechanism. They transfer features of the contextual product to the target products. In practice, that means you can tell the module: find products that have the same artwork, the same collection, the same category, or any other attribute that makes business sense.
Two fields are especially important here: Required and Empty Value Policy.
Required decides whether a given rule is mandatory. If enabled, lack of a match rejects the candidate. If disabled, the rule works more as a narrowing layer, but a mismatch does not block the whole result. In practice, this is very important in projects where context on the PDP and in the cart may look different, for example for a configurable parent on the product page and a simple child in the quote.
Empty Value Policy tells the module what to do when the contextual product does not have a value in the source attribute. The rule can be skipped, treated as failed, or supplied with a default value. This field often determines whether a profile will remain stable in a complex catalog with different product types.
Target Product Filters are the final narrowing layer. They no longer work on the context-to-candidate relation, but directly on the target products. This is a good place to enforce status, visibility, product type, or limit the result to selected assortment families.
Sorting and presentation
From an implementation standpoint, it matters not only which products are found, but also in what order and in what form they are shown.
The module lets you define both a primary and a secondary sorting attribute. This makes it possible to build more predictable lists instead of relying only on the default collection behavior.
On the presentation side, different rendering variants are available, including grid, slider, and compact. This lets you adapt a list to the available page area without creating separate profile types just to change the markup or visual layout.
It is also important that the profile can independently control elements such as:
- price,
- regular price,
- add to cart button,
- product name,
- short description,
- image role.
In practice, this means the same recommendation engine can be used both for richer PDP sections and for more modest lists in the cart or checkout.
Feeding Magento's native lists
One of the more interesting features of the module is the ability to feed Magento's native blocks. This is especially important for agencies that do not want to rebuild the existing frontend immediately, or that work on projects where part of the store still relies on classic related, upsell, and crosssell lists.
In this scenario, the profile does not have to be rendered as a separate block. It can be connected to the native list and work in one of two modes.
The append mode keeps the native products and adds the profile results to them. This is a good solution where the e-commerce team still wants to maintain some manually defined relations while also needing an extra automation layer.
The replace mode goes further and fully replaces the native list with the profile results. This option is particularly interesting for stores that no longer want to manage relations manually and expect profile logic to become the main recommendation mechanism.
This architecture offers a lot of implementation flexibility. You can introduce the module gradually, first extending native lists and only later taking full control over them.
XML as a layer of flexible embedding
From an implementation perspective, it is very important that the module does not stop at product selection logic. Control over where products are rendered is just as important.
That is exactly why the profile includes XML fields assigned to individual placements. They make it possible to embed the profile result in a specific container or under a specific layout block, without building a separate module just to place the list in the desired spot.
In practice, this matters a lot when working with custom themes. Every frontend has its own layout structure. Some themes move the product description to another parent, others build their own wrappers, and others almost completely rebuild Magento's native product blocks. The ability to control placement via XML provides a major advantage here.
This is the layer that makes the module not only a recommendation engine, but also an integration tool. For agencies, this means real time savings because the embedding method can be adapted to a specific project without disturbing the core logic.
Example implementation scenarios
The simplest scenario is the classic recommendation of "same collection, different base". A profile can activate for a product from a given base and, based on matching rules, find products with the same artwork but already belonging to another assortment family. This allows the store to promote sets or expand the purchase with additional product types without building manual relations.
The second scenario is accessories or add-ons in the cart. In this case, the context can be the first or the most expensive product from the quote, and target filters narrow the final result to products that make sense as an extension of the purchase. This is especially useful where Magento's standard cross-sell does not provide enough control.
The third scenario is seasonal campaigns. A profile can run only within a selected date range, only for specific store views, and only for selected customer groups. From the implementation team's perspective, this means the campaign can be built within the same mechanism, without creating a separate promotional module.
The fourth scenario is a partial or full replacement of native upsells. This is especially interesting for stores with large assortments, many catalog characteristics, and no desire to maintain manual product relations.
Why this approach scales well in project maintenance
For agencies, the most important question is not only "does it work", but also "will it still be maintainable in six months"?
That is exactly where the profile-based approach has its biggest advantage. The logic is not scattered across separate observers, plugins, and dedicated classes for individual cases. Instead, you have one configuration model and one recommendation engine that can be developed in layers.
This setup brings several benefits:
- it is easier to hand the project over for maintenance,
- it is easier to add new scenarios without rewriting existing ones,
- it is easier to diagnose profile behavior because the logic is concentrated in one place,
- it is easier to work with custom frontends thanks to the XML layer,
- it is easier to separate business decisions from implementation details.
In practice, this means the module gives an agency not only new options at implementation time, but also a sensible base for further project development.
Summary
Kowal_RelatedProductsProfiles is not just a mechanism for displaying yet another product list on a page. It is a tool for designing recommendation scenarios in Magento 2.
For implementation teams and agencies, three things matter most. First, the module allows recommendation logic to be built around profiles rather than one-off exceptions. Second, it gives control over placement, context, product selection, and rendering. Third, it fits real project conditions, where business expectations, theme constraints, and the need for future store growth all have to be balanced.
If a project requires more than simple manually linked product relations, this model offers much more freedom than Magento's standard mechanisms. And that is precisely where its greatest value lies.
