How we developed our push notification system (and why)
Without push-notifications today, probably, no mobile application can do. The market already has a lot of ready-made solutions to this important task. But, as is usually the case, if you want to do something well, you have to do it yourself. In this article, we asked Denis Borovikov, a UBANK developer, to tell about his experience in creating a mobile push notification system for UBANK and share tips for those who want to solve the same problem.
Among the existing cloud systems push-mail can be noted services such as Infobip , Jeapie , Pushwoosh , Urban Airship . They have a lot in common: all of them are not cross-platform, they allow you to send pushes taking into account the time zone, make mailings on a schedule, and also give statistics.
It sounds good, but when you delve into the details, you know: it's like ready-made dinners. I bought a frozen convenience food, put it in the microwave - I got an edible dish at the exit. Filled stomach, but without pleasure.
')
Carl lender
For UBANK, the main disadvantage of all these cloud solutions is that they can only push the entire customer base at once. And we wanted to be able to break the audience into groups and send each one a different message.
After a little research, I left the thought of ready-made solutions. Theoretically, some of them can be used as an addition. For example, when we need to support more platforms (add Windows Phone and Web), we will send push through the cloud, rather than directly to APNS and GCM. But so far all this is not very interesting to us.
The UBANK mailing system developed by me is a separate payment application module written in Scala. It took me about two months to develop it. It could have been done faster, but I had many parallel tasks.
Push system has its own MongoDB database. It stores the history of each newsletter. In total, these are tens of millions of records - we didn’t want to litter the main application base with them.
The operation of the module does not affect the main system. Therefore, we can test changes (for example, turn off or restart the newsletter). The main application will not be affected.
The logic of the module is as follows: periodically, with a specified interval, a request is launched, users are selected from the base of the main application to whom they need to send a push (in accordance with the rules we have invented).
As we have already told in the previous article , our fluffs, with different content, come to three groups of clients. The first group is those who have registered, but never used the service. The second - users who have ever made one payment, and then stopped using UBANK. The third is the people who used the application, but the last three months have not opened it.
Sooner or later, some of them would fall into the third group. But we realized that in some cases, a reminder after three months is too late for them. And it is not a sin to remind oneself a little earlier.
In general, when developing the criteria for selecting recipients for each mailing, you need to measure seven times before cutting. The more jewelery you will address the audience, the higher the exhaust will be.
janwillemsen
But to determine who, in principle, needs to send a push, is one thing. Understanding how and when to do it is another.
The rules, to whom and how we send the push, were formed gradually. The main ones are: the frequency of shipment (once a week), the maximum number of shipments (not more than five pieces to one person). We also do not send the flutes at night.
We analyzed the time zones in which our users live, and it turned out that the overwhelming majority live in the European part of Russia, so we chose these hours for distribution when almost everyone has a day. When there are more users in other regions, thanks to filtering, we can easily make geo-referencing by time zones.
In order not to spam people, you need to develop a system of constant verification of the user, whether he falls under our criteria or not. For example, if we sent a push to a user who had not paid a long time, and he paid, then our goal is fulfilled - do not annoy him and send notifications to him again.
It should also not forget about manual control and provide for the ability to send pushy, not only on schedule, but whenever you want. Manual sending is useful for test mailings when you want to first test the system on a small sample of users.
It is important for us to track the statistics of key indicators for each mailing list. Therefore, we in UBANK save the history of each of them in order to be able to evaluate the effectiveness of push.
If a person tied a card, made a purchase, all this information is automatically checked once an hour and sent to APNS or GCM, depending on whether the client is sitting on Android or iOS.
To speed up the process, we use batch sending. When sending to GCM, do not forget, by the way, to set the delay_while_idle sending parameter to true - it says that you don’t need to deliver a push to the user if the device is not active.
Our push system has a web interface. The dynamics of all our key indicators in the web interface is displayed in the form of graphs and charts.
Web interface and graphics are used for general quality assessment. But we also have export to Excel. Marketers naturally do all the calculations for each group there.
Analyze the results of each test distribution and make adjustments. The more information you have about users, the more effective your mailing will be.
We monitor the behavior of our users through the server - and thanks to this, we know about each client whether he downloaded the application or whether it was preinstalled, we know the version of its application, the version of the operating system of the smartphone, the device model and the user's time zone. We pull out all the statistics that are interesting for marketing and save on the server.
I advise all developers involved in pushing to start making mailings in small portions.
Having launched our system for the very first time, we sent pushups to UBANK to a large number of target groups at once. Many immediately responded and simultaneously entered the application.
The hamster factor
To avoid such incidents, we now set up the work of the system so that during the day it sends out every hour several thousand messages, and does not push the entire database in one sitting.
Nothing works as well as a bicycle invented by itself. Own development provides such opportunities that never provide a ready-made solution. At least, that is the reality with push notifications.
Of course, we plan to develop this system. Now our task is to increase the effectiveness of mailing. To do this, we want to develop a new type of notification, which, firstly, will be not just text, but with pictures, and secondly, they will send users to the landing pages immediately, and not just to the application.
But about this, perhaps, another time.
SEMI-FINISHED PRODUCTS NOT FOR US
Among the existing cloud systems push-mail can be noted services such as Infobip , Jeapie , Pushwoosh , Urban Airship . They have a lot in common: all of them are not cross-platform, they allow you to send pushes taking into account the time zone, make mailings on a schedule, and also give statistics.
It sounds good, but when you delve into the details, you know: it's like ready-made dinners. I bought a frozen convenience food, put it in the microwave - I got an edible dish at the exit. Filled stomach, but without pleasure.
')
Carl lender
For UBANK, the main disadvantage of all these cloud solutions is that they can only push the entire customer base at once. And we wanted to be able to break the audience into groups and send each one a different message.
I realized that it was necessary to make a system that would create mailing lists based on various criteria for user behavior. In this case, the purchase of semi-finished products can not do, you need to learn how to cook good homemade meals.
After a little research, I left the thought of ready-made solutions. Theoretically, some of them can be used as an addition. For example, when we need to support more platforms (add Windows Phone and Web), we will send push through the cloud, rather than directly to APNS and GCM. But so far all this is not very interesting to us.
INTELLIGENT POSTAGE
The UBANK mailing system developed by me is a separate payment application module written in Scala. It took me about two months to develop it. It could have been done faster, but I had many parallel tasks.
Push system has its own MongoDB database. It stores the history of each newsletter. In total, these are tens of millions of records - we didn’t want to litter the main application base with them.
The operation of the module does not affect the main system. Therefore, we can test changes (for example, turn off or restart the newsletter). The main application will not be affected.
The logic of the module is as follows: periodically, with a specified interval, a request is launched, users are selected from the base of the main application to whom they need to send a push (in accordance with the rules we have invented).
As we have already told in the previous article , our fluffs, with different content, come to three groups of clients. The first group is those who have registered, but never used the service. The second - users who have ever made one payment, and then stopped using UBANK. The third is the people who used the application, but the last three months have not opened it.
A little later, we realized that we had missed a fairly large audience of people who had not made payments during the month. Many of them did not fall into the second group, because they made more than one payment.
Sooner or later, some of them would fall into the third group. But we realized that in some cases, a reminder after three months is too late for them. And it is not a sin to remind oneself a little earlier.
In general, when developing the criteria for selecting recipients for each mailing, you need to measure seven times before cutting. The more jewelery you will address the audience, the higher the exhaust will be.
janwillemsen
MANUAL CONTROL
But to determine who, in principle, needs to send a push, is one thing. Understanding how and when to do it is another.
The rules, to whom and how we send the push, were formed gradually. The main ones are: the frequency of shipment (once a week), the maximum number of shipments (not more than five pieces to one person). We also do not send the flutes at night.
We analyzed the time zones in which our users live, and it turned out that the overwhelming majority live in the European part of Russia, so we chose these hours for distribution when almost everyone has a day. When there are more users in other regions, thanks to filtering, we can easily make geo-referencing by time zones.
In order not to spam people, you need to develop a system of constant verification of the user, whether he falls under our criteria or not. For example, if we sent a push to a user who had not paid a long time, and he paid, then our goal is fulfilled - do not annoy him and send notifications to him again.
It would be rather stupid of us to send him a message: “You haven’t paid anything for a long time!” But that’s exactly what would have happened if we had taken advantage of a ready-made solution: the push would continue to be sent with a specified frequency.
It should also not forget about manual control and provide for the ability to send pushy, not only on schedule, but whenever you want. Manual sending is useful for test mailings when you want to first test the system on a small sample of users.
SHIP US DIGITAL, PLEASE
It is important for us to track the statistics of key indicators for each mailing list. Therefore, we in UBANK save the history of each of them in order to be able to evaluate the effectiveness of push.
If a person tied a card, made a purchase, all this information is automatically checked once an hour and sent to APNS or GCM, depending on whether the client is sitting on Android or iOS.
To speed up the process, we use batch sending. When sending to GCM, do not forget, by the way, to set the delay_while_idle sending parameter to true - it says that you don’t need to deliver a push to the user if the device is not active.
Our push system has a web interface. The dynamics of all our key indicators in the web interface is displayed in the form of graphs and charts.
Web interface and graphics are used for general quality assessment. But we also have export to Excel. Marketers naturally do all the calculations for each group there.
Analyze the results of each test distribution and make adjustments. The more information you have about users, the more effective your mailing will be.
We monitor the behavior of our users through the server - and thanks to this, we know about each client whether he downloaded the application or whether it was preinstalled, we know the version of its application, the version of the operating system of the smartphone, the device model and the user's time zone. We pull out all the statistics that are interesting for marketing and save on the server.
YOUR PORTION, SIR
I advise all developers involved in pushing to start making mailings in small portions.
Having launched our system for the very first time, we sent pushups to UBANK to a large number of target groups at once. Many immediately responded and simultaneously entered the application.
We did not expect such a high conversion. Our server could not withstand this load and hang.
The hamster factor
To avoid such incidents, we now set up the work of the system so that during the day it sends out every hour several thousand messages, and does not push the entire database in one sitting.
Nothing works as well as a bicycle invented by itself. Own development provides such opportunities that never provide a ready-made solution. At least, that is the reality with push notifications.
Of course, we plan to develop this system. Now our task is to increase the effectiveness of mailing. To do this, we want to develop a new type of notification, which, firstly, will be not just text, but with pictures, and secondly, they will send users to the landing pages immediately, and not just to the application.
But about this, perhaps, another time.
Source: https://habr.com/ru/post/241025/
All Articles