Customer-Data Platforms mini-course #3-1: how to identify users (the different types of IDs)

Following a customer through is journey of discovering and using our product!

Sep 04, 2022

Hi everyone!

Welcome to the 3rd post of this series to learn about Customer Data Platforms! Here’s a quick recap of what we discovered in the first and second posts.

Customer Data Platforms collect events from sources
- There are 2 main types of events:
  1. Track: to follow user behaviors
  2. Identify: to create/update users’ profiles (and their attributes)
- Sources can be your website, your web app, or your mobile app.
Having those 2 types of events is enough for most of the use-cases when you want to send data to your destinations (your tools). There are 5 types of destinations:
1. Email marketing tools
2. Analytics tools
3. CRMs (and customer support tools)
4. Advertising platforms
5. Data warehouses or databases
CDPs lets you standardize and centralize data for all your users, to then replicate it into your tools. The goal is to have the same data anywhere, so:
1. Your teams are aligned (they look at the same numbers)
2. You can customize customers’ journeys (based on their behaviors in your app/website).
  - Not only into one tool but several — as they all have the same data.

Today, I want to bring you to a new concept we barely discussed in the last edition: user identities.

One of the important jobs of a CDP is to identify users. Think about this:

It’s great to know about user behaviors (with track events) but it’s better to know which users did what event.
It’s great to have user attributes (with identify events) but it’s better to know which users have what attributes

But all the way to this perfect identification — to « user X did Y at Z time » — we will face many questions.

And believe me, this problem is harder to tackle than it sounds!

For this post, we’re going to follow a user through his journey of discovering and using a new product (yours 😉).

Let’s go!

Let’s say you’re a B2B payment solution. You have a SaaS and payment infrastructure.

→ You users (businesses) can pay each other easily, using your app.

Your behavioral data can come from:

Your website
Your web app
Your mobile app
Your database

All of these are your sources. As soon as users interact with your business (on any of these sources) data will be sent to Segment.

The different types of IDs (and users)

1. `AnonymousIds` (for… anonymous users 🕵️‍♂️).

A. On your website

As soon as anyone lands on your website, an anonymousId will be automatically generated by Segment.

An anonymous page call for instance (meaning someone is just visiting some of the pages on your website) looks like this:

{
  "anonymousId": "aaa-aaa-aaa",
  "name": "Home",
  "properties": {
    "title": "Super nice Fintech - Pay & get paid easily",
    "url": "<http://www.superfintech.com>"
  }
}

The anonymousId is automatically generated by Segment (along with the automatically generated page call).

Quite easy for now, right? We only have:

A user who is linked to an anonymousId. Let’s say this anonymousId is aaa-aaa-aaa for the example.
Any of his ‘actions’ will be linked to this anonymousId as well.

What you can imagine is a customer profile with a list of all the pages he’s seen. Here’s what it will look like in June for example:

*(The* `anonymousId` *is stored on the browser’s local storage, and as a cookie. Meaning that if the user comes back to your website after a while, he’ll still have the same* `anonymousId`.)

Now, let’s imagine this user likes your content on your blog and decides to signup for your newsletter.

You’ll want to trigger 2 events:

A track event, let’s say website_newsletter_submitted (to know when the user subscribed).
An identify event, to attach the user’s email to his profile.

Now, our user will look like this in June:

All right! That’s it for now. Our user decided to subscribe but now leaves our website.

(He will receive a couple of emails sent from Customer.io from us (our newsletter). This is not important yet, but we’ll go back to this later).

B. On your mobile app

🚌 A couple of days later, the same user thinks again about us, but this time he’s on the bus, on his mobile phone.

He wants to see how good our iOS app is, and decides to download it from the App Store.

He opens it, and can signup from his phone, but doesn’t want to for now. So he leaves the app right away.

Here’s what happened behind the scenes:

1. A new `anonymousId` has been generated by Segment

As we cannot access the previously stored anonymousId because it’s only stored on the desktop device, Segment will generate a new anonymousId.

That means that for now, Segment considers our unique user as 2 different ones:

Anonymous user seen on desktop, who subscribed to our newsletter (with anonymousId aaa-aaa-aaa).
Anonymous user seen on mobile, who just opened the app (with anonymousId bbb-bbb-bbb).

2. Anonymous user “B” has performed the event "`Application Installed`".

By default, Segment sends this event as soon as users open the mobile app for the first time.

Our user with anonymousId bbb-bbb-bbb will have this event appearing on his profile when we look at his timeline.

If you recall correctly, mobile apps send `screen` events instead of `page`.

All right. That’s it for now. We have 2 different anonymous users (for the same person). One seen on your website, the other on your mobile app.

2. `UserId`... For logged-in (identified) users

A couple of weeks later, our user goes back to his desktop, but this time he’s ready to signup.

He:

Searches for our brand on Google
Clicks on our website (a new page call is sent, along the anonymousId aaa-aaa-aaa).
Clicks on the “Sign Up” CTA on our website
He creates his accounts, and sets:
1. His first name
2. Last Name
3. Email (using the same email
4. Password

Here’s what happened on our hand:

1. A new `userId` has been generated in our database (and sent to Segment).

So here’s a new type of id! The userId should be a unique identifier available in your database.

What typically happens when a user signs up, is that a new “row” is created in your users table.

And the userId is generated along this new row.

(Again, if you’re not familiar with databases, you can just imagine a spreadsheet with a new row and a column filled with userIds.)

As soon as this userId is available from our database, we should use it for any of our identify calls.

2. We send 2 new events to our CDP

A. `Identify` event, to create the user profile and his attribute

So here, we’ll include the recently generated event, as well as the collected traits:

{
"type": "identify",
"traits": {
	"first_name": "Fernando",
	"last_name": "Alonso",
	"email": "example@thiscasestudy.com"
},
"userId": "97980cfea0067",
"anonymousId": "aaa-aaa-aaa"
}

B. `Track` event, to know when the user signed up

{
  "type": "track",
  "event": "account_created",
	"sentAt": "2015-12-12T19:11:01.169Z",
	"userId": "97980cfea0067",
	"anonymousId": "aaa-aaa-aaa"
  }
}

As you can see, both of our events include the userId and anonymousId.

This is exactly how the magic happens…

3. Because our events include both anonymous and user IDs, we can tie different profiles together.

Segment now receives two ids:

AnonymousId has been saved and stored by Segment as a cookie (for a while).
We send the UserId along any track or identify call.

So Segment knows exactly how to link the “anonymous” activity with the “identified” activity:

First, the page and website_newsletter_submitted events were sent a couple of weeks ago with the anonymousId (aaa-aaa-aaa).
Second, the recent logged-in activity is sent with the userId (account_created, user traits…).
- Segment automatically includes the “old” anonymousId in any of our events.
We know those “different” activities are related to only one user because both anonymousId and userId are sent along our events.

And this work both within Segment, but also into any of your tools!

For example, our user’s profile will now look like this in June:

All you have to remember… 💭

That’s it for today. All you have to remember is:

AnonymousIds are generated as long as users are not identified.
- One user can have several AnonymousIds
Users are really identified as soon as a userId is sent. It’s often coming from your database.
Segment can merge different profiles together when both the AnonymousId and the UserId are sent at the same time in one of your CDP events.
- This happens within Segment, but not only: also in the destinations connected to Segment.

Now you might be wondering about the ‘unlogged-mobile-version’ of our user, and about Segment’s behaviors when it comes to managing identities from a database source or a 3rd party source (like Customer.io).

Well, see you in the next one!

Victor

GaaS

Discussion about this post