Behavioural modelling updates
Added in Q1 2026
Modelling templates support for unlimited variables.
Work is ongoing to make behavioural modelling templates available in Apteco Orbit. Until then, experienced FastStats users can access and use this functionality through the FastStats Modelling Environment. Please note that both the features and the user interface in this release are still being developed and will continue to improve in future updates.
The first iteration of behavioural modelling templates (released in Q3 2025) allowed you to export dimensions from one system and import them into another. The template was limited to one instance of each type of parameter needed to create behavioural modelling dimensions.
For example:
| %GroupingTable% | People |
| %TransactionTable% | Bookings |
| %TransactionDate% | boDate |
| %TransactionValue% | boCost |
| %TransactionType% | boDestination |
| %TransactionCategory% | 01 |
This was sufficient for templating models within the “3D” scenario - systems used for a proof of concept, which only held the transaction type, date and value variables for one transaction table against an anonymised person ID.
It is now possible to template models which include dimensions using any number of variables from multiple transaction tables.
For example:
| %GroupingTable_1% | People |
| %TransactionTable_1% | Bookings |
| %TransactionDate_1.1% | boDate |
| %TransactionDate_1.2% | boTravel |
| %TransactionValue_1.1% | boCost |
| %TransactionValue_1.2% | boProfit |
| %TransactionType_1.1% | boDestination |
| %TransactionType_1.2% | boGrade |
| %TransactionCategory_1.2.1% | G |
| %TransactionCategory_1.2.2% | S |
| %TransactionTable_2% | Activities |
The templates are still exported and imported as before:
See Behavioural modelling - templates for more details.
Validation of the variable and table names used in a template takes place during the import, with a list of valid table names provided to help you achieve the correct format.
Categories are not validated on import - this occurs when the behavioural features are used.
More flexible definition of event-driven models
When defining an event-driven modelling scenario, set-up requires you to select a point-in-time which determines the transactions used when assessing the behaviour of, and looking for differences to explain, those in the analysis selection. To avoid potential misinterpretation of differences in behaviour caused by the scenario definition rather than the differences being predictive, for cases where the analysis event was explicitly after the reference date, you could only set the point-in-time to be the reference date. To provide greater flexibility, you can now choose your point-in-time in all cases, but you are prompted in scenarios where caution is necessary. This is especially useful when creating a churn model.
Churn model example
A churn model differs from a standard model in that the behaviour being predicted is not the presence of some event (e.g. a Booking or a Response), but rather the absence of any event!
You can set the model up by creating a virtual variable for the 'lapse date' on each transaction which is not then followed by a subsequent transactions within a defined period. That might - for example, be no further transaction within 12 months of making a charitable donation or, here, within 2 years of making a holiday booking. The lapse date would be the day before the end of the time window.
More details on how to set the model up are provided below.
In this example, the model scenario is defined as:
-
Base = People with a Booking Date in the year before the reference date.
-
Analysis = People with a Lapse Date up to 2 years after the booking.
In this situation it is very helpful that you can look for differences between the analysis and base during the time frame highlighted before the defined point-in-time. The model uses these differences to predict who is likely to lapse.
Warning issued
The equivalent scenario defined using standard events demonstrates the need for the warning that displays.
In the above scenario, the analysis event - the purchase of insurance - is very likely to occur before the reference date, since it is only a maximum of 3 months after the booking. If you make a behavioural feature on the Policies table - such as 'Count of previous insurance' - the analysis selection is very likely to have have at least one extra insurance transaction, but this transaction relates to the method of selection and is not a prior predictive behaviour that explains why someone is part of the analysis group.
Ignore the warning
You can still choose to create a model when there is a warning. For example, the impact of one additional transaction is minimal if people generally have many transactions. Note, however, that in a charity donation churn scenario, where many people only have one donation, this extra transaction can distort the model.
The warning relates only to behavioural features based on transaction that are used in the analysis event. In this Holidays example, any feature based on insurance policies will be distorted, but features that are not related to insurance policies will not be distorted if they are not linked to how the analysis selection is made.
In this example, the 'lapse date' is, by definition, 2 years after the booking date and it is, therefore, not possible for it to occur before the reference date.
Removing the warning
In scenarios where the definition is explicit that all the analysis event fall after the reference date, no warning is displayed, as there is no longer a risk. This may or may not be viable, depending on the scenario. The sample below illustrates the point, but is not particularly useful since the interesting behaviour, that explains why someone takes out insurance, could easily occur after the reference date and, consequently, would be missed.
As in previous releases, no warning is issued if the events themselves are used as the point-in-time.
For example:
By analysing all the behaviour before the policy date, the model is more likely to discover differences which can predict who will purchase life insurance - e.g. people who have reserved activities such as 'dangerous' sports during their holiday.
Inclusive point-in-time
In models where the “point-in-time” is based on one of the events, the transactions used for the behavioural features do not by default include the day of the event itself.
In the above example, a 'count of previous bookings' would exclude the booking which occurred on the day of the event; the person lapsing as per the diagram below, only has one prior booking, whilst the base person has two.
This is not an issue on data with a high volume of transactions but, for a charity system where many people lapse after a single donation, it has a significant impact.
When a behavioural feature is defined, the Q1 2026 release introduces the option to include the point-in-time. This option only displays when the time frame is adjacent to the point-in-time so, for example, it is not relevant if the time frame is “3 to 6 months ago”.
Transactional preview
The Modelling Environment has always included the option to create a data grid which allows you to examine records relating to the behavioural features in more detail. In the Q1 2026 release, this option is extended to allow the automatic inclusion of transactional data, and to choose a sample size.
A data grid launches at the transactional level and has the analysis date set to the training date used in the model. The addition of a transactional filter restricts the bookings shown to just those before this date. Note that it is possible for there to be relevant transactions after this date – in which case you can adjust the filter manually.
More flexible fixed-date behavioural models
The range of selections that you can use in fixed-date behavioural models is now consistent with those possible when using events. For example, the scenario below is equivalent to the event-driven example described previously, where the reference date is used to specify both the events and the point-in-time.
Similarly, a scenario using the analysis and base selections from different tables can be represented, as below:
This is equivalent to:
For more on behavioural modelling, see What is behavioural modelling?