Meet Pushkin - Nordeus’ Open Source Push Notification System

Dev & Ops

Push notifications deliver information from a software application to a client device without a specific request from the client. An important advantage of push notifications is that the technology doesn’t require any specific application on a mobile device in order to be received as Android and iOS support it out of the box. This allows a smartphone to receive and display a message even when the device’s screen is locked and the application pushing the message is closed.

Obviously, the rise of push notifications is a game changer for the gaming industry. Opening up a new channel of communication, push notifications have changed the way games interact with their users. An important factor contributing to this is the non-restriction policy push notifications have. You can send as many as you like, and whenever necessary. You have to be careful of course, because it can drive your users away.

Nordeus has been successfully using push notifications in Top Eleven for a long time; they drove our early retention numbers to an all time high by reaping the benefits of various cutting edge machine learning models, which construct specific personalized messages for every user.

We don’t consider our most successful notifications to be the ones that increase the most KPIs, but rather the ones that maximize user experience and enjoyment.

We call these messages service notifications, or in other words, notifications that inform the user of something important that would otherwise only be seen at the next log in. To give you an example and tell you a secret, the most successful Top Eleven push notification of all time is the one that informs the user a direct transfer offer that was placed on a player has been accepted. The second best notification is quite similar — it tells the user that the offer has been rejected. These two messages motivate as much as 95% of all the users who receive them to login to the game and react. We have achieved comparable results with notifications before and after a match.

To support our push notification efforts, we have developed a centralized messaging service with Apache Spark that runs on our Hadoop cluster. This gives us great scalability, tracking, real time messages, reliability and the opportunity to increase our KPIs by using every bit of data we have as it’s right there on the Hadoop cluster. We exploited this situation and launched various metric changing campaigns (one of which you can find here).

Soon after, Nordeus recognized push notifications as an important asset and other teams started requesting push campaigns of their own. After some time, we started to notice certain flaws in our design. Although there was nothing wrong with our system, we didn’t like the process every new idea — from ideation to implementation — had to undertake. Our system worked perfectly for the Marketing team, whose members could define any campaign they could think of in a dashboard and it would work just fine. But there was a problem when new features got implemented.

Rethinking the process brought empowerment through reliable data and independence for game designers and scalability.

Game designers quickly realized that service notifications were important for every feature, but in order to support them through our system, data needed to be prepared for it first. This obviously required some work from our Analytics team and it created a crucial dependency, which made us rethink the whole process. A good Analytics team needs to try to remove itself from all equations, enabling its supporting teams to be fully empowered with data. This was the main idea behind our effort to create a new lightweight messaging framework — Pushkin.

Pushkin has a few key differences in comparison to our former messaging system. It is designed to run directly on our game servers, increasing reliability and scalability even more. Also, we no longer depend on our database to create messages, but rather on game events that Pushkin receives from the game servers. This allows our game designers to be more independent, as they no longer need to wait for the Analytics team. All it takes for a new notification to be implemented is basically one line of server code and that is it! By doing this, we shift the focus to creating important service notifications our users appreciate and find useful.

Lack of good free-of-charge solutions motivated us to launch our very first open-source project as a way of giving back to the industry.

Our policy has always been to give back to the community. Seeing how there really wasn’t a good free tool for real time and scheduled notifications, we decided to open source our solution.

To fit all use cases, Pushkin has two modes of operation:

  1. You can issue a direct notification, meaning the game server supplies the user and the message. This is the most simple use case.
  2. You can send Pushkin a game event that happened to a certain user. Pushkin will then decide whether it can send a notification based on that event or not. If yes, Pushkin will construct the message in the proper language for the user (localization is supported) and the notification will be sent.

How does it work under the hood?

The system is set up in such fashion that the game server notifies Pushkin every time a mobile user logs into the game. This is done to update the device ID for every user, which uniquely identifies every mobile gadget your user has, as well as the language the user plays your game in. Because Pushkin can be distributed on your game servers, this load is evenly distributed and you are protected from outbursts.

If you want to take advantage of Pushkin’s event-to-message system, you are required to load in messages, as well as some metadata about them through Pushkin’s Message API. From that point on, all you need to do to send a message is to implement an appropriate server code that will notify Pushkin about ongoing in-game events. As a part of the Message API, Pushkin has mechanisms in place that will protect your users from unwanted spam caused by human error and also supports deep linking, which you can use to full extent to maximize user experience.

Although Pushkin is mainly made for live service notifications, you can easily turn it into a service for scheduled notifications. Because Pushkin’s flexible Input API, game servers do not hold exclusive rights for sending messages or events. It is fairly simple to construct a service that will query a database, gain insights and notify Pushkin about them. For Top Eleven, we already have a system in place doing just that. We are looking forward to open sourcing that part of our system as well.

On the matter of currently supported platforms, Pushkin uses Google’s messaging service and Apple’s push notification service so there are no problems with diverse mobile audiences. We plan to add Facebook and Chrome notifications in the near future as well.
 

More detailed instructions and all relevant documentation can be found on pushkin.io.

Milos Milosevic

Milos Milosevic

Data Scientist

April 01, 2016