use mixpanel 2.2 about analytics.js HOT 20 CLOSED

Do you know anything about the required call to mixpanel.alias mentioned in those docs? Sounds like something I don't want to have to do...

from analytics.js.

I think it helps when you have an anonymous users that turns into a known user so the two separate identities are merged into one. Haven't looked at how it should be implemented enough here, but if/when I switch from Mixpanel to analytics.js I'll send a pull if you haven't already.

from analytics.js.

K, the trouble is it's a very context specific method, and they even say do not call it in a bunch of cases... which seems like a horrible developer experience to me... and I'm hesitant to support it.

from analytics.js.

+1 on upgrading to mixpanel 2.2

mixpanel.alias is completely optionaly, not required at all

from analytics.js.

• 1 from me too. Would be very useful

from analytics.js.

It looks to me like they won't be getting rid of it anytime soon. My guess for the current version is that they aren't merging visitors at all, so I think it makes sense to bump to 2.2 without explicitly supporting alias.

Users who want alias can call it directly, until we make a clean way to create the equivalent of alias that works across providers.

My main concern is that I'm not sure exactly how the upgrade breaks people 2.1. The documentation is really vague on that point, and I'd rather not have people lose data by switching to use analytics.js. I emailed them to get a more definitive answer on what ends up breaking.

I'd like to keep the library lean by supporting only a single version of Mixpanel - so I think it makes sense to support their latest version and then hope that they don't keep making breaking changes. Alternatively, we can create multiple versions and then choose to only bundle the most recent one. The downside is that starts adding a lot of scope to keep multiple versions of different providers supported.

Out of curiosity, since we already group the identify calls - is alias the primary reason you want 2.2? I'm not sure what other benefits 2.2 gives you.

from analytics.js.

We use analytics.js for mixpanel, then we call mixpanel.alias manually since we want to track the transition from "unregistered user, no email address" to "registered user, with email address". After a user signups up or logs in, we call alias so we can identify them by their email address in future.

from analytics.js.

Btw, upgrading to 2.2 is backwards compatible.

from analytics.js.

Yeah, I think that would be our initial approach after merging in 2.2. Let developers with custom setups manually call alias.

Have you seen any of the data inconsistencies mentioned here and did you guys upgrade from 2.1 to 2.2 using the people feature? If the problems they mention are just part of an edge case, I'd be willing to update the library to 2.2.

from analytics.js.

I'm down to move to 2.2, I'll leave it up to you Calv. I think alias is a case where (for now at least) it should be called straight from mixpanel.alias and not analytics.js. Seems like it's the perfect example of such a case for the docs that we should write :)

from analytics.js.

Sounds good to me, that is essentially what we had planned.
The mixpanel guys responded:

In 2.1 you could choose to use one id for your people records distinct_id and one for your events. Now we force you to use the same id, but allow you to use alias() to tie them together.
So if you are already using two different ids, then you can end up with duplicate people records, which is bad news.

Given that, I think it makes sense to upgrade to 2.2. Analytics.js already chooses to send a single userId, so anyone who was previously using the 2.1 version shouldn't have a problem.

Edge cases can call mixpanel.alias directly.

from analytics.js.

+1 should merge in #31 - people can call mixpanel.alias manually if necessary

from analytics.js.

Gonna merge it in as soon as possible. The tests are doing some weird stuff, so I hope to figure them all out tonight.

from analytics.js.

Just merged #31

from analytics.js.

Just a thought, but since both Mixpanel and KISSmetrics have very similar .alias() calls, perhaps analytics.js should support a generic way to go from anonymous -> logged in users

http://support.kissmetrics.com/getting-started/understanding-identities
https://mixpanel.com/docs/integration-libraries/using-mixpanel-alias

from analytics.js.

Yeah that is definitely something I've been mulling over. Ideally it would all be combined into identify, but then handling logging out becomes a problem, so I guess either way you need two methods. For now we just recommend calling alias directly when you need it, but we might abstract over it soon

from analytics.js.

alias would be pretty helpful, as a user might connect from other platforms (iOS, Android) and we'd like to feed the data back to the services but won't be able to match the records because the unique ID might have been generated on Web and not passed along to the other clients yet (edge case, but it's happened before)

from analytics.js.

So after doing some alias research a couple problems:

Mixpanel throws a console error if you call alias on an already-aliased user. Which is sad because that means we can't just pave over it in identify for you nicely (can't even try catch or anything).

KISSmetrics and Mixpanel have different signatures for their alias methods. For KISSmetrics you need to know the previous user's identity.

.... Actually scratch that, after looking at the source it looks like Mixpanel's alias actually can take an optional original identity, defaulting to the current user's distinct_id. And KISSmetrics has their KM.i(); method so we could technically always default to the original using that. And actually it looks like KISSmetrics also supports not passing an original even though it's not defined that way in their docs... so... it looks like we actually can pave over those.

I'll start hacking on an alias method :p

from analytics.js.

K added an alias method! https://segment.io/libraries/analytics.js#alias

from analytics.js.

Going to implement it later this afternoon. Thanks @ianstormtaylor

from analytics.js.