Try Something New

Solution Background and Business Value

Personalized try-something-new recommendations introduce customers to products they haven't purchased but might find appealing, based on their buying habits and preferences. This strategy not only diversifies the customer experience but also drives business growth by expanding sales into new product categories. When embedded in push notifications, in-product placements, and email campaigns, these recommendations offer a dynamic way to engage customers, sparking curiosity and encouraging exploration. This proactive approach helps businesses to capitalize on cross-selling opportunities, enhances customer satisfaction by keeping the shopping experience fresh, and increases overall customer engagement, making it an invaluable asset for maintaining a competitive edge.

Data Requirements and Kumo Graph

We can start developing our try-something-new model with a small set of core tables, but Kumo allows you to take the model much further by including additional sources of signal.

Core Tables

There are three core tables which we need:

• Users table: holds information about all users that we want to make recommendations for. It should include a user_id so it can be connected to each individual transaction/order event. The table can also include other user features, such as age, location, etc. we can also include user JOIN TIMESTAMP which is taken into account when training the model.
• Items table: contains information about the items available for recommending. It should include an item_id so it can be linked to individual transactions. Kumo also supports START TIMESTAMP and END TIMESATAMP columns, including such columns into the data allows Kumo models to take into account that some items were only available for a limited time, it also prevents the model from recommending items which are no longer available! The items table can also include other information about the items, such as price, color, category, etc.
• Transactions/Orders table: This table records all purchase events from which the model learns to model user-item affinity. It should include the TIMESTAMP of the event as well as user_id and item_id. The table can also include other properties of the transaction, e.g. total amount, payment method, …

Additional Table Suggestions

Alongside above tables we can optionally include many more sources of signal, such as:

• (optional) Merchants table: Information about merchants in the marketplace.
• (optional) Search query events: What did users search for in the marketplace
• (optional) Item rating events: How did users rate items, e.g. numerical rating
• (optional) Item return events: Items returned by the users
• (optional) Comment/review events: Review data, which can include text
• (optional) Wishlist events: Recording additions of items to wish lists
• And many more possibilities!

Predictive Query

Try-something-new recommendations pose a specific challenge; in theory we can train a model only on new-purchase signals, but this would throw away many other important signals. We want our model to grasp both item to item similarity, as well as user behavior and how it relates to new item purchase tendencies. Only using the full spectrum of the data/labels (purchases) will our model be able to distinguish between new-buy decisions and repeat purchase behavior.

The solution is to train a general item-to-user recommendation model on all purchases and filter out old items at prediction time. This way the model learns a more general notion of user-item affinity while the user is still served only new recommendations. We can create a recommendation model in Kumo with a very simple predictive query, which predicts the distinct list of item_id’s each user is likely to buy in a X day time horizon.

PREDICT LIST_DISTINCT(transactions.item_id, 0, X, days) RANK TOP 50
FOR EACH users.user_id

Deployment

We have trained a general recommendation model its output at prediction time is a list of items for each user. To obtain try-something-new recommendations we can filter the model. Try-something-new recommendations are especially powerful for users who are not overly active, so we can create the predictions only for active users who have had less than N purchases in the previous D days:

ENTITY FILTER: COUNT(transactions.*, -D, 0, days) < N

Filtering out old items from the recommendations

The filtering operation can be performed as part of the batch prediction flow in Kumo. We can specify batch prediction transformations (link to documentation), which filter the output of the prediction job. The transformations are defined in SQL, to filter out all new recommendations from the predictions we can use:

WITH CANDIDATES as
SELECT DISTINCT entity_id, item_id
    FROM <ORDERS>
    WHERE timestamp <= PREDICTION_ANCHOR_TIME, sss as 
	SELECT *
	FROM PREDICTIONS
	LEFT JOIN CANDIDATES AS  
	ON PREDICTIONS.entity_id = CANDIDATES.entity_id 
	   AND PREDICTIONS.item_id = CANDIDATES.item_id
	WHERE CANDIDATES.entity_id IS NULL AND CANDIDATES.item_id IS NULL;

The predictions can then be used to power either notification or email campaigns in a batched fashion. Item and user embeddings can be exported for real-time serving applications.

Links to integration recipes:

• Batch mode serving of predictions
• Embedding export recipe and real-time embedding lookup