How the GET CXID identification process works?
- Ben Clark
- Dave Parsons
How do we identify an individual and then track across channels?
Alterian provide a Public Template called “Get CXID” (Get Customer Experience ID).
This Template provides the identity management and matching capabilities for Alterian CX and should be pulled into any Rule where the identity of the person is important to it’s output or behaviour.
The Get CXID Template takes the three top priority fields (that are populated) to provide up to three elements of identifying information.
Example Data provided to GET CXID
Priority | Fields provided to GET CXID | Example | Accuracy |
|---|---|---|---|
1 | AlterianCX_emailhash | Used in Alterian's Email Tracking, we know this is a good identifier as it is derived from Email Address. This is created automatically and used in the standard Alterian email tracking | Good - This is taken from the Email address used to send the email so is specific to an individual |
2 | customerid | Provided by on the website by the CMS when a customer logs in | Very Good - This is taken from the customers CMS and will be linked to the users login credentials and therefore should be specific to an individual. Could be used as a Exclusive identifier. |
3 | CookieID | Cookie ID, this is linked to browser on the website when a customer is browsing but is different per browser and changes when cookies are cleared. | Poor - This relates to a browser session but doesn’t identify a specific individual. It can however be used to link anonymous browsing together but could feasibly be shared |
The GET CXID template then looks up each of these values to see if any have already been associated with a CXID. If none of the identifiers match any identifiers provided before we provide back a new CXID and link ALL of the identifiers provided to this CXID.
First browsing session user arrives via tracked email and then logs in
Priority | Fields provided to GET CXID | Value provided | Do the Identifying fields value match existing values? | CXID Provided |
|---|---|---|---|---|
1 | AlterianCX_emailhash | ca33109b491a40ad84cf8525f98b0a7b (created from Mark@Acadianhotels.com) | No - New CXID provided - same for all values all linked to the same CXID | cd315a22-b762-4d20-adff-51819728e9eb |
2 | customerid | 123456789 | No - New CXID provided - same for all values all linked to the same CXID | cd315a22-b762-4d20-adff-51819728e9eb |
3 | CookieID | 7e01bd2c-2ed0-48e8-8a4c-0d6270a45fbf | No - New CXID provided - same for all values all linked to the same CXID | cd315a22-b762-4d20-adff-51819728e9eb |
If one or more of the identifiers match this means they have been created in a previous session and this individual will already have been provided with a CXID.
Because we know we have seen this person before we assign all these ChannelIdentifiers to the previous CXID and we look to merge this sessions CXIDs with the original. The identifiers match so we believe it to be the same individual. (Note the Exclusive Identifiers functionality will restrict merging in some senarios. See Exclusive Identifiers for more details)
Second browsing session user arrives via tracked email and then browses around using a different browser
Priority | Fields provided to GET CXID | Value provided | Do the Identifying fields value match existing values? | CXID Provided |
|---|---|---|---|---|
1 | AlterianCX_emailhash | ca33109b491a40ad84cf8525f98b0a7b (created from Mark@Acadianhotels.com) | Yes - Use previously mapped CXID | cd315a22-b762-4d20-adff-51819728e9eb |
3 | CookieID | 0b4d860e-680f-4b7a-a65c-8686f4810cb9 | No - But the other identifier provided HAS mapped so we map this value to previously mapped CXID | cd315a22-b762-4d20-adff-51819728e9eb |
Any new identifiers are linked to the same CXID so any use of these values in the future will match back to the original CXID. The CXID can be used as a lookup to bring other information into the Rule flow.
Over time as people interact with Alterian CX we will build up a comprehensive list of identifiers. With these we can track a person's interaction with your brand across multiple channels.
Where we successfully match an existing CXID with another existing CXID via newly added values we will pass a merge flag through in the event data so old records can be updated with the correct new CXID.
Where Identifier priority is used
First browsing session user arrives via tracked email and then logs in
Priority | Fields provided to GET CXID | Value | Do the Identifying fields value match existing values? | CXID Provided |
|---|---|---|---|---|
1 | AlterianCX_emailhash | ca33109b491a40ad84cf852gty8b0a7b (created from Colin@Acadianhotels.com) | No - New CXID provided | bdf40940-0346-432e-8811-91140606f748 |
2 | customerid | 987654321 | No - New CXID provided | bdf40940-0346-432e-8811-91140606f748 |
3 | CookieID | f9cc1346-bd85-4a1d-9795-13eb9d2cc80d | No - New CXID provided | bdf40940-0346-432e-8811-91140606f748 |
Second browsing session user arrives direct and then browses around using a different browser before logging in
Priority | Fields provided to GET CXID | Value provided | Do the Identifying fields value match existing values? | CXID Provided |
|---|---|---|---|---|
1 | customerid | 987654321 | Yes - Use previously mapped CXID | bdf40940-0346-432e-8811-91140606f748 |
2 | CookieID | 0b4d860e-680f-4b7a-a65c-8686f4810cb9 | Yes either due to the previous browsing before logging in or one or more previous sessions - The other identifier however is a higher priority - The customerid identifier is higher quality so we use the more accurate identifier to match and the CXID that was previously used for this Cookie ID is mapped to to the CXID linked to the customerid (bdf40940-0346-432e-8811-91140606f748) | bdf40940-0346-432e-8811-91140606f748 |
Where we get more than one identifier match to an existing identifier value we work out whether the identifiers belong to the same previously provided CXID. If not, we need to make a decision on which identifier to use. We cannot use both.
We will use the identifier with the highest priority supplied in this session as this is likely to be more accurate. In the example above we use customerid rather than CookieID as this identifier is significantly more likely to be correct.
If you would rather NOT merge identifiers simply only pass a single identifier through with each call to a rule. This will stop any merging but you will lose any benefits of merging user sessions within and cross channel.
Thoughts on Identification and merging
This identification and merging process is not perfect, we rely on our customers to provide accurate identifiers to allow this to work correctly. In some cases customers may share identifiers, like a session cookie with shared browsing or a shared or family email address. We are not able to identify this behaviour.
Forwarding of emails can also cause merging issues. The email when sent has the hashed identifier built into the tracking links.
In normal usage the individual sent the email will click and when they land on the tracked website will automatically provide two tracking identifiers, “AlterianCX_emailhash” and the “CookieID” created or updated as they landed on the website.
The passing of these two identifiers in a single call enables us to link email traffic to web activity. The “AlterianCX_emailhash” is the higher priority,
When an tracked email is forwarded on the hash identifier is still included in the tracked links and our system has no way of knowing that the email is now being opened and clicked by another individual.
If another individual clicks through the email link the original “AlterianCX_emailhash” for individual one is provided but the “CookieID” would belong to the second individual. As the “AlterianCX_emailhash” is the higher priority the “CookieID” and it's related identifiers are merged to the original recipients CXID.
The exclusive Identifiers functionality may help with limiting merges in this scenario.