I’m having an issue with Mixpanel identification. I want to be able to track events logged before the user logs in and identify them as such.
Here’s an exemple. Louie opens the webpage and visits the “About” page. Using mixpanel.track('Visit About'), I’m able to log Louie’s anonymous visit. All is fine and dandy.
Louie decides to log in, and a mixpanel.identify(user.id) call identifies him — and subsequent events can be tracked back to Louie. However, the first event (“Visit About”) still shows up with a random, Mixpanel-set distinct ID and hasn’t been associated with Louie.
Is this behaviour expected? What can I do? Cheers
You want alias.
From their Javascript API reference:
Use alias() when a unique ID is first assigned (registration), and use identify() to identify the user with that unique ID on an ongoing basis (e.g., each time a user logs in after registering). Do not call identify() at the same time as alias().
From your description, it sounds like, rather than viewing the "About" page anonymously and then logging in, Louie is viewing the "About" page anonymously and then signing up.
In that case, call alias when Louie signs up, and call identify when he logs in after that. That should associate the random, anonymous Mixpanel ID with Louie's new registered user ID.
Note: using this method will mean that, because Louie triggered an event anonymously and then logged in, Louie's anonymous id for that event will not be linked to his distinct id from logging in. If he had signed up after triggering the anonymous event, you would call alias, and they would be linked. This is a known limitation of Mixpanel, unfortunately. From their documentation:
This is the first time he's accessed your site from this device, so we assign a brand new distinct_id to him. He clicks around and then logs in. You should not call mixpanel.alias() in this situation - we haven't seen him on this device, but he is not a new user. ... Instead of calling mixpanel.alias() you should just call mixpanel.identify(). This will remap his phone activity to the original ID he used when signing up for your service, which is the most desirable outcome. This does mean that regrettably the events he fired before logging in will not be associated with him.
More about aliasing in Mixpanel here.
It took them a while, but here it is...
It's called Mixpanel Identity merge and it should fix the whole problem of connecting the actions an anonymous user did before signing up /logging in
The new system improves the behavior of identify(), alias(), and adds a new event called $merge.
All pre-authentication activity can now be mapped back to a user
The ID merge system makes it possible to link pre and post authenticated event streams under a single identifier. This eliminates “false-uniques”, ensuring the most accurate conversion and drop-off rates in funnels and flows.
Previously, Mixpanel could only map pre-sign up activity back to a user who was later identified. Any activity a user did anonymously before signing in again could not be attributed to that user.
Here is the whole blog post
Alias doesn't work for the scenario when existing user logs in, but I found work around for this.
When a user first logs in, check to see if the distinct_id of the request cookie matches the user id.
If they don't match, create a backend task to backfill the anonymous distinct_Id to the user's distinct_id.
Load the events with JQL, then fire them again using the mixpanel import endpoint.
The downside is that you will have duplicate events in the system since there are no way to delete events from the anonymous distinct_id.
For the imported events, you can add a property to them indicating that they are imported so they can be filtered out if need be.
Related
As per Google Assistant documentation for Smart Home, the agentUserId used in action.devices.QUERY is defined to 'Reflects the unique (and immutable) user ID on the agent's platform. The string is opaque to Google, so if there's an immutable form vs a mutable form on the agent side, use the immutable form (e.g. an account number rather than email)'
However there can be cases where the same device (with same agent user id) is attached to multiple Google Assistant accounts and in such cases a DISCONNECT request may result is ceasing report state for all accounts. The solution will be to add some unique ID corresponding to the Google Assistant account, however such information is not available in any request.
Has anyone seen similar issue and is my understanding incorrect?
The agentUserId is meant to be the user account on the smart home platform. SHP user '1234' may have a vacuum and two lights, but could be linked to multiple Google accounts.
During the account linking process, you would be expected to give a refresh and access tokens to allow for Google to have authorized control over these devices. If you assign unique access tokens for each Google account that signs in, you'd be able to determine which Google account the request is coming from.
At that point, once the user disconnects, you can use the access token in the request header to associate that with a specific Google account and only disable reporting for that account while not affecting other accounts.
So, yes the solution is to have a unique ID connecting to the account. While this is not passed in the agent ID, there is already a mechanism to make this association through the authorization system.
Alternatively, you could append a key in the agentUserId, ie. '1234-user#gmail.com'. However, this may have unintended impacts in the Home Graph. In a multi-user home, you may end up seeing the devices duplicated because Google doesn't have the right information to deduplicate.
I'm using Google Analytics to track user behavior. In order to get actionable insights, one thing I have to track is the session duration for users. Is it possible to track session duration for each user on Google Analytics by sending user-id?
With the User Explorer Report of GA you get an individual view of each user and the actions that he conducted on your website from the time of acquisition to the point of exist and at times to when the user comes back.
about the user id feature
User ID lets you associate a persistent ID for a single user with that user's engagement data from one or more sessions initiated from one or more devices.
Analytics interprets each unique user ID as a separate user, which provides a more accurate user count in your reports.
So setting user id is an internal field used by google for processing of your data. This is not a field you will be able to see so it will be hard for you to analytics things based upon this user id.
However you could send the userid with all the calls as a custom dimension this will enable you to add the dimension to your reports.
I an developing a chrome extension which doesn't has any sign up or sign in flow, instead depends on authentication of a separate web app. I started integrating mixpanel and tracking user events anonymously, Now i want to identify those anonymous users using "alias" and "identify" api. I have a user_id for identifying users from the web app exposed REST api. Now if i apply a boolean check and make sure i call mixpanel "alias(user_id)" once and call "identify(user_id)" every time user visits a page, I can see a user entry in explore tab of mixpanel but live events tab has a anonymous user with same user_id and its tracked data, I wish to link such anonymous users with appropriate user profiles.
Please help me with this if you have some understanding of mixpanel. I am new at this.
Since I didn't had a sign in or sign up flow, I cannot use
mixpanel.alias
Hence i am now calling
mixpanel.identify
As soon as user installs the plugin, Since "identify" api can be called any number of times for an user, We are able to track all future events as soon as plugin gets installed.
This way by not letting the user generate anonymous events we can handle such situation.
IBM Knowledge Center states that
Server disables security access checks during subscription execution
but does not mention the user credentials the code uses to execute which you need to know in order to map user RunAs roles on the application server.
What user credentials does FileNet use to execute event action code?
As I understand, when you create async subscription it will be executed under p8boostrap user.
And it will keep user context when you execute syncronious subscription.
But you can check it for sure.
It is using the user who triggered the action. E.g. if a user changes a property of a document (let's say DocumentTitle because it is always there) and clicks save, then an update event will be triggered which launches the subscription (if subscribed to the update event) which launches the action. Use synchronous for short running tasks, you can immediately show the update to the user. With asynchronous the user will have to click "Refresh".
Security can be a pain if not planned carefully at the beginning, for the action to be executed, the user has to have rights for the subscription, action event, document class etc. basically for everything involved or the user will get a cryptic error message when trying to modify the DocumentTitle.
Source: personal experience, sorry no official reference, if in doubt verify first.
I'm trying to figure out exactly when the event Profile_MigrateAnonymous fires.
My best guess from just tracing through my code is that it fires when it detects BOTH an anonymous membership cookie AND an authenticated membership cookie. Can anyone confirm this? I'm looking for real in depth answer here. Not just it gets called 'when a user logs in'.
Now - why do I care?
I was trying to keep the anonymous profile hanging around after a user had authenticated so that once they log out I'd still be able to tell who they were, and certain settings that may have been set.
The problem I'm seeing is that Profile_MigrateAnonymous is getting fired on EVERY request. Not just when a user has logged in. This makes me believe it to be a bad practice to keep the anonymous cookie hanging around - and that I should always call ClearAnonymousIdentifier();
For instance I have a new store and an old store. I want users that have access to the 'new store' to never be put back on the old store. Obviously - as with most shopping carts you don't need to autenticate to begin a session. Therefore I think the only way is to call 'ClearAnonymousIdentifier' as designed but keep a secondary cookie 'UseNewStore' to track which store they should go to.
is this a good interpretation. Or should I just not care that Profile_MigrateAnonymous is being called all the time?
Don't bother with it. There is a simpler way
Migrating Profile Properties During Log On
http://msdn.microsoft.com/en-us/library/taab950e.aspx