Cross Device History Reconciliation

Context

The Kameleoon platform offers the ability to merge history and actions made from visits on different devices, if the user responsible for those visits is the same. Basically, what it means for a personalization platform is that a person visiting your website twice via a desktop computer at work, then a third time via his smartphone at home, will be correctly identified as a returning visitor. The platform will correctly report his number of visits on the smartphone as 3, not 1 as would be the case without history reconciliation. This is a very powerful feature that is extremely simple to implement on Kameleoon, as long as you have a way to identify users on your side (most of the time, this will be via a standard customer login).

Using cross device history reconciliation has three significant advantages:

the ability to have a coherent targeting system, taking into account all visits and all actions across all devices;
the ability to ensure that a single visitor always sees the same variation for a given A/B experiment, no matter his current device;
the ability to have a precise and exact reporting system, where unique visitors are correctly counted.

How to activate cross device history reconciliation on Kameleoon

To benefit from Kameleoon's cross device history reconciliation, you need to have subscribed to the Personalization module and have this option activated in your account (it's an add-on to the standard offer). If this is the case, you should create a new Kameleoon Custom Data and check the relevant checkbox (labeled as "Use this custom data as a unique identifier for cross-device history reconciliation"). This will allow Kameleoon to treat this custom data as a unique identifier on your side, which will be used to map several Kameleoon visits to a unique user. Of course, you also need to implement the passing of the custom data via the usual methods (Data Layer integration, Activation API, etc).

This is all that needs to be done. The Kameleoon.API.Data.performRemoteSynchronization() method will be automatically called at the appropriate time (see below for details), and will perform the necessary SSC (Server Synchronization Call). You can also manually call this API method for greater control or special cases, but this should normally not be needed.

Cross device history reconciliation for targeting

Principle

If setup is properly done (see previous paragraph), when a new session starts and the custom data is present, Kameleoon will automatically download from our server the list of visits that took place on other devices and store this information on the current device's Local Storage.

If the custom data is empty (not yet provided), reconciliation is not performed at the start of the session. It is triggered as soon as the custom data is passed (a network call is made to our server, then targeting is re-evaluated for all active experiments and personalizations). Typically, this happens when the user logs in to your site, and you are able to recognize him and provide his user id (or email or other unique identifier) to Kameleoon.

Note that in this case the custom data will be present for the next visit, thus reconciliation will take place at the start of the following session. It's worth noting that this is independent of the logged-in status of the visitor in your system. In practice, Kameleoon implements a long standing login, ie it remembers the identifier over a long period of time.

Affected Data

The reconciliation adds the list of all previous visits not yet known to the current device. These visits include their usual information, such as (not an exhaustive list):

Number of visits and page views;
Length of session;
Acquisition channels and referrers;
Key pages seen;
Custom data (note that custom data provided in other sessions, and scoped to visitor, will be merged on the current one).

You can use normal targeting segments as usual, and they will work as expected. For instance, a targeting condition based on the number of previous visits will correctly take into account all visits; as will a targeting condition based on the previous visit duration, etc.

Cross device history reconciliation for variation allocation consistency

The premise of variation allocation consistency is relatively simple: we guarantee that an identified visitor will receive the same variation across all his different devices for a given A/B experiment.

However, it should be noted that it can lead to different variations being seen within the same session. Let's take the (complex) following example: a user goes to a website on a first device, logs in, and then triggers an AB test. We record his allocated variation as V1. He then makes a subsequent visit on another device, but is not identified yet on this device. He triggers the A/B test without being identified, then is identified (logs in) and then re-triggers the experiment again. The variation seen the second time is guaranteed to be the same as that of the first session (ie, it will be V1). But there is absolutely NO guarantee that the variation seen before identification / login will be V1.

Note that it is impossible to solve this issue, as you can either guarantee the same variation accross all devices OR the same variation at various moments within a single session, but not both. For this reason, it is assumed / expected that the identification of the visitor will take place as soon as possible in the user journey, in order to minimize this effect.

Cross device history reconciliation for analytics

History reconciliation has an impact only on the visitor view on the Kameleoon reporting. The visit view is not affected. For the visitor model, instead of merging several sessions into a unique visitor by comparing the standard Kameleoon visitorCode value (ie, visits are regrouped into a single visitor record if they have the same visitorCode, which is normally only possible for a returning visitor on the same device), we merge by looking at the value of the custom data. If the custom data is empty / not provided, then the value from visitorCode will be used instead. This allows you to have correct unique visitor metrics even when the user is not yet identified in your customer system (of course in that case, it only works for returning visitors on the same device).

The end result is that for the visitor view, metrics are provided correctly accross all devices for identified users (usually known customers). A single customer with 3 sessions accross 2 different devices will be counted as a single visitor; without history reconciliation, he would be counted as two distinct visitors (one per device).

Merging via the custom data used as unique identifier will be possible only for sessions saved after Kameleoon knows which custom data to use. As a result, it is highly recommended to setup cross device history reconciliation (with the correct custom data) when initially installing and configuring Kameleoon, and to never change the custom data setup.

For instance, if you let Kameleoon run for one month without any cross device history reconciliation, then a second month with history reconciliation activated, a single user making two visits, one during the first month and one during the second month, will be counted as two different visitors. This is normal since on the first month the key used for session merging will be visitorCode, but on the second month it will be the custom data, with (obviously) a different value! Note that this will happen even if the user was logged-in on both visits, and even if he was on the same device.

Any change in the setup of the custom data responsible for history reconciliation will thus result in temporarily false visitor based metrics. Of course, this effect will disappear over time.