In my last post I spoke about the two most basic requirements your website and analytics tool must support in order to track the full customer journey:
- User Identification – Your analytics tool must support user identification as a prerequisite for linking user activity across devices
- Signing In – Your users must sign in or identify themselves on each of their devices (PC, iPad, etc.)
However, although these prerequisites are necessary, I was surprised to find that they are not sufficient. Even if your website and analytics tool do support these 2 requirements, they may not always manage and interpret user activity correctly.To explain, I will now elaborate on 5 scenarios (presented in my previous post) and how Google Universal, Mixpanel and KISSmetrics handle each of them. You can take this information into account when next choosing an analytics tool, and please let me know if you have any questions or input.
Scenario No.1 – What happens to session activity prior to registration?
A user browses your site for 10 minutes, searching for products and reading reviews, prior to registering. The user then registers.Will the analytics tool track this activity prior to registration and link it to the registered user? With Mixpanel or KISSmetrics, there is no loss of session-activity when using the Mixpanel or KISSmetrics alias method, as they automatically link your user ID (that you passed to the alias method) to the internal ID allocated by Mixpanel and KISSmetrics. When a user first accesses a site from a specific device, Mixpanel and KISSmetrics generate a new client ID (distinct_id in Mixpanel and anonymous id in KISSmetrics) for that user (no. 1 in the above illustration) and begin using this ID to store all activity from now on. Once you call the alias method, these tools tie the current client ID to your user ID that you passed (no. 2 in the above illustration) – and all past activity will now be related to that user ID. Google Universal: With Google Universal it is not that simple, as there is no alias method, and the user ID attribute that is much talked about doesn’t actually exist at this point. The good news is, however, that there is a work around solution. The secret is to use the client ID that Google Universal generates for the user, and tie it to the user information on your end. When the user registers, instead of replacing the client ID with your own user ID, keep the current client ID and store it on your database. From now on, this client ID will be used every time the user logs onto the site.
Scenario No. 2 – What happens to session activity prior to signing in?
Mixpanel: Every time a user signs in, use the identify method to tell Mixpanel to switch to the relevant client ID. (This will automatically set the correct client ID based on the user ID that you passed to the identify method).Google Universal: There is no identify method in Google Universal, but by manually changing the client ID (explained here), all future activity is related to that client ID, thereby achieving the exact same result. So both Google Universal and Mixpanel support identification, one way or another. But, what about the pages already viewed by the user (browsing and searching) prior to signing in? And what about the marketing channel used? Let’s expand on this scenario. During her first visit, Anne registers on eBay from her desktop (visit I). A few days later, she uses her iPad to look for a digital camera on eBay, but doesn’t find anything (visit II). Later that same day, she uses her iPad to google for a specific camera. She finds what she is looking for, logs on, and makes a bid (visit III). What your web analytics tool should show is: 1 unique visitor with 3 visits. But what Mixpanel or Google Analytics actually show is: 2 unique visitors with 4 visits.
Let’s see why: First Visit
- Visit I, pre-registration from desktop. Anne views one page but as the analytics tool does not recognize the visitor (first visit to the site from her desktop), it generates a new client ID (100). Anne then views one more page before registering (all tracked under the same client ID (100).
- Anne now registers. The site executes the alias method and ties our newly created user ID (1000) with client ID (100) and understands that the two pageviews prior to registration are related to this user.
- Visit II, from iPad. The analytics tool does not recognize Anne as this is her first visit to the site via her iPad. Therefore, the analytics tool generates a new client ID (200), and this entire visit (2 pageviews) is related to this client ID (200). (Note that Anne has not logged in during this visit).
- Visit III, from iPad. The analytics tool still recognizes the user as Client ID (200) because she has again accessed her site via her iPad. The next two pageviews are, therefore, automatically related to this user: Client ID (200).
- Once Anne logs in, however, the site executes the identify method and uses Anne’s user ID (1000). The analytics tool now changes her client ID from 200 to 100, and all future activity will be related to client ID (100).
Presenting 2 unique visitors (client ID #100 and #200) with 4 visits (third visit was split between client id #200 and client ID #100) instead of 1 unique visitor with 3 visits is unfortunately far from correct.In Mixpanel, this behavior is by design as described here:
“This [the identify method] 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.” The results presented by Google Universal are far from correct and we currently only have the client ID to work with. As I have said before, their user ID attribute only exists in theory and they are far from being considered a user-centric platform. The KISSmetrics solution: We need to be able to merge the two identities. You can read more about the KISSmetrics built-in support for merging identities with their alias and identify methods, but in a nutshell, by using just the identify method, KISSmetrics links the current anonymous ID with the identified user every time the identify method is called (as long as the current user is anonymous and has not already been identified). So eventually, the same user ID will be linked to all activities prior to signing in.