GET CXID - Person Identification
- Ben Clark
Alterian provide a Public Template called “Get CXID” (Get Customer Experience ID).
This Template should be pulled into any Rule where the identity of the person is important in the running of the rule.
The Get CXID Template takes up to three elements of identifying information, saves these values, compares these to any values recorded before and either provides back a new CXID (Customer Experience ID) to identify this person or presents back the optimal CXID that was previously assigned to this person. (See Exclusive identifiers for alternative behaviours around the merge process.)
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.
The CXID is the primary identifier in Alterian CX.
Over time as people interact with Alterian CX we will build up a comprehensive list of identifiers. With these we can track a persons 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 match flag through in the event data so old records can be updated with the correct new CXID.
The Get CXID Tile automatically records whether the person was newly exposed to your brand. This is useful when looking at customer journeys, allowing you to filter journeys for new visitors only.
The final purpose of the Get CXID is to create CX “conversations”. Alterian define a conversation as one or more interactions with Alterian CX with no gap between interactions of more than 30 minutes. Customer Journeys can be viewed using conversations. The conversation shows a series of interactions capturing one or more specific actions the person was trying to achieve.
For some Alterian CX customers billing will be linked to the number of conversations created and therefore accurate identification of a person is important. It improves the information you hold in Alterian CX and importantly it also allows for more accurate calculations of conversations helping to reduce your costs.
Placing the GET CXID Template
If you have a “Conversations” contract with Alterian, you will need to add the Get CXID Tile into every Rule you create.
For each Rule we would recommend the Get CXID Tile is added directly after your Input Tile. This allows the identification information to be passed directly into the Get CXID Tile and for the information provided by it to be available for the full flow of the Rule.
The Get CXID requires the following information to work correctly.
Fields Required by Get CXID | Commonly mapped Fields | What is required | Mandatory or Not? |
AlterianCX_inboundSource | AlterianCX_inboundSource | If the parse campaign tracking tags is used we will use the AlterianCX_inboundSource provided by this to indicate the source of the visit | Not Mandatory |
AlterianCX_inboundMedium | AlterianCX_inboundMedium | If the parse campaign tracking tags is used we will use the AlterianCX_inboundMedium provided by this to indicate the source of the visit | Not Mandatory |
AlterianCX_isknown | AlterianCX_isknown | Is this identification value for a person known to the brand? | Mandatory |
AlterianCX_referrer | AlterianCX_referrer | The referrer for the Invocation of this Rule. Where a location is provided we will use the referrer domain. If the parse campaign tracking tags is used we will use the AlterianCX_inboundMedium field as a the channel and AlterianCX_inboundSource as the Channel Source and Direct is used in the location if one is not provided in the call.
| Not Mandatory** |
AlterianQueue_channel | AlterianQueue_channel | What Channel is using this Rule in this specific call | Mandatory |
AlterianQueue_location | urlPath | Where the Rule is being called from. For website tracking rules it’s often the urlPath taken from the page URL that should be used. | Mandatory |
AlterianQueue_position | AlterianQueue_position | Where within the Location the rule is being used. Top Banner, Hero banner, Footer banner all on the home page using the same rule. Rule Position identifies which one was using the Rule in this specific call. | Not Mandatory |
Is Control | Is Control | Identifies whether the individual is in the Control Group for this Rule. Created by Alterian CX | Automatic |
It also requires Identification fields as defined below.
Identification Field Mapping
The GET CXID Template needs to understand who is interacting with the rule so we can track the activity against an individual and create the conversations. To do this we need to provide the GET CXID with the fields that will provide the identification values.
We provide the fields that contain the identification values within a parameter inside the GET CXID called
AlterianCX_identificationFields
This parameter has been given a default value so we will still support the old and new default identification fields.
With the defaults we will use the top three of the following in order of priority where the value is populated.
Default Values
Priority | Fields | Origin / Use |
|---|---|---|
1 | AlterianCX_emailhash | Used in Email Tracking, we know this is a good identifier as it is derived from Email Address |
2 | dderh | Used in Email Tracking, we know this is a good identifier as it is derived from Email Address |
3 | customerid | Default field to allow a customerid to be mapped. New default value to allow our Public Rules and Templates to function without changes |
4 | emailAddress | Default field to allow an emailAddress to be mapped. New default value to allow our Public Rules and Templates to function without changes |
5 | mobileNumber | Default field to allow a mobileNumber to be mapped. New default value to allow our Public Rules and Templates to function without changes |
6 | visitorId | Default field to allow a vistorid to be mapped. New default value to allow our Public Rules and Templates to function without changes |
7 | AlterianCX_channelagentid1 | Old default - This will allow older rules using channelagentids to continue to work wiht no changes. |
8 | AlterianCX_channelagentid2 | Old default - This will allow older rules using channelagentids to continue to work wiht no changes. |
9 | AlterianCX_channelagentid3 | Old default - This will allow older rules using channelagentids to continue to work wiht no changes. |
Adding new Identifier fields
When you are creating your rules you may have alternative identification fields to provide to the GET CXID. You may for example pass through fields called ‘email’ or ‘CookieID' or 'LoginID’.
How do you change the GET CXID to use these?
Firstly we need to create a new Global Parameter
AlterianCX_identificationFields
Simply create an ordered list Global Parameter called ‘alteriancx_identificationfields’ this will allow the changes made to this Global Parameter to cascade down to the same named parameters in the Rules.
Set the Parameter as Forced and Visible - This will allow the users to see the values being used in the Rule and allows the value cascade to work.
Set the Global Parameter as Data Type 'Ordered List'.
In ‘Values’ provide the superset of the identification fields you may use in any of your Rules. It’s okay to include all of them, the GET CXID will only use the top three based on priority where populated.
Edit the order of the identification fields for each target. The fields on the far left has the highest priority so ensure your best identifiers are included here.
If you are using Alterian Email Tracking ensure ‘AlterianCX_emailhash' and 'dderh’ are included as high priority Identifiers
Once the Global Parameter has been set you will find that the AlterianCX_identificationFields parameter in the rule now has your selected fields.
The GET CXID will now use these fields to identify an individual and work through them in priority order. We only use the top three which are populated.
Up to three can be provided in each call. The more you supply the better the chance that you will match a previous value and by providing them in one call you automatically add and link these values for checks in the future. If you have more than three possible, we would recommend providing the most accurate and what could be considered the less accurate identifiers.
Customer ID will successfully identify a specific person and providing Cookie ID, which is less accurate will match a specific cookie to a known accurate user.
Providing the Identifiers in priority order will help when merging the data. For example if you have available:
Cookie ID
Customer Number
Email Address
We would recommend
Priority | Identifier |
|---|---|
1 | Customer Number |
2 | Email Address |
3 | Cookie ID |
With this ordering we will look to merge any information with the Customer number if matches occur.
If you do not provide a populated Identifier field the Get CXID Tile will generate its own random value to provide a conversation metric. This will have an impact on the number of conversations generated, increasing numbers significantly and therefore providing accurate alternative identification value should be a focus.
Rule Designer will highlight where you have created a Rule but have not included a Get CXID Tile. You will not be able to start the Rule until the Get CXID Tile has been included in a sensible position.
AlterianCX_referrer **
The referrer is marked as not mandatory. In many cases it is not needed or provided. As users move through your website page by page each may provide a referrerbut these are of little value.
However where you want to record which campaign or creative started a journey or a specific originator for a journey the referrer automtically provides this information.
The standard track web rules for example will include the Identify Email Manager Clickthrough which requires the querystring elements from the referrer to work and will identify which Alterian email was involved in your journeys
The parse campaign tracking tags public template will identify UTM query strings in the referrer allowing you to use these in the flow of the rule and to improve the accuracy of your reporting.
Please include the referrer where this is possible.
Control Groups
The Get CXID Public template is pivotal in highlighting to a Rule whether someone being exposed to the Rule is in a Control group or not. As such we have built into the Get CXID some Rule level setting related to Control Groups.
Control Groups are turned on and off at an Initiative level. Here the Control group percentage is set as is whether success growth is a good or bad result.
Further changes can be made at a Rule level.
Test Iteration
Where significant changes are made to a Rule, the previous results gathered for that Rule are no longer relevant when measuring current success. The Get CXID Public Template in each Rule now allows the setting of a “Test Iteration”. Test Iterations are optional, they restart the Control Group for this specific rule. Anyone who was in the Control Group for the previous Test Iteration is removed from the Control Group. Everyone who is exposed to the Rule moving forwards is retested to see if they should now fall into the Control Group for the new Test Iteration. Our expectation is that once significant changes have been made to a rule the iteration should be increase by one allowing future calculations on success specific to this iteration of the Rule.
Control Group Lifespan
By default, individuals remain within a Control Group for 180 days. After this they are automatically removed. This Control Group lifespan can be changed on a Rule by Rule basis by changing the Control Group Lifespan Parameter within the Get CXID within each Rule. This parameter is based on days to remain in the Control Group and will apply to those individuals added to the Control Group after the change is made.