How to harness the power of a CDP for machine learning: Part 2

In part one of this series, we discussed the three major infrastructure challenges posed by machine learning, and how a CDP can help to solve them. To show you what integrating machine learning into a CDP can look like, I'm going to work through a complete example, using mParticle and Amazon Personalize to implement personalized product recommendations for my made-up store: Items4U.

Items4U ("The finest items, which you will particularly enjoy"), operates a retail business across it's website, native iOS and Android apps, and network of brick-and-mortar stores throughout the country. Our challenge is that the sheer number of items we offer can make the shopping experience on our apps feel a little scattershot. I want to use ML to figure out which products I should focus on surfacing for each user.

By the end of this tutorial, I'll have set up a mechanism to deliver personalized product recommendations to each user, which will automatically continue to grow and improve over time.

At a high level, the data flow looks like this:

• mParticle collects commerce data from my website, apps and stores. Each action is attributed to a master mParticle User ID and forwarded on to Amazon, using Amazon’s Kinesis streaming service.
• An AWS Lambda function converts the data into a format that can be used to train ML models and uploads it to Amazon Personalize.
• The same function requests custom product recommendations from Amazon Personalize, and uploads the recs back to a master customer profile in mParticle.
• The mParticle customer profile powers personalization on the Items4U website and apps, as well as making the same information available in my messaging and analytics platforms.

There’s a fair amount of busy-work to go through in order to set up the AWS assets we need, but the good news is that most of it can be automated for subsequent iterations. For this reason, I’m using the AWS CLI and other scripting-friendly tools wherever possible. In this post, we’ll walk through how to:

1. Collect commerce event data through mParticle (prerequisite)
2. Create a Kinesis Stream and start streaming event data from mParticle
3. Create a Personalize dataset group
4. Create an AWS Lambda function to load data into my Personalize dataset group until I have enough data to train an ML model
5. Create a Personalize campaign
6. Update my Lambda function to request recommendations for each customer and store the recommendations on mParticle’s customer profile

To train an ML model to give product recommendations, I need data about how my customers interact with products. Fortunately, I don't have to start from scratch just for ML. Capturing commerce data is a core function of mParticle, and by the time a retail brand like Items4U is ready to explore ML, the required data is already being captured and used for more basic use cases, like app analytics, segmentation and re-targeting.

When ready to begin integrating ML with mParticle, I've already:

1. Set up inputs to collect data from the following channels: iOS, Android, Web, Custom Feed (Point of Sale), Custom Feed (Amazon Personalize)
2. Added mParticle's client-side SDKs to my iOS, Android and Web apps, and configured my point-of-sale platform to forward purchase events to mParticle using the NodeJS server-side SDK.

You can check out the mParticle Developer Docs for details on getting started with any of our client or server-side SDKs.

mParticle uses a single standard schema for capturing commerce events, and this schema is enforced by the SDKs. This means I don't have to rely on individual developers on each platform picking the right event names. To my ML model, a purchase made through the iOS app will look the same as a purchase made on the website, or in-store. For example, here's how a developer would log a purchase on my web app.

What mParticle will forward on to downstream services, like my ML model (stripped down to just the fields we care about), will look like this:

Ideally, my product interaction data is linked to a customer ID that works on my website, on my mobile apps and in-store. For me, that's the mParticle ID (MPID). mParticle's identity resolution allows me to gradually build up identities for each channel and resolve those identities to a single MPID.

For example: when a customer visits the website for the first time, I can link a cookie ID to the MPID. If the customer creates an account, I can add an email address, and perhaps a phone number. If they make an online purchase, I can add a secure hash of their credit card number. This means that if the same person then makes a purchase in a physical store with the same credit card, I can attribute that purchase to the same customer profile.

This process lets me train my ML models based on a complete set of customer interactions.

For this use case I need to bring together mParticle and four AWS services:

• A Kinesis stream receives events from mParticle
• A Personalize campaign creates product recommendations
• A Lambda function acts as a broker. It transforms data from mParticle into a format accepted by Personalize, and uploads product recommendations back to mParticle.
• IAM controls access and permissions for the other components.

These services can be configured in the AWS UI, but I'll be using Amazon's CLI tool. This way, I can reuse my work by creating a script to quickly spin up future iterations. I've followed Amazon's documentation to create an IAM user with access to the above four systems and log in to the console.

As I go, I’ll need to save the Amazon Resource Number (ARN) for each asset I create. I’ll need these ARNs to set up interactions between the different resources I create.

Create a Kinesis Stream

Kinesis is a tool for processing streaming data. mParticle will forward commerce event data to Kinesis, where it will be picked up by the Lambda function I'll set up later.

1. Create the Stream

Save the `StreamARN` from the response.

2. Create a role for mParticle to assume

For mParticle to be able to upload to the Kinesis stream, I need to create an IAM role for mParticle to assume. This role needs a policy allowing PutRecord access to Kinesis (sample), and a trust policy (sample) allowing mParticle to assume the role.

3. Connect mParticle to Kinesis.

mParticle offers an "event" output for streaming event data to Kinesis in real time. This can be set up and controlled from the mParticle dashboard without writing code. You can read an overview of event outputs in the mParticle docs.

a. Create configuration

First, I need to create an overall configuration for Kinesis. This holds all the settings that will remain the same for every input I connect. Each mParticle integration requires different settings. For example, API keys are commonly required. For Kinesis, I've already granted mParticle write access using IAM, so I only need to provide my AWS account number here.

b. Connect all sources

Now I need to connect each of my four inputs: iOS, Android, Web and POS, to Kinesis.

The settings I need to provide here are the Amazon Region (us-east-1) and the name of my stream.

c. Set filters

mParticle lets me switch each individual event name on or off for a particular output, like Kinesis. These settings help me save costs by making sure I'm only sending to Kinesis the data that I need to train my ML model. I'm interested in 4 types of commerce events:

• Add to cart
• Add to wishlist
• Purchase
• View detail

In my filter settings, I leave these four events on, and turn everything else off.

Now, I'm streaming events from mParticle to Kinesis, hurrah! But Kinesis is only a staging area. From here, I need to load them into an Amazon Personalize Dataset Group.

A Dataset Group is an overall container for a set of user data that can be used to train an ML model.

Save the `datasetGroupArn` from the response.

A Dataset Group can include up to three datasets:

• Items: Contains detail about products, including price, category, color, etc.
• Users: Contains detail about customers, like age, location, gender, etc.
• Interactions: Details interactions between users and items. For example, a user viewing a product, purchasing it, or adding it to a cart or wishlist.

Only the Interactions dataset is required, so to keep things simple it's the only one I'll use. I can come back later and improve future iterations of my model by adding other datasets.

Before I can create the dataset, I need a schema. A schema defines the shape of the data that makes up the dataset. Different ML recipes require different datapoints. For this example, I need the following elements:

• User ID - this will be the mParticle ID
• Session ID - mParticle automatically creates a unique ID for each session, which I can use.
• Item ID - this will be the SKU of the product
• Event Type - this will be the type of product interaction: Add to Cart, Add to Wishlist, Purchase, or View Detail.
• Timestamp - time of the interaction. mParticle automatically records a timestamp for each interaction.

As a Personalize JSON schema, it looks like this:

1. Create the schema:

Save the `schemaArn` from the response.

2. Create the dataset:

Save the `datasetArn` from the response.

3. Create the tracker

A tracker is an ID linked to the dataset that lets me upload events.

Save the `trackingID` from the response.

In order to train a Machine Learning solution, I need at least 1000 records in my dataset. One way to do this is to upload CSVs of historical events. mParticle integrates with several Data Warehouses, including Amazon Redshift. If I have access, I can easily create a training set from my past data. The CSV would look something like this:

However, training the model on historical data is not strictly required, and since data warehouse access is often tightly controlled, this step can be a huge bottleneck in attempts to implement ML.

An alternative way to train the model is simply to start forwarding real-time event data as it comes in. To do this I need to set up my Lambda function.

Eventually, the function will perform three tasks every time a new event is received at my Kinesis stream:

1. Transform the mParticle data into my Interactions schema, and upload it to my Personalize dataset.
2. Call my Personalize Campaign and ask for updated product recommendations for the user.
3. Use the mParticle API to store the updated recommendations on the mParticle user profile.

However, since I can't create a Personalize Campaign until I can train a Solution, this first version of the Lambda performs only the first task, while I collect the minimum 1000 events.

Lambdas can use several different languages and runtimes. I'll use Node for mine. The first version looks like this:

1. Create the IAM role

As before I need to create an IAM role to grant my Lambda function the permissions it needs to access Kinesis and Personalize.

The necessary trust policy can be found here.

Save the `Role.Arn` from the response.

I can use off-the-rack managed policies to grant access to Kinesis and Personalize:

2. Create the Lambda

To create the Lambda I need a zip file including the function itself, as well as it's dependencies in the node_modules folder.

I'll also need the mParticle API credentials for the Custom Feed I created for Amazon Personalize, and supply these as environment variables for the Lambda, as well as the Dataset Tracker ID.

3. Create an event-source mapping

Configure the Lambda to be triggered by new events received at the Kinesis stream.

By now, every time a commerce event is collected across any of my app platforms, mParticle is forwarding it to Kinesis. From here, the Lambda uploads the event to my Personalize dataset.

Now I need to wait to get at least 1000 records loaded. This can take some time. In the meantime, I can check the logs in AWS Cloudwatch to make sure the Lambda function is being invoked as expected.

A Personalize Campaign requires three components:

• A "Solution" which describes the particular ML recipe we want to use for the campaign. One dataset group can contain many solutions.
• A "Solution Version" is an instance of a Solution trained on a specific dataset.
• The "Campaign" is what will actually dispense product recommendations for a user.

1. Create a Solution

For this example I'll use Amazon's 'User Personalization' recipe.

Save the `solutionArn` from the response.

2. Create a Solution Version

Save the `solutionVersionArn` from the response.

The solution version takes some time to create. I can check in on its progress regularly with `describe-solution-version` until the response shows "status": "ACTIVE".

3. Create the campaign

The final step is to update my Lambda function to request product recommendations from my new campaign, and send those recommendations back to mParticle. The updated Lambda looks like this:

As well as updating the code, I also need to add the CAMPAIGN_ARN environment variable.

When I request recs from a Personalize campaign, I can specify the number of recommendations I want. Here, I'm going for a top 5 -- enough to populate a carousel or an email widget.

The payload uploaded to mParticle by the Lambda will look like this:

This payload records the product recommendations in two ways:

1. As an event, to record what the current recs were at a specific time.
2. As a user attribute. User attributes are kept up-to-date for each user by mParticle as new data is received. mParticle enriches incoming data with a complete set of user attributes, so any user activities captured on any platform will include the current set of recs as context.

I've now set up a Machine Learning system that can generate a set of product recommendations for every user and update them each time the user interacts with a product. Unlike a model trained on a one-off CSV upload, mine will continue to get better over time as the results of successful and unsuccessful recommendations feed back into the model in a flywheel pattern.

In part three of this series, I'll explore some ways to put these recommendations to use, and to track how well my recommendations are doing.