​

Overview

Dynamic Sender Routing is a customised routing system that automatically selects the most appropriate sender for each API request. By defining custom routing rules based on user properties or API attributes, you can optimize your messaging for better deliverability, manage sending costs, and ensure compliance with local regulations. Configuring dynamic sender routing eliminates manual sender selection, providing a powerful and flexible solution for managing your communications at scale.

​

Use Cases

• Geo-based routing: Automatically route messages through a local sender based on the user’s country code (e.g., use a US sender for +1 numbers and an Indian sender for +91 numbers). This improves local deliverability and can optimize costs.
• Cost optimization: Configure routing to prioritize the most cost-effective sender for a given region. This enables the dynamic selection of senders to optimize messaging costs based on volume or other pricing criteria. For example, A routing rule can be configured to use Sender A for all messages to the US, where the per-message cost is $0.01. If the monthly message volume to the US exceeds 10,000, a rule is triggered to use Sender B, which offers a bulk rate of $0.008 per message, thereby minimizing total sending costs.
• A/B testing of senders: Create a routing rule to send a small percentage of a campaign’s traffic to a new sender. This allows you to test the new sender’s performance before rolling it out to your entire audience.

​

Configure Dynamic Sender Routing

To configure dynamic sender routing rules, perform the following steps:

1. Log in to the MoEngage dashboard and navigate to Settings on the left-side panel.
2. Under Channels, select the required channel. As this feature is supported only for SMS and Email channels, select the channel as per requirement.
3. On the following page, click the Dynamic Sender Routing tab.
4. On the Dynamic Sender Routing page, click + Add Condition.
   
   
5. On the Add condition page, enter the following details:
   • Name: Enter the condition name. This name helps you identify and manage the condition, and you can use it when creating alerts.
   • Description: Add a description for the condition that indicates where and how you use the rule.
   • Rule type: This field allows you to select the rule required for sender selection. The following rule types are available:
     
     
   • Attribute Based: This rule type allows you to select a sender based on attributes stored in the user profile. For example, if moe_mobile (an attribute) starts with +1, use Sender_A ( a sender); else if moe_mobile (an attribute) starts with +91, use Sender_B (another sender). Conditions for this rule are explained below:
     • If condition: Defines the initial condition. For example, if a user’s moe_mobile attribute starts with +1, use Sender_A.
     • + Add condition: Click + Add condition to add more Else if conditions. If the initial If condition is not met, MoEngage checks this condition. For example, if the moe_mobile attribute starts with +91, use Sender_B.
     • Else use fallback sender as: If neither the If nor any Else If conditions are met, the system uses the specified fallback sender as a default.
       
       
   • Traffic split: This rule type allows you to select multiple senders and split traffic among them. For example, send 50% of the traffic to Sender A and 50% to Sender B. You can add up to five senders.
     
     
   • Performance based: This rule type automatically switches senders based on real-time performance instead of following a fixed sequence. You can configure up to five senders, and if a sender’s performance measured by Sent Rate or Delivery Rate drops below the configured threshold within the defined monitoring window, the system automatically switches to the next sender. For example, if Sender 1’s Delivery Rate drops below 80% in the last 5 minutes, traffic switches to Sender 2. If Sender 2’s Delivery Rate also drops below 80% during the next monitoring window, traffic switches to Sender 3, and so on. Once the configured time period elapses, the system resets the routing sequence and routes traffic back to the primary sender, restarting the sequence from the beginning.
     
   • Sender fallback: This rule type allows you to configure multiple senders as fallback options. If sending through the primary sender fails, the system automatically attempts to send through the next sender in the configured sequence, for example, if Sender 1 fails, it tries Sender 2, and if Sender 2 fails, it tries Sender 3. You can configure up to five senders in the sequence.
     
   • Advance customisation:
     This option allows you to use a combination of API attributes (a piece of data passed to MoEngage as part of an API call, but is not stored as a permanent part of a user’s profile) and user properties to create a rule to select senders. Conditions for this rule are explained below:
     • If condition: Defines the primary conditions that must be met for the rule to apply.
       • Select Attribute: Choose the user or API attribute for the condition.
       • Select attribute value: Enter or select the specific value for the chosen attribute.
       • Operator: Select a logical operator.
       • Case Sensitive: Select this checkbox if the value comparison should be case-sensitive.
       • + Add nested condition: Add more criteria that combine with the existing ones using AND or OR logic.
     • Then condition: Defines the sender that you want to select when the If conditions are met.
       • Select User Property/Sender: Choose the user property or sender for the condition.
       • + Add sub-condition: Define specific sub-conditions to select the sender. Add multiple criteria for sender selection within the Then block.
       • Else if: Click + Add sub-condition to add alternative sub-conditions using Else if within the same Then block. MoEngage evaluates these sub-conditions sequentially. It executes the action for the first one that is true and ignores the rest.
     • + Add condition: Click + Add condition to add multiple Else If-Then rule blocks to create complex routing logic. The system evaluates these blocks in the order they appear, and the first rule whose conditions are met dictates the sender whether that’s a specific sender, a fallback sequence, or Performance-Based Monitoring.
     • Else use fallback sender as: If none of the defined conditions are met, the system uses the specified fallback sender.
       
       
   You can also use Traffic split and Sender fallback as conditions in Advance customisation. These work similarly to their respective rule types described above.

   ​

   Sample Rules

   The following are some of the sample rules created using the combinations of different user properties, different API attributes, and the combination of user and API attributes.
   Sample rule created using different user properties

   If a user’s moe_country_code is US AND their LTV (Lifetime Value) is greater than 500, then use Sender_A. If the moe_country_code is US but their LTV is less than or equal to 500, use Sender_B.
   Conditions for this rule:
   If moe_country_code (user property) is US AND LTV (user property) is greater than 500, then use Sender_A.
   Else if LTV (user property) is equal to 500, then use Sender_B.
   Sample rule created using different API attributes

   If campaign_type (API Attribute) is Promotional AND priority (API Attribute) is low, then use Sender_A. If the campaign_type (API Attribute) is Transactional AND priority (API Attribute) is high, then use Sender_B.
   Conditions for this rule:
   If campaign_type (API Attribute) is Promotional AND priority (API Attribute) is low, then use Sender A.
   Else if campaign_type (API Attribute) is Transactional AND priority (API Attribute) is high, then use Sender B.
   Sample rule created using a combination of user property and API attribute

   If the Region (API attribute) is North America, then use Sender A for users whose mobile number starts with +1, and use Sender B for all other users whose mobile number exists.
   Conditions for this rule:
   If the main condition is met (the region is North America), the nested condition is as follows:
   If the Mobile Number (user property) starts with +1, then use Sender A.
   Else if Mobile Number (user property) exists, then use Sender B.
6. Click Save. After saving, all the routing conditions you created are listed under the Dynamic Sender Routing tab
7. Click the ellipsis icon against each condition to edit that condition.

​

FAQs

What is a fallback sender?

A fallback sender is a default sender that is automatically used if a message does not meet the conditions of any of the rules you have defined. This ensures that messages are always sent, even if they don’t match specific routing logic.

Can I use both user and API attributes in a single rule?

Yes, you can. The “Advance Customisation” rule type is designed for this purpose, allowing you to combine API attributes (sent with the message request) with user properties(from the user profile) to create highly specific routing logic.

How does the system handle multiple rules that could potentially match?

The system processes your routing rules in a top-down order. It executes the action for the very first rule that is fully matched and then stops. Because of this, the order of your rules is critical. You should arrange them from most specific to most general to ensure your intended logic is followed.

What is the reaction time for performance-based sender selection?

Sender performance is evaluated only after the first evaluation window of the rule is complete. The duration of this window depends on the configured rule (for example, 5 minutes). Until the first window is complete, the system continues to send messages through Sender 1, even if it does not meet the configured sending criteria. After that, the system evaluates sender performance every minute using a rolling window of the latest data. If Sender 1 meets the sending criteria, the system continues to use it; otherwise, it switches to the next sender. For example, if the rule starts at 12:00 PM, performance is not evaluated between 12:00 PM and 12:05 PM, and messages are sent through Sender 1. At 12:06 PM, the system evaluates performance for the period from 12:01 PM to 12:06 PM, and at 12:07 PM, it evaluates the period from 12:02 PM to 12:07 PM.

​

Next Steps

1. Create Alerts
2. Alert Analytics