Review the information below to learn about some of the more complex mechanisms behind customer journeys.
To maintain accurate counts of where customers are within the journey and within the context of Visual Business Director, we track a property called EntryExitIndex. (This value is used exclusively within the LastInteraction data set for counts on Nodes; this is not required for links.) This is because Visual Business Director data sets do not track customer IDs, and we are only able to add to the data set. Instead of taking a count of records for a given node (the intersection of journey/stage/step and channel) which might represent people who are no longer on that node, we take the sum of EntryExitIndex values for that node instead. This gives us an accurate count of people who are still on that node.
Take the example below:
- When a customer first enters the Journey, they have no previous interactions to worry about. We write a new record to LastInteraction with an EntryExitIndex of 1.
When we sum the EntryExitIndex values for that node, we get a value of 1.
- That customer has a new interaction that places them on a different node in the Journey. Now, we need to write 2 records to LastInteraction.
- The first is much like the record written previously. We write a record for the new node with an EntryExitIndex of 1.
- The second is a negative record for the previous node, with an EntryExitIndex of -1.
- When we perform the sum function on Node 2, we get a sum of 1. When we perform the sum on Node 1, however, we get a sum of 0. The original positive entry (1) is offset by the (-1) index of the negative entry. This reflects the fact that the customer has left that node and should no longer be counted there.
This applies at a larger scale to track entry counts and exit counts to give us an accurate count of how many people are still present on any given node.
0-Index and declines
As part of the design, we want to track when a customer drops out of the Journey. This group of customers is represented visually by the orange bar that appears beneath some nodes and is also represented numerically in the overlay that appears when you click on a given node. Presently, the only way a customer could be considered as having declined is if a Journey interaction is recorded with an outcome of Rejected. This fits with the common interaction pattern presented by offers, but also allows users to configure other interactions/events in such a way that a Rejected outcome is recorded in any instance where they would like the user to be considered out of the Journey.
To manage this technically, we need to once again utilize EntryExitIndex. Recall that every time an interaction is recorded, the last interaction on the current Journey (if any) for the current customer is included with the Journey interaction to remove that customer from the last place they were present. In order to maintain proper counts, a Rejected outcome Journey interaction should be recorded with an EntryExitIndex of 0. This is automatically performed as part of the UpdateCurrentRecordInfo data transform run by the DF_ProcessJourneyResponse data flow. If the outcome is Rejected, EntryExitIndex is automatically set to 0.
To walk through the visual above, let's consider an example:
- A customer named John opens an email we sent him, and that is his first interaction on our journey. This creates a single journey interaction, with EntryExitIndex of 1, in the IntroductionEmail step.
- John, after reading the email, decides he is not interested in the offer and actively removes himself from the Journey by unsubscribing from the offer/email list. This has been configured to record an outcome of Rejected.
- Since John's previous interaction was on the IntroductionEmail step, we record an interaction with an EntryExitIndex of -1 for IntroductionEmail. This negates his presence on the node.
- While John is still a customer, since he has a Rejected (Declined) interaction on the current node, we need to record the interaction in such a way that he is tracked as having left the Journey without contributing to the count of people still present on that node. This is why we record an EntryExitIndex of 0. It adds a Rejected outcome which is queried separately from the Remaining count, but it also does not impact the count of Remaining positively or negatively.