Create triggered tasks (server-side)
Triggered push applies real-time calculation to user behavior or status data collected in real time to find players who meet the specified behavior rule conditions, and automatically pushes content to those players. Compared with Scheduled or Manual pushes, triggered pushes don't need a fixed push time. Instead, they push suitable content at the right moment based on player behavior.
Example scenarios:
- After a player fails a stage 5 times in total, immediately push a combat power boost gift pack to the player;
- When a player unlocks a limited-time gift pack but doesn't buy it within time "T", remind the player that the reward is about to go offline and to buy it soon.
End-to-end processing flow:
Entry: Go to Engage > Operation Tasks > Create task > Select the Channel Type > Webhook / Push Notification > Select a channel to open the operation task editing page.
1. Set push timing
Four trigger modes are currently supported: Completed A, Completed A then B, Completed A but not B, and Custom
-
Trigger rules can only use reported events. Custom events are not supported.
-
If the reported event you select is an updatable event or a first event, the triggered task doesn't process the data across reported events. The events go directly into the real-time calculation flow:
- Updatable events: For example, "Submit order" is an updatable event. The first submission has an order amount of 100, and a second report changes the order amount to 200. Trigger calculation treats them as two independent events, so the triggered calculation result is 300.
- First events: For example, "Device activation" is a first event. If device A reports the activation event twice, only 1 record is actually stored, but trigger calculation counts 2.
1.1 Trigger - Completed A
Pushes are sent after a user completes the specified behavior event or behavior sequence. For example, when a player reaches level 50, a level-50 limited-time gift pack is triggered.
1.1.1 Trigger rule — Accumulatively completed
Accumulatively completed: A push is triggered once when the user completes an event a cumulative number of times
Example: If you push a gift pack to users who have visited the store 5 or more times in total, a push is triggered each time the user visits for the 5th time, the 6th time, the 7th time, and so on.
- Within the selected start and end time, pushes can be sent after counting cumulative completions of a behavior, by day, week, month, or over the whole period
- Trigger rules based on multiple events are supported, as well as filters on behavior event properties
- You can customize daily, weekly, or monthly start and end times. For example, 5:00 to 5:00 the next day counts as one day, and Wednesday 5:00 to the next Wednesday 5:00 counts as one week
- Pushes can be sent immediately after the conditions are met, or with a delay of x minutes, hours, or days after the trigger. The maximum delay is 30 days
1.1.2 Trigger rule — Each time continuously completed
Each time continuously completed: A push is triggered each time the user consecutively completes an event multiple times within the task schedule without doing another event in between (you can set this with Add 'Have Not Done Between').
Example: Push a gift pack to users who fail to level up twice in a row within 2 hours without topping up in between
- Within the selected start and end time, pushes can be sent after counting each time the user consecutively completes the specified event multiple times, by day, week, month, or over the whole period
- Trigger rules based on multiple occurrences of a single event are supported, as well as filters on behavior event properties
- You can customize daily, weekly, or monthly start and end times. For example, 5:00 to 5:00 the next day counts as one day, and Wednesday 5:00 to the next Wednesday 5:00 counts as one week
- Pushes can be sent immediately after the conditions are met, or with a delay of x minutes, hours, or days after the trigger. The maximum delay is 30 days
1.1.3 Trigger rule — Each time completed in turn
Each time completed in turn: A push is triggered each time the user completes the specified behavior sequence in order
Example: Push a gift pack to users who complete "Log in - Gacha - Pay" in order within 2 hours
- Within the selected start and end time, pushes can be sent after counting each completion of the specified behavior sequence in order, by day, week, month, or over the whole period
- Trigger rules based on multiple events are supported, as well as filters on behavior event properties
- You can customize daily, weekly, or monthly start and end times. For example, 5:00 to 5:00 the next day counts as one day, and Wednesday 5:00 to the next Wednesday 5:00 counts as one week
- Pushes can be sent immediately after the conditions are met, or with a delay of x minutes, hours, or days after the trigger. The maximum delay is 30 days
1.2 Trigger - Completed A then B
Pushes are sent after a user completes the specified behavior event A and then also completes behavior event B within a specified period of time. For example, when a player browses the store (completes A) and completes a purchase (completes B) within 30 minutes, a guide to an item consumption event is triggered.
Trigger Rules
- Pushes can be sent after the user completes A within the selected start and end time and then completes B a cumulative number of times within a period afterward
- Trigger rules based on multiple events are supported, as well as filters on behavior event properties. Event properties can be tracked properties, preset properties, or custom properties (dimension table properties are not supported yet).
- The interval between events A and B can be x minutes, hours, or days, up to 30 days
- Pushes can be sent immediately after the conditions are met, or with a delay of x minutes, hours, or days after the conditions are met, up to 30 days
1.3 Trigger - Completed A but not B
Pushes are sent after a user completes the specified behavior A but doesn't complete behavior B within a period of time. For example, when a player gets a limited-time gift pack (completes A) and doesn't complete the purchase (doesn't complete B) within 5.5 hours, a push message is triggered to remind the player that the gift pack is about to expire.
1.3.1 Trigger rule — Accumulatively completed A but not B
- Pushes are sent after the user completes a behavior multiple times in total within the selected start and end time and then doesn't complete a behavior enough times in total to meet the set condition within a period of time
- Trigger rules based on multiple events are supported, as well as filters on behavior event properties
- The interval between completing A and B can be x minutes, hours, or days, up to 30 days
- For Completed A, you can customize daily, weekly, or monthly start and end times. For example, 5:00 to 5:00 the next day counts as one day, and Wednesday 5:00 to the next Wednesday 5:00 counts as one week
- Pushes can be sent immediately after the conditions are met, or with a delay of x minutes, hours, or days after the conditions are met, up to 30 days
1.3.2 Trigger rule — Each time continuously completed A but not B
Trigger Rules
- Pushes are sent after the user consecutively completes the specified event multiple times within the selected start and end time and then doesn't complete a behavior enough times in total to meet the set condition within a period of time
- Trigger rules based on multiple events are supported, as well as filters on behavior event properties
- The interval between completing A and B can be x minutes, hours, or days, up to 30 days
- For Completed A, you can customize daily, weekly, or monthly start and end times. For example, 5:00 to 5:00 the next day counts as one day, and Wednesday 5:00 to the next Wednesday 5:00 counts as one week
- Pushes can be sent immediately after the conditions are met, or with a delay of x minutes, hours, or days after the conditions are met, up to 30 days
1.3.3 Trigger rule — Each time completed A in turn but not B
Trigger Rules
- Pushes are sent after the user completes the specified behavior sequence in order within the selected start and end time and then doesn't complete a behavior enough times in total to meet the set condition within a period of time
- Trigger rules based on multiple events are supported, as well as filters on behavior event properties
- The interval between completing A and B can be x minutes, hours, or days, up to 30 days
- For Completed A, you can customize daily, weekly, or monthly start and end times. For example, 5:00 to 5:00 the next day counts as one day, and Wednesday 5:00 to the next Wednesday 5:00 counts as one week
- Pushes can be sent immediately after the conditions are met, or with a delay of x minutes, hours, or days after the conditions are met, up to 30 days
1.4 Trigger - Custom
When you need to meet specific trigger scenarios, you can integrate a custom trigger to reach users. Within the selected start and end time, pushes are sent to users who meet the Trigger Scene.
Custom triggers don't depend on data logs. Your game server can send target information to the AE Engage module through an API, and the Engage module then sends the message push. For example, you may need to push a login reminder to players when their stamina is full (this reminder's trigger doesn't come from behavior logs).
For how to integrate, see the Custom trigger integration guide
Trigger Rules
- Within the selected start and end time, pushes are sent after the conditions of the trigger scene are met
- Pushes can be sent immediately after the conditions are met, or with a delay of x minutes, hours, or days after the conditions are met, up to 30 days
1.4.1 Scene configuration
How to create and use scenes for custom triggers:
In the trigger rules, you can select an existing scene or create a new scene
To create a new scene, enter the Scene Name and Scene ID and select the push entity ID. You can then select it directly in the trigger.
Tip: Currently, a scene can be used by only one operation task, so when a scene is occupied by an operation task in progress, it's disabled in the drop-down list.
2. Push control
2.1 Timeout control
Because data reporting can be unstable, with delays or backlogs, there may be a time gap between the trigger calculation completion time and the time the player behavior occurred. To avoid too many late pushes, you can turn on timeout control. When timeout control is on, pushes that would arrive after the timeout are canceled automatically.
Example:
The trigger's push rule is: push immediately after a player finishes a battle. A player finishes a battle at 9:50, but because of a data backlog in the reporting pipeline, the data arrives 10 minutes late, so the actual push time is 10:00. If timeout control is on and set to 5 minutes, the latest allowed time is 9:55, so this push is not sent to the player.
2.2 Task entry limits
You can use Task Entry Limits to limit the maximum number of pushes a user receives within a period of time. You can choose:
- The maximum number of pushes a user can receive within the task schedule (for example, only once within the task schedule)
- The maximum number of pushes a user can receive within X days (a sliding window; for example, only once within 7 days means only once within the last 7*24 hours)
- The maximum number of pushes a user can receive within each X minutes, hours, days, weeks, or months (a rolling window; for example, once per week means only once within each calendar week)
For example, an in-game event updates weekly, and the trigger rule pushes a related item once a player has played the game mode more than 30 times in a week. If you also want each player to receive only 1 push per week, select Weekly cumulative completion in the start and end time, and in Task Entry Limits, set each user to receive at most 1 push Weekly. You can also customize the first day of the week.
3. Audience
You can customize the audience, or push to all users who meet the trigger conditions.
3.1 Custom audience
After a user behavior triggers the task, you need to determine whether the user belongs to the audience, and push only to users who meet the audience conditions. Depending on timeliness, the audience is either calculated in real time or updated hourly.
Real-time calculated audience
-
After the trigger, whether the user belongs to the audience is calculated in real time
-
The following conditions support real-time calculation:
- The audience conditions use only user properties and cohorts that Support Real-time Calculation
- User properties that support real-time calculation: properties whose definitions don't include user tags or dimension tables that are unavailable in real time
- User cohorts that support real-time calculation: cohorts whose size doesn't exceed the specified limit (2 million users by default)
-
If the audience conditions use a user cohort that supports real-time calculation, you can click Edit rule to change how often the cohort is updated (every 12 hours by default)
Scheduled audience calculation
- Scheduled Update means that the audience is recalculated on a schedule at the specified frequency. After a behavior triggers the task, whether the user belongs to the audience is determined based on the most recent calculation result.
- When the audience conditions involve events or tags, dimension tables that don't support real-time calculation, or cohorts that exceed the specified limit, only scheduled calculation is supported.
- You can click Edit rule to change how often the audience is updated (every 12 hours by default)
Cohort updates consume computing resources. Choose an update frequency that fits your business scenario to avoid unnecessary resource usage.
3.2 All users
Once the trigger conditions are met, users are not filtered further. The push is sent as long as the trigger conditions are met.
3.3 Estimate audience size
After you set the audience conditions, you can click Estimate to estimate the number of target users and assess how many users the operation task may reach.
To keep the estimate as close to the actual value as possible, the estimate counts target users who meet the audience conditions and whose push ID for the selected channel is not empty (that is, users who can actually receive the push).
4. Push configuration
4.1 Set up an A/B test
Triggered tasks support A/B split-flow tests and horse-racing tests. For more information, see A/B testing
4.2 Delivery caps
When multiple operation tasks use the same channel type (channel), you can limit the maximum number of pushes a single user receives from the same type of channel within a period of time, to avoid disturbing users too often.
4.3 Do not disturb control
Triggered tasks support Do Not Disturb Control, which you can customize as needed. Users don't receive push content during the do-not-disturb period.
- Do not disturb is off by default. When turned on, the default period is 22:00- 6:00
- The default timezone is the task timezone
5. Push content
Based on the selected channel, you can fill in suitable message content according to your operation strategy and insert user properties to personalize the copy. You can also run a send test right away to preview and confirm the push effect, and turn on delivery caps or set a task whitelist as needed.
5.1 Multi-language support
If your product is released globally, you can configure multiple language versions of the push content. When pushing, the language version is matched based on each user's language property. (To use multi-language features, configure the User Language Property in Settings - Localization Settings.)
In addition, to make configuration more efficient, when you add languages, the content entered for the default language is automatically synced to the content of the other languages.
5.2 Personalized content
You can insert user properties into the message content as needed to personalize the push. For example, if you insert the user nickname property into the message content, the message that each user receives will include their nickname.
5.3 Send test
Before you submit the task for approval, you can use Send Test to preview the push content of the operation task and make sure it's correct.
- Send tests can verify the push content and channel custom parameters
- If you insert user properties into the push content, the Default Value of each user property is used as the send test content
- Channel custom parameters use their Default Value as the push content. If there's no default value, you can enter the content you want to test
5.4 Use trigger values
When the push type is Trigger - Completed A, you can define the statistical value of the trigger condition, or an event property value at the time of the trigger, as a field value of the push content, enabling more refined operation strategies.
Example scenarios:
- When a player fails a level consecutively, carry the corresponding level ID and dynamically deliver the matching level difficulty (as shown in the figure above)
- In games, push discount coupons for the item types players click in the shop (for example, if a player prefers item types such as skins, heroes, pets, or weapons, push discount coupons for that item type, such as skin coupons or weapon coupons)
- Count the total amount of a resource a player has consumed, and dynamically deliver resource bundle content based on that amount
- In live streaming products, when a streamer a player follows goes live, carry the streamer's ID and build the final profile page URL from it in the push content, so the player can go directly to the streamer's page
6. Goal settings
A conversion is counted when a reached user completes the specified event behavior. Conversions are used to evaluate the effect of the operation task.
You can set one main goal and two secondary goals at the same time.
7. Metric settings
You can set metrics for performance after any reach node to help evaluate the operation effect.
For details, see Task performance analysis
8. Available data assets
| Key step | Available assets |
|---|---|
| Push timing |
|
| Audience |
|
| Push Content |
|
9. FAQ
-
Is there a limit on the number of triggered operation tasks?
Currently, each project supports up to 30 triggered operation tasks. To raise the limit, contact Ops to change it.
-
What does the start and end time in trigger rules mean?
The start and end time limits the time range of event A. Event A occurrences outside the start and end time are not counted in the trigger rule calculation.
-
Why can't I select the operation task schedule manually?
Task Schedule represents the start and end time of the task. Because triggered tasks have delayed push settings, the task schedule is calculated automatically: task schedule = start and end time of event A + interval between events A and B + delayed push time.
-
Is a day in delayed push and in the interval between events A and B a calendar day or 24 hours?
Days, hours, and minutes are all calculated in seconds. A delay of 1 day means a delay of 24 hours, that is, 86400 seconds.