You can access the Product Recommendations dashboard through the top navigation.
You are able to:
- create a recommendation instance that can be used in the Ometria automation campaigns
- select one of 7 recommendation engines
- select the fallback model
- restrict to category / attribute
- restrict to a specific price range
- add products to a “blacklist”
- remove products that have been previously purchased by the recipient
- preview the recommendation engine based on recipient email or products left viewed / left in basket / purchased
Product Data Requirement
In order for any product recommendation engines to recommend products accurately, each product your ecommerce platform passes us should contain the following fields with valid values. Meaning there should be no null values for any of these data listings.
- attribute: (attributes to include)
- attribute_blacklisting: (attributes to exclude)
- attribute_type: (meaning unclear)
- blacklist_products: (product IDs to exclude)
- bought_products: (product IDs that were bought)
- context_products: (product IDs from triggering event, sometimes used depending on engine)
- price: (must have price)
- store: (product must be associated with a given store, usually store from triggering event)
Also, if a product is not in stock and you do not want it to be recommended, then the global "is_active" field should be false as well as the store level "is_active" field. If either is set as 'true', the product could be recommended wrongly whille not being in stock
The criteria for a product to be available to be shown in product recs are listed in this section.
- We only recommend parent products, not variants.
It has to have been sold in the last 28 days - we don't recommend products without any sales - these are unlikely to convert. EXCEPTIONS:
1. recently added products where this restriction DOES NOT apply, it only looks for newest products
2. Personalised products, where if no sales are found for that set of attributes it falls back to MOST RECENT products.
Some notable fields
- is_active = TRUE (parent product level - not listing)
- Price has to be defined and >0 (parent product level - not listing)
- Title has to be defined and not empty (parent product level - not listing)
- URL has to be defined and not empty (parent product level - not listing)
- the "is in stock" flag needs to be NOT FALSE (e.g. true or not defined) (parent product level - not listing)
Once the recommendations are trained based on the above, the generated recommendations follow rules below:
- If no store parameter is passed in, we just use product details based on the top level product record (e.g. title, url, is_active, price, currency, image etc)
- If a store ID parameter is passed in (see below), then this is resolved to a "product listing". And IF that listing is found, the title, url, is_active, price, currency, image etc are merged in from the listing into the record before being displayed. If, after the merge, is_active is FALSE (e.g. it was FALSE on the listing) then the product is removed from the returned products and not displayed.
As a reminder, we have "products" and "product_listings". Product listings are overridden product fields for individual stores. E.g. a product may be £45 in the GB store and EUR 59 in the fr store. It may also have a different URL, image and title etc. This allows us to generate localised product info.
These are not to be confused with parent products and variants. Variants are for shippable SKUs. E.g. a shoe available in 8 sizes would have 1 parent product and 8 variants.
Product listings only really apply to parent products. E.g. the shoe above may have its title and image localised in a bunch of different stores.
There are a couple of odd edge cases that can occur:
- A client sets is_active=FALSE on the top level product but sets is_active=TRUE on the store listing. In this case, the product will NOT appear as it will not be trained into the mode.
- Contrary to, perhaps how you might expect this to work, if you pass in a store ID where no product listing, it just uses the default product details, but the product will still be shown. This is really because some integrations send listings and some don't.
What does 'store ID passed in' mean, depends on context:
- For product recs previews, it depends on the new 'store' selector in the UI.
- For Automation emails corresponding to an event that occurred in a store (e.g. order, abandoned basket) the store is the store that raised the event
- For all other sends its the 'default store' of the contact if set (first signup store)
- If that's not set it falls back to default settings (Top level product details).
No-context recommendation engines
These recommendation engines can be used without any context - i.e. they can be generated for any customer without needing to know what products they have interacted with.
This will recommend the best selling products (in terms of units sold). You can choose to recommend best selling products in the last 7 days, 14 days or 28 days.
This aims to recommend the most recent products that have been launched on the website. In practice, this recommends the most recent products that we have observed (which may be different to those most recently launched depending on how the retailer adds products to their database)
Product-based recommendation engines
These recommendations engines can be used in a context where a set of products exists and provides recommendations based on those products. For example, it can be used to recommend products based on the products in an abandoned basket or products placed in an order.
This will recommend products most similar to the context products. Similarity is determined based on the number of common attributes between the products.
Bought this, bought that (a.k.a Product up-sell)
This will recommend the most common products that were bought by other customers that purchased any of the context products.
Viewed this, bought that (a.k.a Product cross-sell)
This will recommend the most common products that were bought by other customers in the same session that they viewed any of the context products.
Profile-based recommendation engines
These recommendation engines can be used in the context where the customer is known and will generate recommendations based on the customer's behavioural history (products they've purchased or viewed).
This will recommend products that have been viewed by the customer in the last 7, 14 or 28 days. The recommendations will be shown in order of recency of view.
This will recommend products that have the attributes that the customer has shown most interest in (by either viewing or purchasing a product with those attributes).
The fallback model will be used in the event that the primary model is unable to generate sufficient recommendations. The fallback model should be either "Top products" or "Latest products" as these, in theory, should always produce results.
This can be used to ensure that the recommendations are restricted to a selection of attributes. The restriction is an "any"-type restriction - this means that products recommended will be products which have ANY of the selected attributes (and not necessarily products that have all of the selected attributes).
Restrict to price range
This can be used to ensure that the recommendations are restrict to products whose price is within the specified range.
Any specified blacklisted products will be removed from all recommendations generated.
Products that have any of the specified blacklisted attributes will be removed from all recommendations generated.
Products recommended will be restricted to those that are available in the specified store.
Remove previously purchased products
Products that have been purchased by the customer will be removed from all recommendations generated.
All models are filterable by one or more attribute ids (e.g. category). If multiple are provided it will be an OR query (e.g. is in category X OR category Y). You can also filter by price. You can also blacklist specific products, any recommendations produced by the model (instance) will exclude products in the list.
'Fallback model ' is here in case the number of recommendations found by the primary model is insufficient to populate the template, the fallback model will be used to generate additional recommendations to complete the template.