Different customers can see the same recommended products because the model uses a fallback when it can't fully personalize for a specific customer.
It typically occurs when the profile lacks sufficient learned events for the given recommendation model, or if a temporary issue, such as a timeout or engine unavailability, arises.
The fallback mechanism is applied in such cases to provide some items from the catalog while respecting the catalog filters you set for the recommendation engine.
It is possible to turn this mechanism off by adding the Jinja parameter fill_with_random = false, which is enabled by default.
{% for item in recommendations('RECO_ENGINE_ID', size = 20, fillWithRandom = false) %}
{{ item.title }}
{{ item.price }}
{% endfor %}
In general, it is recommended to validate the results after the model is trained and ready. In the engine's Preview tab, filter customers with events based on the learning sample used for training so that you can test on profiles with sufficient data.
You can validate the behavior in two ways:
-
Test tab in the recommendation model
Use the Test tab and switch between customer profiles to compare outputs. The Test tab always requests 10 items from the engine, and this number can't be changed.
-
Jinja in an email template
Call the recommendation in an email template using Jinja, and control the number of requested items with the size parameter (for example, request 50 items and render only the top 5–10). It gives you more flexibility when testing and debugging.
For more information about recommendations testing using the Test tab, refer to our documentation.