How (And Why) We Fixed User Aliasing

Posted by Josh Weissburg on Feb 5, 2016

User identity management is surprisingly tricky. What seems simple at firstgive each user a unique ID, then track everything that happens to that user IDquickly turns complicated. But when you get it right, you can actually understand and communicate with each of your users as an individual.

Why should you care about identifying users?

There is a simple option: use Google Analytics to track actions without user identity attached to them. This gives you the raw numbers: how many people are doing each action you care about?
The problem is that you don’t know who these users areyou only know them as an anonymous IDso you can’t look at their full history in your product or add them to a cohort to see how long they stick around and how engaged they are over time. That’s somewhat limiting, but you might decide to make do. (This is the core of the “Is Mixpanel worth it?” question.)
But now think about sending messages: if you’re going to use behavioral history to decide which users get which messages, you HAVE to know who these users are. You need to tie those anonymous actions to a persistent user ID that has a phone number, email address or other contact info.
The payoff for doing full identity management to improve your analytics is big, but the payoff for stacking behavioral user engagement on top of this is huge. Full user identity tracking enables you to build durable relationships with your users, making them far more likely to stick with you over time.
When you do decide to track and manage user IDs for analytics and messaging, you'll encounter two big challenges:

Problem 1: Anonymous users

You have users who haven’t created an account or haven’t logged in but they are still taking actions you need to track. You want to combine that anonymous history with the same user’s logged-in history. The problem is that they will have two IDs: a random one attached to the cookie that tracks anonymous browsing and a permanent user ID that your system assigns to their logged-in account:
The standard way to deal with this is to “alias” the anonymous user with the real user ID, meaning that the anonymous user ID will simply point to the real one once it has been created. 
We want to create one record for this user, so we “alias” ID 1 and ID 2. Now, whenever we look up ID 1 or ID 2, the system will look at ID 2. (ID 1 has become an alias for ID 2.)
This is how most analytics products deal with anonymous users. But notice that we didn’t actually combine the information in ID 1 and ID 2. We took one ID and pointed it at another ID. We just lost all the data stored on ID 1.

Problem 2: Multiple devices

If users can access your product on different platforms (i.e. web, mobile apps), you’ll probably end up with multiple IDs for that person. In this scenario, aliasing as described above is a real problem. Say a user downloads your mobile app, then gets aliased to an account they created on your website; you won’t have access to the attributes of the original user, like mobile tokens you need to send push notifications.
That’s why we just overhauled our system to enable you to combine the data stored on multiple user IDs. Instead of picking one user ID that will be the reference point, Outbound can now merge all of the data across two or more user IDs:
Now I can call User ID 1 and get the user’s name even though I never stored this on User ID 1. I can call User ID 2 and get product preferences even though I never stored this on User ID 2. Magical!

Why aliasing matters

Our vision for Outbound is simple: engage with any customer, based on what they do, on any device. If your product runs on multiple devices, cross-platform identity management is the only way you will be able to make sense of what your users are doing and communicate effectively across devices.

Topics: Best practices