MoEngage Flows is a series of Cross-channel (across the channels viz. Email, Push, SMS etc.) Lifecycle campaigns to be sent to your customers basis their actions/in-actions on your app/website.
Flows have been divided in four key pieces:
Entry trigger condition can be configured by clicking on Add Entry Condition block.
An entry trigger condition determines who will enter into the MoEngage flow. All the users who satisfy the entry condition will enter the flow. Entry condition can be a combination of user properties criteria along with behavioral criteria.
For the example below, users who have "Last known city" as Bangalore and who have executed App/Site Opened and haven’t executed Made Purchase with-in 2 hours after the IF Action will enter the journey.
Currently the supported actions are:
- Send Push
- Send Email
- Send Connector
When a user comes to this stage, a push will be sent to him/her if they have active devices present against them. Currently marketers should be able to send push to Android & iOS devices.
Marketers can set the new push message (personalize-able on User attributes) or import the message from an existing campaign using the campaign id of that campaign.
When a user comes to this stage, an email will be sent to him/her if they have active email subscription present against him/her.
Marketers can set the new email message (personalize-able on User attributes) or import the message from an existing campaign using the campaign id of that campaign.
If used in Flow, when a user comes to this stage, a connector request will be sent as per user data to the chosen Connector End-point. You can use connectors to do a lot of tasks as mentioned here.
Conditions are evaluated when users arrive to the state. Conditions are always evaluated within a certain time range starting from the time when user moved to this stage from previous stage to the time set by you in condition.
Has done event condition
Evaluates whether user has done a certain event/action (or a combination of them) basis which marketer may direct them to different treatments/paths in the Flow.
Say your user came to Event Condition evaluation at time T (after viewing a Product page) and you want to track whether your user has Added the product to the cart and made the purchase within 2 hours. The system will check for next two hours if the condition is fulfilled or not.
If yes, it will immediately move to the Yes branch. If condition is not fulfilled at the end of two hours, it will move to No branch. Marketers can accordingly decide the subsequent Flow paths.
In the example above, the evaluation was being done since user reached the Event Condition evaluation. For certain use cases, marketers might want to check whether some actions have been taken since their users have entered the journey. Marketers can use the option accordingly.
The example below will check if the actions are taken in the past since the user entered the journey. The system will further wait for 2 hours if the condition is not being satisfied. After two hours, it will move to Yes/No branch as per the current status.
Check Attribute condition
Evaluates whether specific user attribute (or a combination of them) is set as the required value. Can be used when marketers set tags/user property when user fulfills a certain condition in their backend systems.
Wait time period will depend on :
- If it is an existing attribute for which value is being checked
- If it is new attribute that is being added to user profile basis action on sent communication
For case 1, it can be kept minimal while for case 2, it should be checked with-in expected time in which value is being set.
- Has received push notification (Valid only for Android) - Checks whether the user has received the push notification. The condition is synonymous to Impression in Android Push.
- Has dismissed push notification (Valid only for Android) - Checks whether the user has dismissed the received push notification.
- Has clicked push notification - Checks whether the user has clicked the received push notification.
- Has opened email message - Checks whether the user has opened the email message sent to him/her
- Has clicked email message - Checks whether the user has clicked any link in the email message sent to him/her
- Has unsubscribed email - Checks whether the targeted user has unsubscribed from the email communication
- On hard bounce - Checks whether the email sent to the targeted user was hard-bounced
- On email drop - Checks whether the targeted email for user was not sent because of previous hard bounces/ marked spam/complaints
- On email spam - Checks whether the email sent to the targeted user was marked-as-spam
Control blocks are placed in journeys to control the flow i.e. to add required time delays etc.
Add Wait time
The system waits for the configured time before taking the succeeding action.
Note: System does not evaluate any condition during this time nor take any action. It is generally used to delay the communication by days or hours once user becomes eligible to receive any communication. Using it before event condition evaluation might be logically incorrect as system will not evaluate the user events during that time.