Mixpanel anonymous user converts to identified user tracking

Question

I'm adding Mixpanel to my web application and I'm curious about the "process" around what happens when a user transitions from "anonymous" (not logged in/registered) to "identified" (when they register / create an account on the site).

If a user comes in and is new to the site, they get an anonymous UUID (according to the documentation). The documentation also says that Mixpanel can not translate between IDs at this time.

Does this mean Mixpanel is incapable of handling the transition of a non-registered user to a registered user, and keep track of their events from before they became a registered/identified user?

If so, does anyone have experience with working around this? How'd you go about it?

Answer 1

As of December 2012, you can now use the mixpanel.alias method call to alias two ids:

https://mixpanel.com/docs/integration-libraries/using-mixpanel-alias

From the above docs:

John comes to your website, example.com, for the first time. He is assigned a randomly generated ID (perhaps 123123) by Mixpanel. Everything he does is associated with that ID.

After clicking through a few pages, he successfully signs up. On the signup confirmation page, you call mixpanel.alias("john@hotmail.com"). This doesn't actually change his ID - he is still being identified using the random ID we originally assigned him.

What it does do is add the ID "john@hotmail.com" to a lookup table on our end. Whenever we see data for "john@hotmail.com", we know to remap it to 123123, his original ID.

So, you can start calling mixpanel.identify("john@hotmail.com") on all your pages, and your events, funnels, and retention will all continue to work perfectly.

Answer 2

There are ways to make this work. But what you are really asking for is a feature called distinct id aliasing, which would allow you to reference one distinct_id ID to another. Unfortunately, we don't offer that right now. This turns out to be a much harder issue than you'd expect due to the unique nature of the data-store we wrote for mixpanel.

In the meantime, I can give you a few strategies to get around this limitation:

• When a user first comes to your website, set a distinct id for them which you generate internally. Once they register for an account, reference that distinct_id in your user detail table, and then continue to register subsequent events with that id. Each subsequent time a user auths, use the stored value as the distinct id. Hopefully when they return the cookie will still be around, and you will capture all the events without a hitch.

• You could, also, let mixpanel give them an auto-issued distinct_id value, and then grab that at the time of registration by using mixpanel.get_property() then add that to your users table, and use that when you identify them in the future.

• But what if they auth from one machine and then come on from another, or a different browser, or from a mobile device? Then the time in between when they hit your site and when they auth they'll be issued a new distinct_id by your site... and there is no way to alias! The solution here is a bit hackier. The only way to get that data is to log those events that were sent before the authentication (maybe server-side) and then send them via HTTP specification to the rest API with the correct distinct_id once the user auths. As long as you keep the correct time stamps, it will all appear correctly, chronologically within mixpanel. If the user never auths, then you can have the logged events time out and send them anyways.

Would either of these work for you?

Answer 3

When a user hits your site, identify them with a unique id and save it in a cookie if they don't already have one, then use the Mixpanel Identify API call to identify them. You can persist the unique id to your database in the user's record once they have registered, so you can re-set it in the case they clear their cookies.

If the user clears their cookies before registering, then you would be out of luck, but that's the nature of this beast and would be an issue anywhere.