Recency, Frequency and Monetary models
Applies to: B2C, B2B
The RFM (Recency, Frequency and Monetary) algorithm helps create meaningful customer segments by analyzing customer engagement and purchase behavior based on how recently, how often and how much they transact.
The RFM model explained
The RFM model measures engagement and purchase behavior using the following characteristics.
-
Recency – what was the user’s most recent engagement/ transaction?
-
Frequency – how often does the user engage/ make a transaction?
-
Monetary – what is the size/ value of user’s transaction?
Each customer is scored on a scale of 1 to 5; with 1 being the least recent/ frequent/ purchase value and 5 being the most recent/ frequent or highest purchase value.
The model uses the following personas to indicate the value of each customer. Note the personas are based only on Recency and Frequency values.
| Value | Description |
| Champion | The best of the best. Your most recent engagers with the strongest rate of high value engagement. |
| New | Recent engagers with a strong rate of valued engagement. |
| Promising | Engagers with average recency and value. |
| Can’t Lose | Subscribers who have a stronger footprint in inactivity. Still salvageable. |
| At Risk | Engagers who show the beginnings of inactivity and low purchase behavior. |
| Lost | Your weakest engagers, with minimum activity in the observed time period. |
Model Types
The RFM scores can be measured at different levels allowing for flexibility in implementation based on the use case. The model types include the below,
-
‘Behavioral attributes only’ – Assesses a customer’s recency and frequency of behavioral engagement. This model will not yield any monetary score.
-
‘Transactional attributes only’ – Assesses a customer’s recency and frequency of purchases along with the monetary value of the purchases.
-
‘Behavioral and Transactional attributes’ – Combines both the behavioral and transactional signals to compute a comprehensive recency, frequency and monetary segments.
Parameters of the model
To create and configure the model the following parameters must be defined:
-
Algorithm: Choose the Recency, Frequency and Monetary algorithm in Unity.
-
Lookback window: You must also set a lookback window (number of days to analyze historical data)
-
Model type: You must choose one of the model types depending on the use case.
-
-
Queries: The queries you select generate the dataset used for both model training and scoring.
-
Inputs: Inputs are attributes from the Oracle Unity data model that the model uses during training and scoring.
-
Outputs: These are the data objects and attributes from the Unity data model that store the model's output values. You can customize the default output mappings if needed.
Model inputs
The RFM model uses the following data. For the model to successfully run, check the sections: key input considerations, key data guidelines and best practices.
| Attribute from Unity data object | Attribute name in the query | Unity Data object | Description of the attribute | Expected Data Type | Must have? – combined model | Must have? – Beh only | Must have? – Trans only |
| ID | ID | MasterCustomer | MasterCustomer identifier | String | Yes | Yes | Yes |
| SourceID | SourceID | Customer | SourceID of the customer | String | Yes | Yes | |
| Type | Type | Event | Engagement event type | String | Yes | Yes | |
| SourceEventID | EventID | Event | Event identifier | String | Yes | Yes | |
| EventTS | EventTS | Event | Date and Time when the event occurred | Timestamp | Yes | Yes | |
| Medium | Medium | Event | Channel/ Medium of the event engagement | String | Yes | Yes | |
| Source | Source | Event | Event source | String | |||
| ExtendedPrice | ExtendedPrice | OrderItem | Amount paid by the customer for the order | Float | Yes | Yes | |
| Quantity | Quantity | OrderItem | Number of items purchased | Integer | Yes | Yes | |
| OrderEntryTS | OrderEntryTS | OrderItem | Date and Time of the customer order | Timestamp | Yes | Yes |
Key considerations on model inputs
-
Data schema checks: If an attribute is unavailable, assign a constant default value across all records. This allows the model to validate the input schema. This will not impact the model outcomes as the attribute will be excluded during feature importance analysis due to lack of data variance.
-
Event Medium values - The ‘Medium’ attribute in ‘Event’ table must contain the value of ‘email’
-
To run the model for a non-email channel, simply alias the medium values to ‘email’ in the data query. This enables the model to execute and generate RFM segments for the non-email channel
-
-
Event Type values - The ‘Type’ attribute in ‘Event’ table must contain the values of ‘open’ and ‘click’
-
To run the model with a non-open or non-click events, simply alias the desired type values to ‘open’ and ‘click’ in the data query.
-
-
Model extensibility – The RFM model can be implemented as a b2b model as well. The model can be used to measure engagement at either the account or the contact level depending on the use case.
-
Schema consistency: Ensure that the attributes used in the query exactly match the specified 'Attribute name in the query' (in the above table) to avoid schema mismatches during model execution.
-
Non-mandatory attributes: These attributes, when available, can enhance the model’s learning and improve its predictive performance. However, if they are missing, the model will still leverage other available attributes to make predictions.
Key input data guidelines
-
Data requirements:
-
It is recommended to provide at least 50,000 data records for model training. However, it is important to bring as much data as possible to build a robust model
-
It is recommended to keep the dataset under 10M records (soft limit). This limit can vary for every model, but maintain a manageable size helps ensure efficient model performance.
-
Best practices
-
Use case first approach: Begin with a specific use case to determine the data required for solving the problem effectively.
-
Review model data requirements with both business and data teams to ensure alignment
-
-
Contextual parameters: Choose model parameters (such as lookback window) based on the business/ use case context.
-
Query validation: Test both the training and scoring queries to validate that they return data and inspect sample records resulting from the query
Model outputs
Output values will be stored in the CustomerRFM or Customer_RFMScore data object.
| Attribute ID | Attribute Name | Attribute Description | Data type |
| SourceCustomerRFMID | Source CustomerRFM ID | This attribute contains the unique ID for the object. | STRING |
| RFPersona | RF Persona | This attribute represents the persona based on Recency and Frequency scores. | STRING |
| RFMTS | RFM Timestamp | This attribute represents the time when the score gets computed. | TIMESTAMP |
| RScore | Recency Score | This attribute represents the recency score on a scale of 1-5 where (5- High recency, 1- low recency). | INTEGER |
| FScore | Frequency Score | This attribute represents the frequency score on a scale of 1-5 where (5- High frequency, 1- low frequency). | INTEGER |
| MScore | Monetary Score | This attribute represents the Monetary score on a scale of 1-5 where (5- High monetary, 1- low monetary). | INTEGER |
| MasterCustomerID | Master Customer ID | This attribute contains the foreign key to the MasterCustomerID. | STRING |
| SourceMasterCustomerID | Source Master Customer ID | This attribute contains the original form of the MasterCustomer ID from the source data system. | STRING |