Defining Customer Journey Selections
FastStats allows you to define customer journey selections in a flexible manner. The selection is defined in terms of:
-
the time interval between events
AND
-
any specific transaction level criteria relating to each event - for example, particular campaign codes or booking destinations
Each event is based on an underlying transaction level selection which contains simple criteria, such as a a booking destination, a campaign code or name, or perhaps a type of response.
An underlying transaction level selection should not include date criteria.
Once defined:
-
Open a new Modelling Environment
-
In the toolbar, switch from Standard Modelling to Use behavioural modelling
-
Check and select Event-driven date for each: and set the required table level - here People
-
Set your Training Date - in this example 01/07/2020 - to ensure that you capture enough data to create a robust model
-
When prompted, select Yes to display additional columns when you come to interpret the Behavioural Modelling dimensions later
A default Base selection of All People is added to the Selections display and you can now drag and drop to add your transaction level selections. The selections will be Type - Event and a check of the Validation Status column confirm that they are valid.
Right-clicking on an Event selection presents you with the options to set up simple customer journey selections or opt for the more detailed analysis/base scenario.
Once selected, you can use the following dialog to compose your detailed customer journey selections by defining a sequence of events. Each part of the sequence has an underlying event selection, as well as timing criteria.
In the above example, Event 1 identifies people who have received the Cross Sell Campaign within one month of the Reference Date - here that is the Training Date defined as 01/07/2020. Event 2 in the sequence then looks at people who have made a Suggested Booking in the 2 months following the Event 1 - Cross Sell Campaign.
Multiple events can be added (and deleted) and moved up or down to determine the base sequence.
The Analysis selection includes all the events - including those in the Base selection.
The timing criteria relate each event, either to another event, or to the fixed Reference Date. During your analysis, the Reference Date is set to be either the Training or Evaluation Date in order to identify which period of historic data to use.
The View a Copy button can be used to view the selection logic for either the analysis or base:
It is not recommended that you edit these selections as there are inter-dependencies between criteria contained in FastStats expressions.
Using an underlying Base Selection
As we saw earlier, a selection of All People is automatically added to the Modelling Environment when you switch to the event driven strategy. This is used as the underlying selection to process when identifying events. It is possible to use a subset of people:
-
Drag a person level selection onto the Modelling Environment Selections tab
-
Use the tab at the top of the main dialog to switch to the required selection
Using a subset reduces the transaction level processing required as you are only investigating the events of people within this selection.
Using a subset is different to using the “Sampling” options. The latter are only applied later in the process to control the balance of people used in the model; they do not affect the transaction level processing.
Migration from Software Release 2021 Q1
From 2021 Q2, the comparison between dates on different tables uses a different approach to earlier releases and can now handle the case where a person has multiple possible dates for each event. A new "timeline” data structure is used to represent multiple dates; this is supported by the server and can be viewed, but not interpreted by the user interface.
When you open a Modelling Environment created in an earlier version, the earlier style of selections are still used. Only when you right click and “Edit the analysis/base scenario” does the selection generated use the new style of selection.
Processing can currently only handle a maximum 5-year span of dates for an individual.
If the transactions for an individual span a range of more than 5 years, the later transactions will not be processed. Although not necessarily a problem, this is displayed as an error in the UI.
The definition of the event will determine whether the truncated data is sufficient to make the selection. For example, if looking for a “response booking sometime after the communication”, there may be more than 5 years of possible booking events for some individuals. In this case, the selection of a response can be easily made using the first 5 years' worth of data and, therefore, truncating the events will not be a problem; it will even speed up the processing. You can avoid this situation by using more specific criteria in the selections defining each event, or by reducing the interval between events - for example, by avoiding the use of the open-ended “Sometime" option.
Allowed selections (effective from Software Release 2021 Q2)
Each event can only be referred to by one other event.
For example, if you have a booking event relative to a communication event, you cannot have e.g. another insurance event that is also relative to the communication. The insurance event could, however, be defined relative to the booking.
-
Events can be before or after the reference date but can currently only be defined as being after (but not before) another event.
A “non event” can be defined - for example, to specify that people should have no previous bookings before the Reference Date - i.e. identifying new customers.
-
This can be expressed before or after the Reference Date, but not relative to another event.
-
A non event cannot be referred to by another event.
Use the “Validate” buttons to check a selection without viewing the logic.
-
An invalid selection should only be possible if it is not yet fully specified.
For more information on using Customer Journey Selections see: