What are Recommendations in Webtrends Optimize?
Recommendations, also referred to as Product Recommendations or Content Recommendations, are our ability to suggest products or content to users.
The primary use case for this is in ECommerce, with product recommendations featuring in a carousel based on a variety of rulesets that we collaborate on.
Prerequisite and preparation
If you are thinking about running Recommendations, the following aspects are worth your consideration. These will help us prepare, and have more data to generate recommendations on.
Product Feed imports - jump to this section
Historical Sales data - jump to this section
Historical behavioural data - views, ATB, purchases, etc. - jump to this section
Product feed imports
What it is a product feed?
A product feed is some sort of file or API that contains your catalogue of products and it's various attributes.
Product feeds are a useful source of data for recommendations for a few purposes:
Knowing what's in stock - we don't want to recommend products which users can't buy in most cases, and product feeds are often a good way to find out which products are in stock across the website.
Looking up "products like x, y, z". For algorithms like Similar Products, or fuzzy matching e.g. Show a good-selling white t-shirt between £15-30, product feeds are an often easy way to narrow down the potential products we should be recommending.
Typically, this is your Google Shopping feed. For users on Shopify, we can use their APIs to pull this information.
Formats we can work with
We are fairly flexible on our side - data will be transformed into our proprietary format regardless of how it's sent to us.
The key thing we ask is that it's either in CSV (ideal) or JSON format, as these are the most lightweight to transform.
How to get the data into WTO
Data can either be imported by Push or Pull mechanisms.
Push - you send data to us.
Pull - we fetch the data from you.
Available push mechanisms:
Blob Storage container / S3 bucket
REST API that you can transfer data through
Available pull mechanisms:
URL-based fetch, e.g. file download / REST API.
Fetching your data via. a S3 bucket
Whichever mechanism you decide on, please let us know and we will provide credentials for you.
Example of Product Feed
brand,description,condition,id,image_link,link,price,product_type,title,color,quantity,availability
Apple,"Iphone 13 Pro, with 256gb storage",new,123456,https://cdn.mysite.com/img/apple-iphone-13pro.png,https://www.mysite.com/products/iphone-13pro-256,999.99,Phones>Apple>Iphone 15 Pro,"Iphone 13 Pro 256GB",black,30000,in stock
Apple,"Iphone 13 Pro, with 256gb storage",new,123456,https://cdn.mysite.com/img/apple-iphone-13pro.png,https://www.mysite.com/products/iphone-13pro-256,999.99,Phones>Apple>Iphone 15 Pro,"Iphone 13 Pro 256GB",purple,30000,in stock
Note that you can send additional fields to us - we will use them if helpful or discard them when transforming/processing that data.
Historical sales data
What should our day-1 recommendations look like? If we are looking towards algorithms like "Customers also bought", historical sales data allow us to have modelled-data early into working together.
Formats we can work with
We are fairly flexible on our side - data will be transformed into our proprietary format regardless of how it's sent to us.
The key thing we ask is that it's either in CSV (ideal), JSON or XML format, as these are the most lightweight to transform.
How to get the data into WTO
Given the size of this data, which is typically in the 100s of megabytes / gigabytes, we prefer this to be a file hosted in somewhere that we can fetch/download.
There are many platforms that will allow this, such as Google Drive or Onedrive.
We expect this to be a 1-time share, with as long a timeframe as you can. 1 year of data is normal, but we are happy to accept shorter or longer ranges where useful/available.
Example of Historical Sales data
The only important fields we typically need from sales history data are:
Visitor ID
Transaction ID
Product ID
The following example assumes products p10000, p10001 and p10002 are bought in the same transaction by a given user.
vid,transaction_id,product_id
v10000,t10000,p10000
v10000,t10000,p10001
v10000,t10000,p10002
Some customers will join all products purchased into a single field, grouped by transaction ID which is fine too. As mentioned, we are flexible on the format, and will be transforming it regardless of what's sent to us.
Historical behavioural data
As with sales data, this addresses day-1 recommendatoins. Specifically, for algorithms like "People who viewed this also viewed".
Formats we can work with
Same as Historical sales data. See above.
How to get the data into WTO
Same as Historical sales data. See above.
Example of Historical behavioural data
The only important fields we typically need are:
Timestamp/Date - Useful for sequencing "did x THEN y"
Visitor ID - Useful for "people who did"
Event
Product ID
The following shows a story of a user viewing product 10000, then 10001, then going back to 10000 to view, add and purchase it.
timestamp,vid,event,product_id
1703071136000,v10000,view,p10000
1703071152000,v10000,view,p10001
1703071165000,v10000,view,p10000
1703071170000,v10000,atb,p10000
1703072000000,v10000,purchase,p10000
As with everything, we are very flexible on format. As long as the required fields are present, we will transform it to meet our requirements.