The key to getting the best out of the Distil AI Customer Data Platform is to ensure you associate your Customers with the way they engage with your platform. The principle way to do this is via the distil.identifyCustomer event. There are however a number of scenarios where we can’t reasonably ask our Customers to perform an action to trigger this without designing an overly burdensome customer experience.
A example of this is when clicking through from an email campaign. It is often the case that we want those Customers to view Content, browse Products – and so on – freely without having to explicitly login. Equally, in many cases the Identification Event is at the conclusion of a complex sequence of interactions, such as shop check-out. In the case of a primarily Content driven site, Customer Identification may never happen once an initial marketing sign-up has occurred.
However, as we design our experience we still want to capture the contextual history of a Customer interacting with our platform. For example we want Distil AI to know that a Customer has read a particular piece of Content – so we know not to recommend again, or they have interest in a Product – so we can suggest similar items.
The URL Identification Token feature provides an additional method to trigger onsite Customer Identification events.
The Token
Each unified Customer record in Distil is provided with a unique Identification Token. This is stored in the Core Data attributes as Tracking Id: `core_data.tracking_id`. It is a long string of characters.
e.g.
IjoiVG9ieU1hc29uQG91dGxvb2suY28udWsiLCJ2IjoiMS4wIiwiY2siOiJjN
This token uniquely identifies the unified Customer Profile in Distil. It can be used to identify the Customer when interacting with them; for instance via a marketing email, or chat system.
As this value is a long and pretty uninteresting attribute it is hidden by default in the default Customer view data screens. You can view it by adding it to the view as you would any other attribute:
It is also visible in the Single Customer Profile screen:
It is important to note, this value may not remain the same for a specific Customer over time. The Identity Resolution module in Distil AI is constantly mapping datasets to Customers and as a result of this process may renew this token as new data comes in. But the good news is that the Identification Token is treated as any other Customer attribute in Distil AI and so can be pushed to third-party platforms via Destinations.
Triggering Identification
As described in Javascript Tracking, Customer Identification is usually tied to a Customer driven event. It is a function that is part of the Distil AI Javascript library that your front-end developers will trigger when a Customer logs in/signs-up/checks-out/registerers for a newsletter or any other event that is appropriate for your platform. When the Identification event occurs the activity of the whole session is attributed to that Customer – both prior to the Identification Event and after it.
This same Identification Event can be triggered using the URL. If you have Distil AI Javascript Tracking setup on all pages it doesn’t matter which page, but by appending the parameter dtt=[core_data.tracking_id] to the URL will automatically trigger the distil.identifyCustomer tracking event.
[core_data.tracking_id] should be replaced with the Customer’s unique value.
e.g:
dtt=IjoiVG9ieU1hc29uQG91dGxvb2suY28udWsiLCJ2IjoiMS4wIiwiY2siOiJjN
You can therefore use this when building templates in your Marketing Execution, merging this value in using the same method you would to include the Customers Name, order details etc.
With Distil AI you can set up an integration and sync this token directly into your Marketing Execution tools – thus building it into a fully automated process.
URL parameters, a very quick overview
A URL Parameter is one method of sending information to your web server about the context a web page should be delivered; for example, the ID of a product to show, the details of a campaign etc.
A URL parameter consists of two elements: 1) the name (or key) of the Parameter. 2) the value of that parameter. These are separated by an equals sign: [parameter_key]=[value]
For example:
name=toby
These can be added to any URL. If the web server expects them then they will be read and used. If they are not expected, they will just be ignored. It is possible to add a URL Parameters to any URL of any site without any consequence.
A question mark ? is used to denote the first URL Parameter. Subsequent parameters should be appended using an ampersand &.
For example:
http://example.com/?[parameter_key]=[value]&[parameter_key]=[value]&[parameter_key]=[value]
Deploying to Destinations
The Customers Identification token can be deployed to any Execution Layer tool as per any other Customer Attribute.
It can also be extracted and used by your Platform team using the Distil API.
Analytics
With Distil Write to Data Warehouse your analytics team has an unrivalled ability to interrogate your platforms Engagement data. As per any other Customer Attribute the Identification Token is available in the Customers dataset.
Equally, usage of the token in URL Parameters will be available in the raw Engagement dataset. This means your analytics team will be able link to two to develop reports, analytics and predictive algorithms that are unique and bespoke to your business.
Considerations
Anything that increases your Identification coverage is good. From a purely data perspective it would be fantastic if we could ask the Customer to identify themselves in each session. There are cases where this is a reasonable request – for example membership sites (Facebook, Instagram, etc). But this is not possible, or even desirable for all platforms.
Distil AI URL Identification feature provides a good way to increase this coverage. There are however few considerations that should be taken into account.
- Forwarding: If your use-case relies on your Customers forwarding content then this could include URL Identification token. This would mean it’s possible to attribute one Customer’s contextual information to the wrong Customer. While this is not ideal, in most situations this is an edge case – and if two Customers are exchanging context about your platform, that context is likely to be relevant to both of them anyway. However, if you rely heavily on “Share” features – it is worth working through the Customer Experience to make sure this does not happen systematically. Our Customer Support team can assist you here if you need it.
- Long URLs: The URL Identification token adds a reasonably large number of characters to your URLs. There is a limit to the number of characters you can have in a URL. This is tied to the Customer web-browser. Modern browsers (Chrome, Safari, Edge, Firefox) can all take pretty significant URL lengths. Some of the older browsers struggle with anything over 2,048 characters – that includes the domain name. If you are worried about the length of your URLs then consider using a URL minification service, such a https://tinyurl.com/
- Keep it private: There are no security issues as such with publishing an Identification Token, however they are designed to be used in one-to-one Customer communications. Using them in publicly available URL, apart from being terrible SEO, could cause a significant disturbance in the Identity Resolution process.
- Good for cross-device: Leaving the considerations on a good note, this feature is great for capturing cross-device engagement as it only requires a Customer to respond to a communication and their device becomes recognised and activity on it will be attributed to them.
