Now that you’ve established what method(s) are available to you and that you want to use this data to do more than reporting, we can think about the implementation options. As far as we see them they are:
This requires a physical action to occur from the customer. The action will include passing across some PII which will be sent off to a system using a secure httpss request which will in turn read this data and pass back an encrypted customer key that is consistent against the customer’s PII. Example actions where this may occur could be a newsletter sign up, quote request, account sign up, service log in, purchase and so on.
This method is still reliant on the direct authentication method. The difference here is that instead of requiring a physical action to occur to use the customer identifier it stores the customer identifier in a cookie after an initial direct authentication. This cookie will have specific expiration rules such as time-based or event-based. For example, the typical flow where this might be used is:
- Day 1 = Browse & Register (Direct Authentication)
- Day 2 = Return to site (Indirect Authentication)
- Day 3 = Return to site and log out (Indirect Authentication cookie expired)
This method will only be as reliable as your customer’s dependence on their specific device and browser combination as well as their desire (or lack thereof) to block cookies. That being said it is still possible to track a significant amount of behaviour this way to give pockets of insight about what the customer is doing.
For example, when a customer arrives at a site that does not require any form of authentication we’re unlikely to ever really know who they are. However it is entirely possible to confidently infer attributes about them using a combination of 1st and 3rd party data. 1st party data would be being built up via a tracking system that collates data directly owned by the business using a 1st party cookie. Such data could include what products they have looked at, items they have added to the cart or the fact that they have not purchased this item yet.
3rd party data would be being built up via a tracking system that collates data that could be utilised (not owned) by using a 3rd party cookie to store data against a specific domain. For example one such domain would be ‘doubleclick.net’. As part of an advertising partnership it would be possible to utilise this 3rd party data to enrich 1st party data to build a single view of the customer. For example, it may be possible to know via this data enrichment more about the customer’s personal interests or preferences based on other sites and other types of content and/or products they had been looking at.
If you’ve ever used or investigated the potential of using Google Analytics and AdWords to create a retargeting campaign you can see this enrichment working in harmony. Google will utilise data recorded directly by the analytics system (1st party data) and enrich it with additional demographic data (3rd party data) for the purpose of finding audiences to specifically retarget advertising campaigns to. For example:
NOTE – there are two ways a cookie can be set which play a very significant role for any company looking to adopt an inferred method of identification:
- HTTP/S Request
- Avoids any potential client-side execution issues (perhaps from obscure plugins)
- Allows data to be set against a different domain to the one the user is on
Inferring relationships in data based on specific behavioural attributes is not a simple task. It involves using or building a service that can interpret a lot of different data points and create an accuracy propensity model to determine whether behavioural patterns are similar enough to combine data together.
For example, the rules may be looking at a combination of IP address, devices, timestamps, interests and possibly indirect authentication data such as click-throughs on email. While much of the data will be stored against a cookie building up data the actual processing of this data will occur on a server (or in the ‘cloud’) by finding patterns in what would otherwise be disparate data. Based on a tolerable level of statistical confidence (80+% ?) the data will then be automatically merged for the purpose of presenting a combined view of a customer’s behaviour across browsers and/or devices.