Everything we do at Toovio starts with a strategic objective that is tied to a measurable outcome. Once we have those two things determined we can begin to design RTIM (real-time interaction management) data with a purpose. There are many examples but for this blog, we focus on a fast-casual restaurant trying to grow night and weekend business. To accomplish this with an active customer base you need to predict who is likely to purchase outside of their typical window. We also know we want that to be an incremental visit from an existing customer. That strategic objective requires data design to be able to tie it to a measurable outcome from an RTIM platform.
RTIM technology capabilities originate a unique and highly valuable data source. Each time the RTIM platform makes a decision the platform will typically initiate a unique session or interaction id that will persist throughout the duration of the interaction between the customer and the organization as it pertains to the aforementioned decision.
This data source is transactional in nature and thus the type of transaction and its date time are essential to record in the context of the session / interaction id (i.e. the decision). Typical transaction types are;
- Trigger
- Processed
- Decision
- Presented
- Accepted
- Conversion
Thus, each decision recorded by the RTIM platform would have one or all of the above transaction types with a unique identifier for the customer and a unique identifier for the decision attached. This data stream is literally the story (electronic data record) of an organizations’ successful or unsuccessful interaction with their customers. If you have a RTIM platform or are considering acquiring one, we strongly recommend that you engage expertise on how to design this data stream before you spend time or money on configuring capabilities.
Once the above basics of recording this data are in place now it’s time to feature engineer the data.
What is a feature?
Some refer to features as “attribution”. Features describe the transactional data. Here’s some examples of features;
- Daypart / Time
- Geography
- Location
- Price
- Promotion
- Product
- Intent
- Agent
- Channel
- Imagery
- Message
- Etc.
How do we engineer the features?
Typically, we begin with creating valid values for each feature driven by human domain expertise. For example, for the daypart feature might have the following valid values;
- AM
- PM
- Lunch
- Weekday
- Weekend
These valid values might be appropriate for a fast-casual retailer to describe customer behavior. It is critical to seek out the appropriate domain expertise when creating these values or we risk bad data (coverage and quality).
Then, we need to understand how these values of customer behavior change over time. These “time splits” are also driven by human domain expertise. Theoretically, we could take an algorithm approach to identifying time splits but let us not ever forget that the actions we take from any insights we harvest from this RTIM data stream are likely to be taken by human operators.
So, a major US big box retailer might choose the following time splits;
- 1 week
- 1 month
- 3 months
- 6 months
- 12 months
- 12+ months
Whereas an international pre-paid wireless telco might choose the following time splits;
- 1 day
- 3 day
- 5 day
- 7 day
- 15 day
- 30 day
The stark differences in these time splits reflect the stark differences in discrimination of correlating customer behavior data against strategic objectives with measurable outcomes the organization cares about. In some industries customer behavior data that is more than 30 days old offers no discrimination against outcomes whereas in other industries up to 3 years of history could provide excellent discrimination.
Finally, these features, values and time splits all come together in the form of customer level data attributes. These data attributes can then be used for real-time decisioning and predictive modeling. Depending on the industry a well-designed RTIM data stream can be counted amongst an organizations most valued customer data.