Reading Time: 10min
(www.robert-matthees.com)
(www.robert-matthees.com)
Please respect your local data privacy laws, even though the tracking ideas outlined in this concept can be set up hidden in your backend.
by Robert Matthees > E-commerce > Cross-Device Tracking (published: 2017-08-21 | last update: 2017-08-25)
I never got why people say users need to have a registered account or even need to be logged in that we can identify them for Web Analytics & Tracking Purposes. You can even get their names, postcodes and local addresses if you want. I rather work with a set of sufficient conditions to identify users in as many states as possible on multiple devices. Enjoy the concept below!
Clearly, we need to assign User IDs next to Client IDs for Tracking nowadays. Because as we are accessing information from multiple devices on our customer journey (e.g. my Android phone, my work PC, and my notebook at home), even cross-device at the same time (e.g. watching TV + my notebook at home), a simple Client ID-based User Tracking isn't enough anymore to reflect such a fractured User Interaction holistically. It is also very likely that multiple users may share the same Device / Client ID at some point on their customer journey (e.g. when I grab the iPad on my mate's sofa table). Sometimes, more than one person is involved in the decision-making process (e.g. when I grab the iPad on my mate's sofa table to show him the sofa my wife's planning to buy). That's why we have to enrich our Analytics Data by User IDs in order to merge different Client IDs towards the actual User accordingly — generating the need for identifying users on as many touchpoints and as early as possible. And if you are able to tell which of your TV commercials made my wife initially googling your furniture brand for buying a sofa plus the number of touchpoints she had with it before: Well done, you're already on Consumer Insights Level »Ninja« (aka. Ultrasound Cross-Device Tracking #uXDT )!
If you want to track any of the above scenarios properly, at least, you will have to handle the Trinity of Session ID, Client ID / Fingerprint & User ID. What does it mean?
When a user accesses your website, the server may assign a temporary ID that is unique for the lifetime of this specific web session (e.g. the one my server has created for your session: ljjl8qf9t7o0qvsa9lsk5el8um). Typically, the default session timeout is 24 minutes, but it varies depending on the purpose of your app and e-commerce business. With a Session ID, you can track a user's journey through your website by following the different pages that got a hit during its lifetime. But it doesn't allow to identify a returning visitor as it is just stored temporarily and unique for each single session. If you just had a Session ID, every visitor would look like a new visitor.
A Client ID is unique per Browser & Device. It helps to identify a Client over a long period of time and many sessions. This enables you to tell whether this Client / Device visited your e-commerce project before (returning visitor) or is a new user. Normally, a Client ID gets stored in a Cookie with a long lifetime (e.g. assigned to you on my domain + stored in a cookie valid for 365 days as your Client ID: e78a577f-fd99-4d30-bab9-7dd39b0166db).
Even if I weren't able to store this Client ID in a Browser Cookie on your device, in case you are blocking cookies in your browser settings, I would still be able to generate a Fingerprint as alternative to a stored Client ID. A Fingerprint gets calculated out of a set of values taken from your Device / Browser configuration. This helps to identify your Client to a (quite) certain degree (e.g. with the ClientJS algorithm by using values like Browser Version, Installed Plugins, Fonts or your Operating System).
In order to reflect a User's Journey over Multiple Devices, you need to assign a persistent (and anonymised) User ID and pass it to your Tracking System like Google Analytics Servers too. This enables you to merge the Sessions from multiple Devices (Client IDs / Fingerprints) towards a specific User ID. Like this, you are able to track a User's Journey in a realistic and holistic way.
The big question is: Does a user need to be logged in in order to be identified, or are there other sufficient conditions that allow us to say that a specific User ID is using a Client ID at the moment? Think about the following scenarios.
Let's say a new user comes to your webshop. There is neither a Client ID stored in a Cookie nor a Fingerprint in your database for a similar Device / Browser configuration. In other words: It's black box without User ID, even a first time visitor from an unknown device. What you will do is assigning a Client ID. Further, you could store a Fingerprint next to the Client ID in your Database. That's what your Tracking would rely on at the moment (example values):
| Client ID | Fingerprint |
|---|---|
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 |
Now, an order happens from this Client ID. Even the Customer places a guest order without account registration, you are able to assign a User ID:
| Client ID | Fingerprint | User ID | Account |
|---|---|---|---|
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user1 | no |
You may ask: How does it help for Multi- / Cross-Device Tracking to have a User ID that will never be able to perform a login on a different device as no account was registered? In detail, how can you identify such a guest user on a different device? The answer is easy: It helps exactly for Multi- and Cross-Device Tracking as you are able to send a tagged link to the user's email inbox which probably gets clicked on another device.
Imagine, the Guest User receives your Email. Maybe, you are going to send it in the morning around 8 am when most people are on their way to work. Very likely, this email will be opened on a mobile device. If an email contains a tagged link, you will be able to identify the user on every device she clicks the link — even there isn't any account registered that would allow the user to perform a login.
Like this, you can assign the User ID known from the order that was placed on the Desktop Device for your Customer's Smartphone too. Because it's definitely the tagged User that clicked the link, just on a device that is new to your Tracking System. A second row for the same User ID needs to be added now:
| Client ID | Fingerprint | User ID | Account |
|---|---|---|---|
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user1 | no |
| cbc27526-1da2-4d61-8d06-07044d117ac4 | 2657491119 | user1 | no |
Congratulations, you successfully mapped a second device for a user who is even not able to log in as there wasn't any user account registered yet. It works very well with tagged links in messages on Social Media Networks too. Always create good reasons why a user expects / accepts + interacts with your message.
This doesn't mean that you should not take the effort to influence the user's decision to create an account. Because a user with a registered account comes with a lot of benefits for your Website Analytics & User Tracking.
Take the user from Scenario A who is linked with two Client IDs without Account Registration. Every hit from one of the linked clients is merged with the User ID. But what if suddenly another order happens from one of the devices — placed by a new Customer? Clearly, a new row needs to be added to your database:
| Client ID | Fingerprint | User ID | Account |
|---|---|---|---|
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user1 | no |
| cbc27526-1da2-4d61-8d06-07044d117ac4 | 2657491119 | user1 | no |
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user2 | no |
The next time you realise a hit from this Client ID, would you allocate the session to user1, user2 or none? There you go, that's the issue with users who don't have a registered account. Normally, I tend to say if user2 clicks logout during the first session, it's a sufficient clue that it was just a guest user:
| Client ID | Fingerprint | User ID | Account | Guest |
|---|---|---|---|---|
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user1 | no | no |
| cbc27526-1da2-4d61-8d06-07044d117ac4 | 2657491119 | user1 | no | no |
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user2 | no | yes |
Depending on your e-commerce project, it can be useful to count the active user time on your website or app to identify the main user of a Client ID:
| Client ID | Fingerprint | User ID | Account | Main User | Online Time |
|---|---|---|---|---|---|
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user1 | no | yes | 03:42:56 |
| cbc27526-1da2-4d61-8d06-07044d117ac4 | 2657491119 | user1 | no | yes | 00:11:32 |
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user2 | no | no | 00:18:43 |
Here, you would have to think about a suitable difference in interaction time that would qualify a user as the main user of your website, app or e-commerce project if multiple users were sharing the same device.
You get a much more sufficient clue about the main user if there is a stay-logged-in cookie set for the old user on this Client ID, but not for the new one. In my eyes, this is a clear enough sign to say the new User ID was just a guest user:
| Client ID | Fingerprint | User ID | Account | Login Cookie | Guest |
|---|---|---|---|---|---|
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user1 | yes | yes | no |
| cbc27526-1da2-4d61-8d06-07044d117ac4 | 2657491119 | user1 | yes | no | no |
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user2 | yes || no | no | yes |
Further, you may target the new user with a tagged email link too. If it's a guest user, very likely, the tagged link in your email will be clicked on a mobile or different device. This technique may help to identify the User ID-Client ID relation as well in the following case when even the new user sets a stay-logged-in cookie.
If more than one user sets a stay-logged-in cookie on a Client ID, of course, the old one has to expire. The big question is: Which one will you count on the next hit from the Client ID? Of course, the one with the active stay-logged-in cookie. In this case, it would be the new User ID. Of course, you could work with a new set of rules (for example) checking if the old user is logging in again straight on the next visit. This could be counted as a clue that the old one is the main user of this Client ID even no stay-logged-in cookie is set this time. Further, you could work with time-based conditions as outlined above.
If you rely solely on Fingerprints in your Tracking without Client IDs in Cookies, you need a process to update them properly (I rather add new ones to the database table as I can hardly define any sufficient conditions, especially for users without an account). It will make sense to store all values that contain a software version or device model in your database separately (and not just the entire fingerprint). This will allow you to update relevant fingerprint values one by one when you think a user has switched to a new device or run a software update and calculate a new fingerprint for the new configuration of an existing Client ID.
| Fingerprint | User ID | OS | OS Version | Browser | Browser Version | Colour Depth | whatever more |
|---|---|---|---|---|---|---|---|
| 2657491119 | user1 | Android | 6.0.1 | Chrome | 59 | 32 | ... |
You Fingerprint system need to be bulletproof for these cases and work with sufficient conditions to identify them too. Software updates are quite easy and clear to handle, switches to a new device seem to be a bit tricky. But actually, you just need to add a new row to your database once you identified the user on a new device / fingerprint. It works well even without saving all the values separately. Because updating a fingerprint is rather guessing than a sufficient condition in my eyes.
Let's start with the basics: Does your website offer a contact form? Whatever a user fills in could be added towards the User ID if you think it could be of interest one day (e.g. name & email; done with firing ajax onkeypress even without an active click on submit form):
| Client ID | Fingerprint | User ID | Account | Name | |
|---|---|---|---|---|---|
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user1 | no | John Smith | js@usa.com |
Quite similar: Are your visitors maybe able to win a prize in your webshop for which they need to fill out a form (e.g. address)? Again, whatever they enter could be linked towards their User IDs even they never signed up for an account:
| Client ID | Fingerprint | User ID | Account | Address |
|---|---|---|---|---|
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user1 | no | John Smith, 725 5th Ave, New York |
If they can even choose between different prizes (e.g. a weekend trip, a flat screen TV, or money), you will note what may influence a user best while decision-making processes. For example, you could get a clue that a user is rather convinced by immaterial benefits like free premium service (prize: weekend trip) than a free material gift (prize: TV set) or a voucher (prize: money) to convert in your shopping cart and complete the checkout.
There are many onsite interactions that provide relevant data for tracking and user insights. Even small things like filters on your category pages. Or even better: Are your visitors able to share, like & rate your content? Are there users who interact significantly more with specific pieces of content on your website? — Well, think about it: Those are very clear signals about interests and other individual preferences like preferred price range, colours and brands.
Or do you have any local stores or something else that would make a radius / geo search of interest for your users? Because, at least, you will get their post code while they locate their nearest points of interest:
| Client ID | Fingerprint | User ID | Account | Post Code |
|---|---|---|---|---|
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user1 | no | NY 10022 |
In a Google Maps Style Search Form, users will type in their full address:
| Client ID | Fingerprint | User ID | Account | Address |
|---|---|---|---|---|
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user1 | no | Drumpf Tower, 725 5th Ave, New York, NY 10022, USA |
Best case, they opt-in for the HTML5 Geolocation API (share location) and you will see how they move as you could track their location anytime they come back to your e-commerce project on opted-in Client IDs:
| Client ID | Fingerprint | User ID | Account | Timestamp | Coordinates |
|---|---|---|---|---|---|
| 26d9283c-f67b-47e9-b8b5-b0c2ed87221c | 166090075 | user1 | no | 1503604706 | 40°45'26.99" N -73°58'16.19" W |
| cbc27526-1da2-4d61-8d06-07044d117ac4 | 2657491119 | user1 | no | 1503601239 | 38°53'52.64" N 77°2'11.61" W |
| cbc27526-1da2-4d61-8d06-07044d117ac4 | 2657491119 | user1 | no | ... | ... |
This may enable you to tell where your users stay between 9 am - 5 pm and where they sleep at night.
Please respect your local data privacy laws, even though the tracking ideas outlined in this concept can be set up hidden in your backend.
Have you read my article How to Track AdBlock Users in Google Analytics even they block JavaScript / Cookies?
You may enjoy my GitHub Open Source (05/2017):
ga-rm.js Plugin for Interaction Tracking in Google Analytics