Support Article
Segmentation Trees: Splits on Stored Field are not ordered
SA-5435
Summary
In CMD version 6.3.1 a split in a segmentation tree based on stored fields were ordered by the values of the stored field. In 6.6.3 this is completely unsorted.
Error Messages
wrong display order
Steps to Reproduce
Run a tree with split on stored field
Root Cause
The reported behavior is same in CMD v6.3.1 and CMD v6.6.3.
Resolution
The segmentation tree will be refreshed to fetch new data. However, since there will be changes in underlying data, CMD will not be knowing about new splits that needs to be added or old splits that might need to be deleted. For example, old BRANCH_CODE might be deleted (which needs the node to be removed) or new BRANCH_CODE needs to be added in between existing nodes. Thus, node numbers are expected to change on segmentation tree execution.
If the requirement is to use a node from the segmentation tree that is split based on stored fields, the segmentation tree should not be refreshed. If the segmentation tree is very much needed to be re-fresher by executing, new version of the campaign has to be created and required node has to be re-dragged.
In general, its very much possible that underlying stored field data might be added/deleted and this will result in change of node number and this behavior is same in CMD v6.3.1 and CMD v6.6.3 also.
Else, normal segment can be used in the campaign as target segment, instead of node from segmentation tree that is split based on stored fields.
Published January 31, 2016 - Updated October 8, 2020
Have a question? Get answers now.
Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.