/
Apply rules after CXIDs are merged

Apply rules after CXIDs are merged

“How can I perisist data held against a cxid after it has been part of a user merge process?”

For the best user experience and the most accurate journeys we need to understand who an individual is as they interact across channels. This often requires us to merge CXID values together if they are found subsequently to be the same individual.

This merge process is vital to allow us to maintain accurate long term information an individual.

However, some customer use cases require that data is stored in Journey Orchestration against the CXID value assigned to the individual at the time the data is written. These can change as part of the cxid merge process.

This link to the individuals CXID is broken when CXIDs are merged. The original CXID used to store the data is replaced by the original CXID and the newer one is no longer used.

This makes it difficult for customers to use any data held against the merged out CXID. In essence it will never be seen again and therefore cannot be used to access the data.

The Get CXID Template can trigger another rule when a merge occurs. The rule triggered is configured by updating the AlterianCX_mergeRule parameter with the name of the rule to call.

In the example below the rule is called MergeRule.

 

This rule will show as a linked rule in the Get CXID Tile

Merge Information provided

The Information provided to the merge rule is as follows:

Field Name

Description

 

Field Name

Description

 

cxid

The CXID that is retained as part of the merge process

Persists. Any data held against CXIDs being merged away should be rewritten using this value.

cxid1

This is one of the the CXID values that we looked up from the identification values provided as part of the merge process.

Don't forget up to three identifiers can be provided per call and therefore up to two CXIDs can be merged into another CXID.

This value will either equal the value in the cxid field, in which case this is the CXID value persisted, or it’s different and has been merged out.

If different any data held with this identifier that needs to be kept should be rewritten using the cxid field which will persist.

cxid2

This is one of the the CXID values that we looked up from the identification values provided as part of the merge process.

Don't forget up to three identifiers can be provided per call and therefore up to two CXIDs can be merged into another CXID.

This value will either equal the value in the cxid field, in which case this is the CXID value persisted, or it’s different and has been merged out.

If different any data held with this identifier that needs to be kept should be rewritten using the cxid field which will persist.

cxid3

This is one of the the CXID values that we looked up from the identification values provided as part of the merge process.

Don't forget up to three identifiers can be provided per call and therefore up to two CXIDs can be merged into another CXID.

This value will either equal the value in the cxid field, in which case this is the CXID value persisted, or it’s different and has been merged out.

If different any data held with this identifier that needs to be kept should be rewritten using the cxid field which will persist.

 

The merge rule should take the cxid field value and then compare to the cxid1-3 fields. Any values that are different from the cxid field have been merged away.

This information allows the rule to take the CXIDs being merged out and to access the cache tables that used these old identifiers. This orphaned information can then be read out and written to the same tables but with the CXID (cxid field) that is persisting.

The information that needs to be merged up to the persisting CXID identifier will depend on the customers use of Journey Orchestration. Professional services assistance may be required for bespoke use cases.

 

The merge rule is called asynchronously so we do not slow the running of the calling rule. Depending on the complexity of the merge rule the data tidy up may take some time. Due to the milliseconds speeds of Journey Orchestration a user may be exposed to more rules before the data tidy up process has completed causing inconsistent results.

 

Related content