How to validate your data through the GET CXID
- Ben Clark
We need to ensure events being pushed into Journey Analytics and the CX Dashboards are accurate and will create useful learnings for our users. We do not validate the data that is fed into Rules, relying instead on our customers to be careful when building rules and integrating to ensure the required fields are available when needed.
Our Journey Analytics and the CX Dashboards have mandatory fields and work best when the data provided meets our field and format requirements.
The GET CXID public template can be set to check for the existence of these mandatory fields, check the format of these fields is correct and provide a way to output rows that fail validation.
The GET CXID does not itself remove rows that fail validation. Instead it will highlight the row as failing validation then it will skip the queues present in the CXID Template, but still allow the row to flow through the step allowing our users a choice on how to handle these exceptions. We would recommend a that these invalid rows are removed with a Invalid Data S3 Output step before they flow through to any other queues.
In the future our Event Queue Public templates will be configured to no longer accept failing rows. Users should use this Template to understand where validation failings are occuring and make the necassary changes to the Rule or integration to correct.
Turning on validation
To turn on tracking data validation in the GET CXID open parameters and change the parameter AlterianCX_validateTrackingData from N the default to Y.
Switch | Description | Example |
|---|---|---|
AlterianCX_validateTrackingData | Turns on validation of tracking data in the GET CXID | Y - Validation is on N (Default) - Validation is off |
Input values
Field | Description | Example |
|---|---|---|
AlterianCX_isvalid | Added by the RIS or the PFE steps for use by this Template. If the Invocation fails validation this template will change the field value here to N or Y | AlterianCX_isvalid = null - Row has not yet been through Validation AlterianCX_isvalid = N - Row has failed Validation AlterianCX_isvalid = Y - Row has passed Validation
|
Identifier | At least one identifier should should be present* | Phone Number |
AlterianCX_isknown | Required for validation. A none null value needs to exist |
|
AlterianQueue_location | Required for validation. A none null value needs to exist |
|
AlterianQueue_channel | Required for validation. A none null value needs to exist |
|
Processing
The template will validate the fields and formats shown above. If the row fails validation the “AlterianCX_isvalid =” field is updated to AlterianCX_isvalid =N if it passes validation the field is updated to AlterianCX_isvalid = Y.
This field is created by the Realtime Input Step and the PFE steps and before it passes through the GET CXID it will simply be null and show as AlterianCX_isvalid =null in the logs.
Please note it’s possible in the future more than one type of data validation will be supported. If more than one is used it may be the row passes validation for one and not the other. We would still class thta row as failing validation.
Rows failing validation can be reviewed in the logs or they can be exported for further investigations using the Invalid Data S3 Output public template.
Choosing to ignore invlaid data
Various Alterian templates provide a way to stop the template activating if the data flowing into it is not valid. For example the step below belongs to the Email Manager step and we can set it to not send emails if the data in the flow of the rule is not seen as valid.
Users are able to choose from three settings
Option | Action |
|---|---|
Write only… if Data is valid | Will only action the step - i.e send emails if the row is marked as valid |
Write only… if Data is not valid | Will NOT action the step - i.e send emails because the row is marked as invalid |
Always Write | Will ignore the validation flag and always action. this provides alight performance improvements and backwards compatability |
Note: It’s possible to use a parameter to hard code the “write only if logic”. Create the Parameter and pass it through with valid, invalid, always. The value is not case sensitive.