Buy It Again

Solution Background and Business Value

Buy-it-again recommendations do not only enhance the customer experience by making relevant products easily accessible but also significantly boost business value by increasing sales and customer retention. When integrated into push notifications, in-product recommendations, and email campaigns, these personalized prompts ensure consistent engagement and timely reminders to customers, effectively driving conversions and fostering brand loyalty. This targeted strategy optimizes marketing efforts and ensures that businesses remain top-of-mind for their customers, making it a potent tool in the competitive marketplace.

Data Requirements and Kumo Graph

We can start developing our Buy-it-again 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

Buy-it-again recommendations pose a specific challenge; if we limit ourselves to using only repeat purchase signal in training we miss out on very important information content of the data. For example, what distinguishes items which are likely to be purchased again vs. ones which are only purchased once and which users tend to make repeat purchases more often than others.

The solution is to train a general item-to-user recommendation model on all purchases and filter items at prediction time. This way the model learns a more general notion of user-item affinity while the user is still served only buy-it-again 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 buy-it-again recommendations we can filter the model. In order to not be left with empty prediction sets after filtering, we can limit the predictions to only active users who have had at least N purchases in the last D days:

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

Filtering out new 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:

SELECT *
FROM (
    PREDICTIONS 
    JOIN (
        SELECT entity_id, item_id
        FROM <ORDERS>
        WHERE timestamp <= PREDICTION_ANCHOR_TIME
    ) AS CANDIDATES 
    ON PREDICTIONS.entity_id = CANDIDATES.entity_id 
       AND PREDICTIONS.item_id = CANDIDATES.item_id
);

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