This article talks about the anatomy of how a mobile in-app campaign and an on-site messaging campaign are delivered to your user. Each section below talks about the dependencies and configurations that affect the delivery of these messages.
Below are some of the common modules across Mobile InApps and On-site Messaging Campaigns that are important to note for the campaign delivery and rendering on the end user's device.
The active mobile in-app and on-site messaging campaigns are delivered to the SDK for rendering when the user opens the app. This sync is tried only once every 15 minutes as long as the app is in the foreground. Once a campaign is delivered to the SDK, it will be shown as soon as the trigger action is performed by the user provided the other campaign conditions like display controls and delivery controls are satisfied.
While creating a mobile in-app campaign or an on-site messaging campaign, you can choose to target all users or specify filters to select the audience you want to target.
When selection is All Users:
These campaigns will be delivered to all users, even the ones who are opening your app for the first time.
When selection is Customers that satisfy the filters
When the campaign starts at the scheduled time, the filter conditions are evaluated and the users who satisfy the filter conditions are evaluated by running the segmentation query. This list of users is maintained on the MoEngage side and when one of the users opens the app/website, the campaign is delivered to the SDK.
Few things to note for Segmented Campaigns -
- Campaign Segments are only evaluated in real-time for user attribute segments. Segments having events and event attributes are evaluated frequently for new users to move into your campaign segment list and start seeing the campaign. The frequency of segment evaluation can vary from 30 minutes to a few hours, based on the campaign type. The frequency is configurable.
- If at the time of the campaign start, your user is not a part of the segment list, you may not see the campaign for up to 6 hours due to the refresh cycle.
- Even after a user becomes a part of the campaign segment, it may still take about 15 more minutes for the SDK sync to happen and for the campaign to be rendered on the app/website.
The Trigger Action is used to actually fetch the campaign payload including the template, personalized properties of the template and render the in-app/on-site message on the app/website.
Trigger Actions for Mobile In-Apps
The user can select one of the below two trigger actions for creating Mobile InApp Campaigns.
- App Open: These campaigns are triggered immediately when the app or any screen is launched by the user.
- Custom Event: These campaigns are triggered immediately when the custom event is tracked on the SDK. Please note that only the events which are tracked from the respective Android / iOS SDK can be used as trigger actions for the Mobile InApp Campaigns.
Trigger Actions for On-site Messaging
The user can select one of the below two trigger actions for creating On-site Messaging Campaigns
- Page Load: These campaigns are triggered immediately on Page Load unless a value is provided for After Delay or After Scroll in which case the campaigns are triggered after the conditions are met.
- Custom Event: These campaigns are triggered immediately when the custom event is tracked on the SDK. Please note that only the events which are tracked on the web SDK can be used as trigger actions for On-site Messaging Campaigns.
- Exit Intent: These campaigns are triggered when the user is about the leave the website. For more information on exit intent, please refer to this article
Few things to note for Trigger Action:
- For Trigger Actions, only the actions generated on the same device and tracked by the MoEngage SDK are supported. Events tracked from S2S or generated by MoEngage internally on the server side like App / Site Opened, Device Uninstall, Device ReInstall or User ReInstall are not supported.
- The actual campaign template is fetched in real-time as soon as the trigger action is detected by the SDK. We do not wait for the event to be processed to fetch the campaign template from MoEngage servers to keep the rendering real-time.
- In the case of multiple campaigns with the same trigger action, only 1 campaign is selected by the SDK to be shown on the mobile app or website.
When there are multiple campaigns that have the same trigger action, in this case, we will make use of the Campaign Priority. Only the campaign with the highest priority will be displayed each time the trigger action is executed.
In case two campaigns have the same trigger action and the same priority, the campaign which was recently created will be shown.
Delivery Controls are used to control your in-app and on-site messages from appearing too frequently on your app and website. We have the below delivery controls in place right now -
- Maximum times to show message ever: This will restrict your campaign to be shown for a maximum number of times as defined during campaign creation.
- Minimum delay between 2 messages of this campaign: This will prevent your campaign from being shown frequently if the user executes the trigger action multiple times within a short time window.
- Ignore Global Delay between 2 On-site Messaging campaigns: Global Delay will prevent your user from seeing too many in-app/on-site campaigns within a specific time window. Check this to not consider global delay for this specific campaign.
- Auto Dismiss message after: This will dismiss the in-apps after the defined auto-dismiss time so that it does not bother the user.
Few things to note around Delivery Controls
- Delivery controls are applicable at a device level and hence for one user who has logged in with the same user unique id on two different devices, the delivery controls will be applied separately.
- For User 1 who is logged in on an Android device and an iOS device, the mobile in-app campaign will be shown for 2 times on each device individually.
- If the user logs out or clears the device cache, the delivery controls are reset and the user will be evaluated for the delivery controls from the beginning after this logout/cache clears.
- Please note that for an OSM campaign, there is a default behavior that OSM campaigns do not show up on the same page more than once. The campaign will be shown on the next reload or on another page.
Campaign Scheduling and First-Time Sync
Once started, for the campaign to start getting displayed, below are the dependencies -
- Once the campaign starts, the segment gets evaluated. Depending on the customer and the customer data we are scanning for the query, it may take around 15 minutes on average for the segmentation query to return a list of user ids for whom the campaign can be delivered.
- After Segmentation, the campaign will only be delivered to the SDK when the user opens the app/website. Please also note that the SDK sync happens only once in 15 minutes and hence it may take more time for the campaign to be delivered to the SDK if the previous sync happened within the last 15 minutes.
- A campaign is personalized when the user executes the trigger action and a campaign is selected for rendering by the SDK. Once done, the SDK will fetch the campaign template from MoEngage. During this activity, we will send a personalized template to the SDK.
- In case of personalization failure, the campaign will not be rendered if no fallback is provided in the campaign. Any other campaign will not be attempted thereafter in case of personalization failure hence it is always a best practice to add fallbacks for personalized in-app/on-site messaging campaigns.
- Internet Connectivity plays a crucial role in mobile in-app and on-site messaging campaign rendering. Poor internet connectivity may delay the campaign rendering by delaying the template fetch from MoEngage, image download delays, or failures.
- If the image download fails, the mobile in-app campaign will not be rendered at all on the mobile app.
Data Flow Diagram of how In-App and On-site Campaigns Work
SDK Integration for Mobile In-Apps:
SDK Version Dependency for Mobile InApps:
Below are some of the features that are only supported for specific SDK Versions
|Mobile In-App Feature
|Supported on Android SDK Version greater than
|Supported on iOS SDK Version greater than
|Ignore Global Delay
|Allowing users to give a half-star rating
|More than 5 stars in the rating template
|Action -> SMS
|Action -> Custom Action
|Action -> Track Event with Event Attribute
Please note that there is no SDK Integration required for On-site Messaging and there are no SDK Version dependent features for On-site Messaging either.