# Create Triggered Tasks

Triggered push is based on real-time collection of user behavior or status data, real-time calculation of players who meet the specified behavioral rule conditions, and push automatically. Compared with timed or manual push, triggered push not need to be set a fixed push time, but combined with player behavior scenarios to push appropriate content.

Usage scenarios such as:

After the player has failed 5 times, immediately push the combat power improvement package to the player;
When the player unlocks the time-limited package but does not purchase the package within "T" time, remind the player with a message that the reward will be offline soon, please purchase as soon as possible, etc.

Processing flow:

# Select push type

Currently four trigger types are supported: Complete A, Completed A then B, Completed A but not B and Custom.

# 1.1 Trigger - Completed A

Push to users when they complete the specified behavior event. For example, when the player reaches level 50, trigger the level 50 limited-time gift package.

Trigger Rules

Push after the user have accumulatively completed event A daily, weekly, monthly or in a custom period.
Support multiple event trigger rules and event properties filtering. Event properties support tracked properties, preset properties, and custom properties (dimension properties are not supported for now).
Customize the start and end time of a day, a week, or a month. For example, consider 5 am today to 5 am tomorrow as a custom day. Or consider 5 am this Wednesday to 5 am next Wednesday as a custom week.
Support pushing immediately after triggering the conditions, or delay pushes by x minutes/hours/days after triggering the conditions. A maximum delay of 30 days is supported.

# 1.2 Trigger - Completed A then B

After the user completes the specified behavior A and also completes behavior B within a specified period of time, push will be executed. For example, when a player browses the mall and completes a product purchase within 30 minutes, the item consumption instruction will be triggered.

Trigger Rules

Support push reach after completing A and accumulatively completing B in a subsequent period of time within the selected start and end time.
Support multiple event trigger rules and event properties filtering. Event properties support tracked properties, preset properties, and custom properties (dimension properties are not supported for now).
Support setting the interval between events A and B in x minutes/hour/day, with a maximum limit of 30 days.
Support pushing immediately after triggering the conditions, or delay pushes by x minutes/hours/days after triggering the conditions. A maximum delay of 30 days is supported.

# 1.3 Trigger - Completed A but not B

After the user completes the specified action A and fails to complete action B within a certain period of time, push will be triggered. For example, if a player fails to complete the purchase of a limited-time gift package within 5.5 hours, a push message will be triggered to remind them that the gift package is about to expire.

Trigger Rules

Accumulatively completed A in a day, a week, a month, or in a period within the selected start and end time, and push after period of time without having accumulatively completed B.
Support multiple event trigger rules and event properties filtering. Event properties support tracked properties, preset properties, and custom properties (dimension properties are not supported for now).
The interval between events A and B supports x minutes/hour/day, with a maximum limit of 30 days.
Support pushing immediately after triggering the conditions, or delay pushes by x minutes/hours/days after triggering the conditions. A maximum delay of 30 days is supported.

# 1.4 Trigger - Custom

When certain scenarios need to be met, you can use custom triggers. It supports pushing messages to users who meet the trigger scenes within the selected time range.

Custom triggers do not rely on data logs. The game server can deliver target information to the TE operation module through the interface, and the TE operation module implements message push. For example, push the messgages to remind the players to go online when the player's stamina is full (the trigger of this reminder is not triggered by the user behavior log).

The access mode can refer to:

Trigger Rules

Pushing will be performed after the trigger scenes are completed within the selected start and end time.
Support pushing immediately after triggering the scenes, or delay pushes by x minutes/hours/days after triggering the scenes. A maximum delay of 30 days is supported.

# 1.4.1 Scene Configuration Instructions

The creation and usage process of the scenes used in custom triggers:

You can select an existing scenario or create a new one in the trigger rule

You can create a new scene by filling in the scene name, scene ID, select the entity ID of the push, and use the scene directly in the custom trigger.

Tip: One scene can only be used for one operation task. Therefore, when a scene is occupied by an operation task in progress, the drop-down list will be disabled for that scene.

# Push control

# 2.1 Timeout Control

Due to the possibility of unstable situations such as delay and squeezing in data reporting, there may be a certain time difference between the "trigger calculation completion time" and the "player behavior occurrence time". To avoid excessive delay, you can choose to enable timeout control. After enabling timeout control, the push of timeout arrival will be automatically cancelled.

For example: The trigger rule is pushing immediately after a battle. If a player finishes the battle at 9:50, the data arrival time is 10 minutes late due to data compression on the reporting link, resulting in the actual push time of 10:00. If timeout control is enabled and set to 5 minutes, the maximum waiting time is 9:55, so this push will not be made to this player.

# 2.2 Task Entry Limits

We support limiting the maximum number of pushing that a single user can receive within the task schedule time through task entry limits control.

For example, we have an in-game activity that is updated weekly. Push is triggered once a player completes 50 or more battles per week. However, we also hope that the player will only receive one push a week. In this case, we can select " weekly " cumulative completion in the start and end time, and set the task entry limit to only accept one push per week per user.

# Select Audience

You can customise the audience or select all users to push as long as the trigger conditions are met.

# 3.1 Custom Audience

After events are triggered, you need to verify whether the triggered user is a target audience, and pushing messages will only be sent to those who meet the audience conditions. Target audience can be calculated in real-time, or updated hourly.

Real-time calculation

"Real-time calculate" refers to the real-time calculation of whether the user belongs to the target audience according to the current condition value after triggered.
If the audience conditions only use user properties and user cohorts that are "Real-time available", then the audience supports real-time calculation.
User property definitions or user cohort size determine whether they are "Real-time available".
- User properties: Dimension properties, or custom properties that include user tags and dimension properties, do not support real-time calculation.
- User cohorts: cohorts with size exceed the limit (default 200M) are not supported for real-time calculation.
If the custom audience uses cohorts, you can click "View rules" to view or modify the update frequency of the cohorts (by default, they are updated every 1 hour).

Scheduled Update

"Scheduled Update" means the target audience is calculated regularly at a specified calculation frequency. After triggered, the result of the latest calculation is used to determine whether the user is the target audience or not.
When the target audience condition involves events, tags, dimension tables, or cohorts with size exceed a specified limit, only scheduled updates are supported.
You can click "View rules" to view or modify the update frequency of the audience condition (by default, they are updated every 1 hour).

Cohorts updating takes up a certain amount of computing resources, please combine with the business scenarios to choose the appropriate update frequency, to avoid unnecessary consumption of computing resources.

# 3.2 All users

After events are triggered, users will no longer be finely filtered. Pushing will be executed as long as the trigger conditions are met.

# Triggered tasks support A/B test

The trigger tasks support A/B split-flow experiments and horse-racing experiments. Refer to the section for more information：

# FAQ

Is there a maximum number of triggered tasks?

At present, a single project supports up to 30 triggered operation tasks. If you need to increase the upper limit of the number, you can contact the operation and maintenance to modify it.

What is the meaning of start and end time in triggerrules?

The start and end time is a time limit for completing event A. It can be understood that event A that does not occur within the start and end time is not included in the trigger calculation.

Why can'tthe operation task schedule be manually selected?

The task schedule represents the start and end time of the task. In the triggered tasks, due to the existence of the delayed push setting, the task schedule = the start and end time of event A + the interval time between events A and B + the delay time, which is automatically calculated.

For delayed pushes and event intervals, are days counted as natural days or 24 hours?

Days, hours, and minutes are all calculated in seconds, and delay of 1 day means delay of 24 hours, or 86400 seconds.

← Best Practices Operation Task Management →