How we developed our push notification system (and why)

    Probably no mobile application can do without push notifications today. There are already many ready-made solutions on the market for this critical task. But, as it usually happens, if you want to do something well, you have to do it yourself. In this article, we asked UBANK developer Denis Borovikov to talk about his experience in creating a mobile push notification system for UBANK and share tips for those who want to solve the same problem.

    SEMI-FINISHED PRODUCTS NOT FOR US


    Among the existing cloud push distribution systems, one can mention such services as Infobip , Jeapie , Pushwoosh , Urban Airship . They have a lot in common: all of them are not cross-platform, they allow you to send pushies taking into account the time zone, do scheduled mailings, and also give statistics.

    It sounds good, but when you delve into the details, you understand: it's like ready meals. I bought a frozen semi-finished product, put it in the microwave - I got an edible dish at the exit. My stomach was full, but without pleasure.


    Carl Lender

    For UBANK, the main drawback of all these cloud solutions is that they can push only the entire customer base at once. And we wanted to be able to break the audience into groups and send each of them different messages.

    I realized that we need to create a system that creates mailing lists based on various criteria for user behavior. In this case, purchased convenience foods can not do, you need to learn how to cook good homemade dinners.


    After a little research, I left the thought of ready-made solutions. Theoretically, one 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 pushies through the cloud, and not directly to APNS and GCM. But while all this is not very interesting to us.

    INTELLIGENT POSTMAIL


    The UBANK mailing system I developed 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.

    The push distribution system has its own MongoDB database. It stores the history of each newsletter. In total, these are tens of millions of records - we did not want to litter the main application base with them.

    The operation of the module does not affect the main system. Therefore, we can test the changes (for example, turn off or restart the newsletter). The main application will not be affected.

    The logic of the module is as follows: from time to time, a request is launched, users who need to send a push are selected from the base of the main application (in accordance with the rules we invented).

    As we have already said in a previous article , our pushies, with different contents, come in three groups of clients. The first group is those who passed registration, but did not use the service. The second - users who have ever made one payment, and then stopped using UBANK. The third - people who used the application, but the last three months did not open it.

    A little later, we realized that we had missed a rather significant audience of people who did not make payments within a 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’s not a sin to remind yourself a little earlier.

    In general, when developing criteria for selecting recipients for each mailing, you need to measure seven times before cutting. The more jewelry you handle with your audience, the higher the useful exhaust.


    janwillemsen

    MANUAL CONTROL


    But to determine to whom in principle you need to send a push is one thing. Understanding how and when to do this is different.

    The rules to whom and how we send pushies were formed gradually. The main ones: the frequency of sending (once a week), the maximum number of shipments (no more than five pieces to one person). We also do not send pushy at night.

    We analyzed what time zones our users live in, and it turned out that the vast majority lives in the European part of Russia, so we chose such a watch for distribution when almost everyone has a day. When there will be 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 for constantly checking the user whether he falls under our criteria or not. For example, if we sent a push to a user who did not pay for a long time, and he paid, then our goal is fulfilled - do not annoy him and send him notifications again.

    It would be rather stupid of us to send him a message: “You haven’t paid something for a long time!” But that’s exactly what would happen if we used a ready-made solution: the push would continue to be sent at a given frequency.


    At the same time, one should not forget about manual control and provide for the ability to send pushies not only on schedule, but also when you want. Manual sending is useful for trial mailings, when you want to first test the system on a small sample of users.

    SHIP US NUMBERS, PLEASE


    It is important for us to monitor the statistics of key indicators for each newsletter. Therefore, we at UBANK keep a history of each of them in order to be able to evaluate the effectiveness of the push.

    Whether a person tied a card, whether he made a purchase - all this information is automatically checked once an hour and sent to APNS or GCM, depending on whether the client is 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 send parameter delay_while_idle to true - it says that you do not need to deliver push to the user if the device is not active.

    Our push distribution system has a web interface. Dynamics for all our key indicators in the web interface is displayed in the form of graphs and charts.

    The web interface and graphics are used for overall quality assessment. But we also have a discharge to Excel. Marketers naturally do all the calculations for each group there.

    Analyze the results of each test mailing and make adjustments. The more user information you have, the more effective your newsletter will be.

    We track the behavior of our users through the server - and thanks to this, we know about each client whether he downloaded the application or if it was preinstalled, we know the version of his application, the version of the smartphone’s OS, the model of the device and the user's time zone. We pull out all statistics interesting for marketing and save it on the server.

    YOUR PORTION, SIR


    For all push developers, I recommend starting small mailing lists.

    Having launched our system for the very first time, we at UBANK sent pushes to a large number of target groups at once. Many immediately reacted and simultaneously entered the application.

    We did not expect such a high conversion. Our server could not withstand this load and suspended.



    The Hamster Factor

    To avoid such incidents, we now set up the system so that during the day it sends out several thousand messages every hour, rather than pushing the entire database in one sitting.

    Nothing works as well as a bicycle invented by yourself. Own development provides such opportunities that a ready-made solution will never provide. At least this is the case with push notifications.

    Of course, we plan to develop this system. Our task now is to increase the efficiency of the newsletter. To do this, we want to develop a new type of notifications, which, firstly, will be not just text, but with pictures, and secondly, by clicking send users immediately to the landing pages, and not just to the application.

    But about this, perhaps, another time.

    Also popular now: