Fatigue Segmentation models

Algorithm name: Fatigue Segmentation

Applies to: B2B and B2C

The Fatigue Segmentation model helps identify customer fatigue levels and enables marketers ensure communication remains effective and relevant.

What is Fatigue Segmentation algorithm?

When customers are exposed to too many marketing messages across multiple channels, they eventually become “fatigued.” This leads to lower engagement, reduced interactions, and ultimately fewer purchases and conversions.

This model helps address the problem of message fatigue by evaluating each customer profile. Fatigue levels are measured based on past engagement behavior and the history of campaigns received and opened.

With this analysis, marketers can

  • Control the number of campaigns sent to each customer profile

  • Determine the optimal frequency of communication

  • Prevent customer fatigue while maximizing campaign effectiveness

Following is the list of fatigue persona and their definitions.

Fatigue Persona Description Example
Inactive No response to any message in the last 180 days. A customer has not engaged or received any messages in the last 6 months
Saturated

  • Active in the last 180 days

  • Messages sent recently

  • Engagement is declining

 A customer who once opened daily messages now opens only occasionally.
Over saturated

  • Active in the last 180 days

  • Messages sent recently

  • Engagement is declining due to too many messages

 A customer opens daily emails but stops engaging when the frequency of messages increase
Just right

  • Active in the last 180 days

  • Messages sent recently

  • Consistently engaged and not fatigues

 A customer opens messages at a steady rate over time
Under saturated

  • Active in the last 180 days

  • Not enough messages sent or has high capacity for engagement

 A customer responds more when messages frequency increases.

Parameters of the model

To create and configure the model the following parameters must be defined:

  • Algorithm: Choose the Fatigue Segmentation algorithm in Unity.

  • 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 Send Time Optimization 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?
ID ID MasterCustomer MasterCustomerID String Yes
SourceID SourceID Customer Source of CustomerId String Yes
EventTS EventTS Event Event timestamp TimeStamp Yes
Type Type Event Customer engagement event ('open/send' events) String Yes
Medium Medium Event Channel or Medium corresponding to the event (where it has 'email' value) String Yes
SourceEventID SourceEventID Event Event ID from the Event object String  
MarketingProgramID/ CampaignID CampaignID MarketingProgram/ Campaign Marketing Program Identifier String  

Key considerations on model inputs

  1. 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.

  2. Event Medium values: The ‘Medium’ attribute in ‘Event’ table must contain the value of ‘email’

    1. 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 recommendations for the non-email channel

  3. Event Type values : The ‘Type’ attribute in ‘Event’ table must contain the values of ‘open’ and ‘send’

  4. Event engagement : The fatigue model requires at least 180 days of engagement data.

  5. 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.

  6. 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

  1. Data requirements:

    1. 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

    2. 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

  1. Use case first approach: Begin with a specific use case to determine the data required for solving the problem effectively.

    1. Review model data requirements with both business and data teams to ensure alignment

  2. Contextual parameters: Choose model parameters (such as lookback window) based on the business/ use case context.

  3. 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 CustomerFatigue data object.

Attribute ID Attribute Name Attribute Description Data type
SourceCustomerFatigueID Source CustomerFatigue ID This attribute contains the unique ID for the object. STRING
Channel Channel This attribute represents the contact point of communication. STRING
FatiguePersona Fatigue Persona This attribute represents the fatigue Persona for e.g. Active,Saturated,Undersaturated,Inactive STRING
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

data science, data science model, analyze data, create data science model, how to create a data science model, fatigue, fatigue analysis, fatigue segmentation