Skip to main content
All CollectionsOther FeaturesProduct Recommendations
Available algorithms for Recommendations
Available algorithms for Recommendations
James Harber avatar
Written by James Harber
Updated over 4 months ago

Below is a list of available algorithms for Recommendations, or more broadly for Product Carousels.

Jump to:

Based on locally stored browsing history (tagged data):

Based on Product Feed (content based filtering):
You may also like (similar products) | New arrivals

Based on collected user behaviour (collaborative filtering):

Key considerations for setup and data collection

We typically see three key interaction points where data needs to be collected or recognised.

Tagging users with their behaviour

Collaborative Filtering - aggregating data across users - is not always required. Some recommendations can be powered purely by analysing a user's own data, such as "Recently Viewed".

In this scenario, we tag users with their own behaviour, typically in localstorage, and make this available for retrieval.

Product feed

For anything that requires access to product metadata, particularly anything that could change e.g. Price, we recommend getting access to a product feed that we can update on a regular basis, e.g. Every 4 hours. We are not restricted by the format of the feed but recommend CSV as the smallest format.

Often, we find Google Shopping feeds give us a fair amount of data to power what we need.

With this data, we can build product cards, deliver prices, have imagery etc., as well as powering Content-based Filtering approaches such as Similar Products.

For more information, see: Product Feeds.

Aggregated onsite behaviour

For collaborative-filtering algorithms - anything that joins up behaviour across multiple users and studies popularity - we can collect user behaviour through the WTO tag.

This is typically put into a dedicated baseline, as data is required in a specific format.

Once collected, we will routinely generate recommendation "batches", and cache these to make them available in an accelerated timeframe. The caching techniques allow us to often reach sub-second content delivery.

Algorithms powered by locally stored browsing history

These algorithms require minimal setup. They are based on data we keep in localstorage, which is easy to set up.

Note: To build product cards and only show in-stock products, we recommend ingesting your Product Feed regularly.

Recently Viewed

This is a fairly straightforward resurfacing of past-viewed products. These could be in the format of a single "last viewed" product that's populated into a specific block on the page, or perhaps a carousel of "recently viewed products" with the last 5-10.

Example:

Recently Viewed recommendations carousel for Webtrends Optimize

Data required to set up

  • Required:

    • The WTO tag, capturing Product ID and required metadata e.g. image, URL.

  • Optional:

    • Product feed or AJAX calls, to build the product cards.


Buy it Again

This algorithm is useful for products which can have repeated purchases. Whether on a regular basis, or timeboxed - e.g. At least 3 weeks after last purchase, we can recommend the same product back to users.

This is typically filtered down to specific products lines. E.g. "don't recommend another bicycle, but do recommend some cleaning spray".

Example

Data required to set up

  • Required:

    • The WTO tag, tagging a user with which Product IDs they've purchased and any other relevant attributes e.g. Category.

    • Test Config, detailing which product types should appear in Buy It Again, e.g. Car Cleaning. Typically entered into the experiment code.

  • Optional:

    • Product card info, either collected into localstorage or made available via. Product Feeds.


Algorithms powered by product feeds

You may also like (similar products)

Similar product lists are an excellent way to help users navigate around the website better. The presumption is that if users pre-purchase and show interest in a type of product, showing similar products will help them find something that they want to buy.

Example

Data required to set up

  • Required:

    • Product feed, with any attributes you wish to include in the similar-products comparison. E.g. Category, brand, price, etc.

    • Config, ranking or weighting attributes in order of importance.

  • Optional:

    • The WTO tag or order history export, collecting behavioural data can help rank products in a "most popular" order, improving the quality of what comes back.


New arrivals

New products in this [category/brand/overall] are a useful recommendation type for keeping fresh content in front of users.

Used quite often on content websites in particular, we can present X newest articles to users. When joined up with personalisation and the maintaining of your users' browsing history, we can present new and relevant content to them. E.g. Our newest dresses / Latest tech news.

Data required to set up

  • Required:

    • Product feed, with created date available

  • Optional:

    • Product feed and WTO tag, both having access to additional attributes you wish to filter on.


Algorithms powered by collecting user behaviour

These algorithms require more configuration. Typically in a dedicated baseline, we'll capture Views, Purchases and other useful events, and aggregate these on a scheduled basis.​

Bought With

This algorithm looks to pair products which were purchased in the same transaction. This is quite useful for targeting add-ons, and topping up baskets. Often, users will configure these to encourage users to reach free delivery thresholds.

Example

Data required to set up

  • Required:

    • Sales History, either as an ad-hoc export or collected on a rolling basis via the WTO tag.

  • Optional:

    • Product feed, if additional filtering or fuzzy match would be helpful. E.g. category often bought with this product instead of a 1:1 product pairing.


Viewed also viewed

Best used before Add to Bag, where the goal is to help guide users through a browsing experience, "Viewed also viewed" takes a collaborative approach to carousels, aggregating what other people have done in a given session/timeline.

These recommendations are typically hidden behind "People also viewed", "You may also like" or similar.

Data required to set up:

  • Required:

    • PDP views, captured in a dedicated baseline.

  • Optional:

    • Product feed, to build product cards

    • Additional user or product-level metadata, to apply layers of filtering. E.g. "Show also viewed products, within a +/- 20% price range".


Purchased also purchased

This is very similar to Viewed also viewed, except that we analyse and aggregate based on a different event - purchase.

Data required to set up:

  • Required:

    • Purchases, along with the required metadata e.g. Product ID, captured in a dedicated baseline.

  • Optional:

    • Product feed, to build product cards

    • Additional user or product-level metadata, to apply layers of filtering. E.g. "Show also purchased products, within a +/- 20% price range".


Most popular

Most popular products can take many shapes and forms. For example:

  • Top Selling by Purchases

  • Top Selling by Revenue

  • Top Selling by Profit

  • Most viewed

  • Blended popularity

Joined up with a filter, e.g. "in this category", you can retrieve popular products that should be in front of your users.

This is great when joined up with personalisation, e.g. "keep track of category affinity. When the user returns to a homepage, show them a popular products carousel based on their favourite category".

Data required to set up

  • Required:

    • Any event and attribute you want to aggregate by. E.g. "Most viewed in this category" requires the capture of PDP Views with Product IDs and Category or a Product Feed to lookup the category.

  • Optional:

    • Product feed, to build product cards

    • Additional user or product-level metadata, to apply layers of filtering. E.g. "Show also purchased products, within a +/- 20% price range".

What's Trending

Quite simply, this is no different to any popularity-driven experience, except that the analysed data applies itself to a shorter timeframe. E.g. Past week, instead of past year.

What can I do / what do I need WTO for?

At the minute, all tagging, collecting, aggregating and querying of data is handled by the WTO support team. This accompanies an exploratory call where we understand your requirements better - it is often not difficult to have variations of the algorithms above, and an exploratory call will help us uncover these requirements.

We do not currently charge for this service (as of Jan 2024), but in the interest of expediency will be documenting the process for you to be able to do this yourself in the near future.

Did this answer your question?