The push to all users service is a group of RESTful APIs implemented based on the IM communication architecture. This service is used to meet message push requirements of the application, including pushing messages to all users, pushing messages by tag, and pushing messages by attribute. Clients can receive pushed messages by using the online and offline push features (Android background notifications and APNs) of the SDK. The group push service also supports offline storage of messages, helping operators achieve their operational goals more efficiently.
- An account can receive messages pushed to all users only after it has been logged in to or manually imported.
- The feature of pushing to all users is available only to users with Flagship edition accounts. See Configuration Change Ticket to apply for this feature. The feature will be enabled 48 hours after your application is approved.
The group push service is provided based on the client IM SDK and IM backend, which guarantee messaging capabilities and system availability.
Example 1: a game application plans to provide special offers on Christmas and needs to push the notification to all users. In this case, the group push service can be used to boost efficiency. In addition, to inform more users of this promotion, you can set the offline message retention period. In this way, even if some users are not online when the message is pushed, they can still receive the message when they go online within this offline retention period. This improves the quality and effectiveness of the promotion.
Example 2: a livestreaming application plans to launch a large-scale live marketing activity and needs to push the notification to all users. In this case, you can push the notification to all users starting 7 days before the activity and set the offline message retention period to 7 days. When the activity starts, you can push the notification to all users again, without specifying an offline retention period. In this way, all online users can receive the notification and join the live room, attracting more users into the live room.
For example, a financial product plans to push a financial planning service to users who follow "stock A" or "stock B". In this case, you can push messages by tag:
For example, users of a game are classified into non-members, ordinary members, gold members, and platinum members. Assume the operator plans to push an activity to platinum members in Shenzhen. In this case, they can push the message by attribute:
In this scenario, pushing by attribute is preferable to pushing by tag. If you push the message by tag, when the city of the user changes from Shenzhen to Guangzhou, the application needs to delete the "Shenzhen" tag of the user and then add the "Guangzhou" tag, which involves two API calls. However, if you push the message by attribute, only one API call is required to modify the city attribute of the user.