Talking about the "pitfalls" of the PUSH Service

Talking about the "pitfalls" of the PUSH Service

Talking about the pitfalls of the PUSH Service"

As the mobile Internet industry develops more and more mature, various development tools and standardized solutions are rapidly reducing the development cost of Internet products. The push service has become a standard service in mobile development. As the only way for businesses to actively touch users, the PUSH Service has extraordinary significance for apps to pull new, pull live, direct traffic, and keep live.

Rangoose, as a product manager who has been fighting for "technical customer service" for many years, I would like to say that for the PUSH Service, there are many things you don't know ~~

Next, I will take Xiaomi push as an example. I will briefly talk to developers (Product/operation personnel) about the most concealed and difficult pitfalls I have ever seen when connecting with various developers.

1. Start of everything: device registration

The first step for all push services is to register devices. In fact, the reason and purpose are obvious, because push itself is a point-to-point behavior, each device's client needs to establish an independent persistent connection with the server for sending and receiving messages. Therefore, the PUSH Service must mark each device.

The registration interfaces of various push services are different, but the two interfaces are the same:

1. All interfaces are client interfaces.

2. After the API is called, a unique ID of the per app & per device is generated.

Take Xiaomi push as an example. The client registration and push interface is called registerPush. After successful registration, a regID is generated. regID is globally unique in the push system. mipush uses a complex encryption algorithm, make sure that each app is different on each device.

After introducing the background knowledge, let's talk about the pitfalls hidden in the seemingly simplest and most basic action of registering a device: the timing of device registration.

Because pushSDK requires a client engineer to manually integrate it into the app, The registerPush method also needs to be called by the client to complete registration. Therefore, the timing of registration is very important.

So from the product level, how can we design the time for registration push?

Different products have different business forms. Therefore, it is difficult to summarize a clear rule to instruct users to register for push. However, when designing the use logic of the push, each product manager must consider this point to the front, understand the timing of app registration push, and decide the time of registration push based on the business logic. So as not to bury the "shengheng" for future push ".

Here is a simple example:

The product logic of a live video app has the following restriction: The content can be viewed only after login. That is, logon is a forced action.

At this time, what time should I register? Before or after logon?

In fact, there is no standard answer to this question. We need to design it through the business logic. If the push system is designed based on an account and can only have an account after logon, it sounds reasonable to register and push the system after login. users who have not logged in do not serve as their own push targets; if the push is not based on an account but on a device that is not logged on in time, you also want to receive the PUSH message. The registration time should be before the user logon. That is, the app is opened by the user to call up push.

2. Do not log out!

Generally, the PUSH Service provides two interfaces, registerPush and unregisterPush, which are both client capabilities. It is used to enable and disable the push function. Note that the previously registered device ID (regID) becomes invalid after the logout interface is called and cannot be used again. A new device ID is generated even if you register the device again.

Therefore, registration is irreversible and only applicable to scenarios where the PUSH Service needs to be completely terminated.

What are the risks if the registration and cancellation interfaces are frequently called?

Let's take another example:

Take the live video app as an example. If the user logs out, messages are no longer pushed to the device. The client logic is: after the user logs on, the registerPush interface is called; after the user logs off, the unregisterPush interface is called. According to the above behavior, a new regID is generated each time the user logs on and out. This behavior directly leads to an increasing number of invalid regids. The push ID system becomes bloated and complicated.

Therefore, if you only want to temporarily stop pushing or disable pushing capabilities. Other methods should be used, rather than directly deregistering the push. Almost all of them provide APIs to suspend pushing.

Take mipush as an example:

The Xiaomi push client SDK provides two methods to control the use of push or resume use.

1. Set the push time (setAcceptTime): in this way, you can freely control the time that the device allows to receive the push every day (-) to stop/resume pushing. Click the link for details

For example, if you do not want to receive the push at night, you can select the push time.

2 enable/disablePush: Unlike the above method, the persistent connection is not closed after acceptTime is set. However, after disablepush is set, the persistent connection of the device is also disconnected, and only the validity of the regID is retained. Click the link for details

For example, in some cases, the method is used to save the power of the device. If you want to disconnect the persistent connection but retain the push capability, you can use this method.

3. Correct Understanding of delivery rate

The delivery rate is one of the data indicators that every developer is most concerned about. It is also a key indicator for measuring the unreliable PUSH Service.

What is the correct way to open the delivery rate? I will use Xiaomi push as an example to explain this problem ~

The following describes how to calculate the delivery rate of the PUSH Service:

The numerator is easy to understand, that is, the number of devices actually delivered by this push.

The denominator is the number of valid devices covered by this push request. If the target object is selected as all users, the denominator is the number of valid devices that have activated the PUSH Service in history; if the tag is selected, the denominator is the number of valid devices that have subscribed to this tag in history. If the number is selected by alias or regID, then the denominator is all valid aliases or regids requested. The validity of a device is determined by the following rules:

1. Call unregisterPush,

2. the user actively uninstalls the package,

3 if you have not established a connection with the Xiaomi server for more than three months, the device will be invalidated.

4. failed to set alias

According to this calculation method, there are several factors that affect the delivery rate:

1. Application retention rate.

Devices that have uninstalled the app cannot be pushed. However, according to the current calculation method, many unmounted devices (especially) will be included in the denominator (planned Push number.

2. Networking of the device where the application is located.

If the device is not connected to IOT platform during the message validity period, the message cannot be delivered, but is also included in the denominator.

3. Message validity period.

The shorter the validity period, the fewer devices on the Intranet, and the lower the delivery rate.

4. Select the target device.

If you select a full user, the delivery rate is certainly lower than extracting the target device accurately based on the user's network conditions (for example, selecting a user who has opened the application within 7 days.

4. "shenkeng" of APNs"

As a push service with a pursuit and attitude, supporting the entire platform is a basic professional capability. However, in the face of Apple's God-like vendor, the platform of the ox-and-the-ox-cross has to bow to the ears and follow the regulations of others.

Companies that provide push services on the market will basically adopt the same approach when facing Apple:

Integrate APNs (Apple Push icationicationservice)

APNs is an official PUSH Service provided by Apple. Due to the closed-source ecosystem of apple, all developers can only use this method to implement push capabilities, which is even better. At the same time, for Android and iOS (including WinPhone), the definitions and usage of the PUSH Service server interface are consistent. In the process of using the service logic, client differences can be transparent.

I don't want to talk about APNs here today. I just want to talk about the Great apple ......

However, those who have been engaged in iOS development have basically faced the same challenge: unable to obtain the unique identifier of the device. The DeviceToken that uniquely identifies a device also changes frequently.

This is actually a good explanation: If developers can uniquely identify the device, there will be a great privacy risk for users.

Developers may not be deeply touched. However, for the PUSH Service, goose is almost crazy: unable to get the unique identifier of the device. How should we push it!

Mipush has made many efforts and attempts in this regard, including using the key chain capability of iOS to store device identifiers ...... Rangoose, I recently saw a piece of news like this:

Http://mp.weixin.qq.com? _ Biz = MzI5MjEzNzA1MA =& mid = 2650264371 & idx = 1 & sn = Hangzhou & chksm = Hangzhou & mpshare = 1 & scene = 1 & srcid = 0314yXPCqwzN26Z7kuKmOVIO # rd

Reposted from: MrPeak grocery store

In short, getting the unique identifier has basically been wiped out by Apple ...... As an ethical PUSH Service, I still want to swear ......

In any case, we have to go through the road and continue to develop our products. We believe there will be better solutions to help developers solve these problems ~

The above is my experience in pushing, hoping to provide you with a little help ~

Xiaomi Open Platform official link: http://dev.xiaomi.com? Hmsr = it168 % E5 % 8D % 9A % E5 % AE % A2 % E9 % A2 % 91% E9 % 81% 93 & hmpl = & hmcu = & hmkw = & hmci =

Official QQ chat group: 398616987
Want to know more?
So follow us!