CDP mini-course #3-2: the last types of sources where you can identify users
Following our user across mobile, database, and 3rd party tools!
Hi everyone!
Welcome to this last post of this series dedicated to Customer Data Platforms! Now, you should know:
How CDPs fundamentally work: with sources and destinations.
The main types of events (
track
,identify
).The main types of IDs (
AnonymousId
,UserId
).
In the last edition, we followed a user on a typical journey of discovering our product, a B2B payment solution. As a reminder:
Our user first discovered us on his desktop device, generating a first
anonymousId
He subscribed to our newsletter, leaving us his
email
He received some emails from Customer.io
He also downloaded our mobile app on the bus, but for now, he just had a look (no action).
He finally signed up on his desktop device: we pulled the fresh
userId
from our database, and we now send it along theanonymousId
in our events.Anonymous and Logged-In profiles from the desktop device have been merged together.
In both our CDP and our destinations.
Let’s see what happens next!
1. A couple of days later, our user logs in from his mobile device:
For now, our user has been anonymous (and linked to AnonymousId
bbb-bbb-bbb) on our mobile source as he has just installed the app.
But Fernando (our user) decided to use our app and to log-in from his iOS device.
Here’s what happened:
A. Anonymous user B has been linked to the real “User” (who has a UserId
)…
Similarly to what happened on desktop when our user signed up and logged in for the first time, we can now merge the anonymous user bbb-bbb-bbb seen on our mobile app to the unique UserId
from our database.
→ As we send events with both AnonymousId
bbb-bbb-bbb and UserId
97980cfea0067, Segment knows those are not different users, but the same one.
B. … And to the anonymous user A
Aaaaand that’s also true for the other anonymous user: the one who has been created the very first time the user visited our website on desktop.
→ Same story. Because Segment received:
Events with
AnonymousId
aaa-aaa-aaa andUserId
97980cfea0067Events with
AnonymousId
bbb-bbb-bbb andUserId
97980cfea0067
Segment knows those previously-separated anonymous users are actually only one person.
C. Activities have been merged together, and we have a unique user with several AnonymousIds
That means we now have access to a (way) more detailed view of our customer, with:
His anonymous activity from desktop (first time seen)
His logged-in activity from desktop
His anonymous activity from mobile
His logged-in activity from mobile
All of this, merged together!
In this situation, a unique user can have multiple anonymousIds
.
That’s precisely how you can tie different profiles from the same users but generated from different sources of data flowing into your CDP. Super cool, isn’t it?
Let’s take some other examples to see again how things work inside a CDP for different sources.
2. Sending data from a server source or your database
Two more and more popular ways to set analytics are to work directly with data coming from your database or your server as we were discussing in a previous post.
This way, you’ll be able to set more reliable and secure analytics. The good news is that CDPs handle this as well.
For our example (B2B fintech) we might want to send data about transactions for instance.
→ As a fintech, you might also offer credit cards to your customers. Transactions happen offline: a user doesn’t have to be connected nor to interact directly with your UI to use his card.
For this, we’re forced to send events not from our apps (desktop/web) but directly from what happens behind the scene: our database, or a server source.
From a server source, you can send track
and identify
events as well
You can ask your developers to add Segment events that trigger from the backend source code. Similarly to what we’ve seen in the first post, you’ll be able to follow users’ behaviors, but from behind de scenes.
This works for the transactions a user makes for instance: you can send a track
call transaction_succeeded
to know how often your users actually use their cards for instance.
Of course, the implementation is more complex, but also way more powerful. Having this kind of that can unlock many possibilities for Sales, Marketing, or even just analytics.
About the user “linking” (it’s easy now)
I hope you start to get the idea! Even if the track
event is sent from the backend, as it contains the userId
(it should) the event will be linked to the previous ones this way!
And again, as the event is to Segment, that also means it will be available through all your tools!
From your database, using SQL queries and Segment Personas
To do so, there is a Segment add-on called Personas. Personas basically helps you query your database using SQL so you can pull data about transactions, for example.
Currently, I do not recommend Personas for your business. We’ll discuss this in an upcoming post, but feel free to reach out to me if you need to chat about this! Happy to help.
What Personas will do actually is:
Run your SQL queries at regular intervals (let’s say, every day at 9:00 am).
Send
Identify
events to transform all the columns from your SQL query into user traits.
This helps you create/update really accurate and robust user profiles across your tools, as the data is coming from your database — and thus is 100% reflecting reality. As a reminder, front-end events can sometimes be missed. Important to keep that in mind!
3rd party sources (Customer.io example)
Finally, Segment can also receive data from the different tools you use, for you to understand customer journeys not only in your product but also from your marketing or sales initiatives.
Do you recall? In our last post, we sent some newsletters to our user before he signed up for our product
Well, if we plug Customer.io as a Segment source, then it will also send events to Segment. For instance:
Email Delivered
Email Opened
Email Link Clicked
This way, we can do analytics and create correlations between many things:
Pages the user first visited (on desktop)
Emails we sent him for nurturing
Usage of mobile app
Usage of desktop app
Plus, not only can we do analytics, but also operations, as Segment is able to send this data to pretty much any tool you want (you can check the 2nd post of this series for this).
All you have to remember… 💭
Here’s a quick recap of everything we’ve seen today:
With several devices, a user can have several
anonymousIds
Those IDs are merged together to create a unique profile once you send a
userId
along theanonymousIds
in your eventsThis works both in Segment and across your tools
You can send the most accurate data possible to Segment:
From your backend
And from your database (using SQL) with the Personas add-on
Even some 3rd party tools (such as Customer.io) can send events to Segment, so you can follow users’ journeys not only across your apps but also across your marketing/sales efforts.
What’s next?
This is the end of this series!
Hope you appreciated reading it as much as I appreciated writing it.
Now, you should have a really clear understanding of what a CDP looks like, why it is useful, and the different possibilities.
For the sake of simplicity, I decided to focus only on CDPs for now, as those tools have many possibilities and are not that easy to understand. But CDPs are actually just a piece of a modern growth stack.
And while this theory of having every data flowing through your CDP looks super nice, the reality often differs from this.
For example:
3rd party tools available as a Segment source are pretty rare (Customer.io is an exception)
Having to always transform everything into “events” is not convenient. And doesn’t feel right. Especially when you want to sync data from your database: you just want to send user attributes and map them easily to destinations.
But this will be for the next posts!
A personal note 🌴
I need a break!
I will take some time off, so don’t expect a new post soon. I’ll move to Bali for the next 2 months!
If you’re there right now, feel free to email me so we can meet: hello@vnouchet.fr
See you in the next one,
Victor