mixpanel
alias set in props even if request failed
From: https://mixpanel.com/docs/integration-libraries/using-mixpanel-alias
In fact, this behavior is so undesirable that if you call alias with an existing alias as the argument, Mixpanel will just silently ignore the alias request.
However the JS client will still set the alias in props even if the request was ignored:
mixpanel.alias("existing_alias")
mixpanel.get_property("__alias")
// "existing_alias"
I think the code actually already wanted to solve this problem correctly here:
return this.track("$create_alias", { "alias": alias, "distinct_id": original }, function(response) {
// Flush the people queue
_this.identify(alias);
});
If I understand correctly, then even if the alias already existed, it would identify as that alias anyway. The problem is that _this.identify(alias); will not do anything because of:
if (unique_id != this.get_distinct_id() && unique_id != this.get_property(ALIAS_ID_KEY)) {
Since alias is already set at this point, it will not change the distinct_id.
I think the correct solution would be actually to identify as the alias if the alias already existed. However the alias function would need a callback parameter so we can wait until this information is known. Otherwise it should change distinct_id to alias immediately, but then I don't know what the value of the alias property (in JS) is.
Basically what I want to do is, if alias already exists, identify as that alias, otherwise create alias for the current Person. I hack around it right now like this:
mixpanel.alias("myalias");
mixpanel.unregister("__alias");
mixpanel.identify("myalias");
hey @mrbrdo - sorry for the delay here. you are correct that our library will not change the distinct_id if the argument passed to .identify matches the value of _alias - my question here is why you need to change the working distinct_id back to the original if it's already aliased. our system will automatically change any aliased distinct_id back to the original when it hits our system so that all events for a given user are written with the canon distinct_id regardless of what it was sent in with (which speeds up reporting). can you give me a bit more information about what exactly you're trying to do here? i think with some details about your user flow here we can come up with a good solution. my inclination (unless i'm missing something here) is that you're actually fine just calling .alias regardless if it fails or not - the general rule of thumb is to call .alias on registration and .identity on login to keep distinct_id all synced up. if you want to do something a bit more complex (like accounting for multi-aliasing) you'll need to build the alias control flow yourself to make sure it behaves exactly as you'd like it to - we can work together to figure out the right solution here. just let me know!
The problem is the behavior of alias. It does not ignore the alias if it already existed, but it registers it as an alias on the client side, which is not only wrong but also prevents identify with that string. I need it because if the alias already exists, I want to identify as that alias, instead of ignoring it and pretending it's an alias when it's not.
I would like you to explain the purpose of the following:
this._register_single(ALIAS_ID_KEY, alias);
return this.track("$create_alias", { "alias": alias, "distinct_id": original }, function(response) {
// Flush the people queue
_this.identify(alias);
});
What is this identify supposed to accomplish? Keep in mind the register a few lines above.
@mrbrdo I totally understand - my point here is that aliases are registered server-side... that _alias flag is simply for convenience/auditing whether the alias was committed or not. i agree that this flag really shouldn't be added if the alias already exists, and i'm going to speak with the engineer in charge of this lib about a fix. that being said, i'm still unsure as to why you need to change the user's aliased distinct_id back to the original.
$create_alias adds a row to a lookup table for your project. when an event is received the very first thing we do is a simple lookup - if the distinct_id on the event returns an "original" from the table (meaning it's an alias) our servers will change the distinct_id back to that original before writing. if the query returns nothing (meaning the distinct_id is an original or hasn't been aliased at all) the data is written as-is.
my point here is that you don't really need to change the user's distinct_id from the aliased value back to the original (unless i'm missing something, in which case my apologies!) - can i have a bit more information about why you need to do this?
that _this.identify(alias) call is actually to flush any existing People data out to Mixpanel - this is what allows .alias to also send out .people.* calls without requiring an additional .identify. you're absolutely correct that this will not change the distinct_id - it's simply added for convenience and to make sure anything pending is flushed when anything happens with identity (this avoids race conditions and the potential for events to go out with the wrong id). let me know if you have more questions here!
that _alias flag is simply for convenience/auditing whether the alias was committed or not
well no, at the moment it only means that the alias was requested. it is registered even before the request is made, and the result has no effect.
I understand how the alias lookup table works. Let me give you an example that will hopefully clear up the issue.
- user comes to landing page gets mixpanel id 123456-whatever
- user registers with email [email protected]
- call alias [email protected]
- 1 month later user cancels account
- 1 month later user comes to landing page gets mixpanel id 654321-other
- user registers with email [email protected]
- call alias [email protected] (ignored)
- track event is tracked to "654321-other" and not "[email protected]"
Alias is ignored because it already exists. I want to send stuff for "[email protected]" and I don't care if it existed before. I am aware in this case the events sent before the alias call won't be transferred over, and that's fine.
Honestly I don't even see the use case where you would want to send events to the old distinct_id instead of the alias, if you just called alias (regardless if it already existed or not).
my point here is that you don't really need to change the user's distinct_id from the aliased value back to the original
I'm not doing that. User's distinct_id doesn't even change, just the alias is registered (even if it's ignored by server). Like I said I want events to go to the user with that alias, no matter if that alias was just registered for the current distinct_id or if it's some other existing user.
The problem is that we set $email on the user after signup. If we don't handle this case then we have multiple users with same $email, due to above case. As you can imagine this is not desirable, it will lead to unwanted automated emails to that user.
i understand - i agree with you that we shouldn't add the _alias flag unless the alias is actually committed, rather than simply when it's sent out. i'll follow up on this to see if we can get a change made.
you're using mixpanel.alias in an unintended way - we always advise customers to use application logic to determine whether alias had been called previously. i would assume that the persistent distinct_id would be a unique key in your DB, and thus your app code would prevent ever calling alias in this way.
are you dropping the row when a user deletes their account (rather than marking it as inactive)? if not, i think the best thing to do here would be to make a quick query to your own DB to check whether the user had previously registered. If they have you can simply call .identify to give them back their old distinct_id so that all future events will be correctly tied back to the user - if you don't have the email in your DB you can safely alias. the _alias flag is really to prevent race conditions and ensure data integrity even on slow connections, not to inform the app whether the user has been previously registered/aliased.
I've been tripped up by this behaviour too. It's definitely surprising that calling alias can cause a subsequent identify call to be ignored.
