Messages that are pushed to the user’s device, not limiting to desktop and mobile, in a heads-up manner are called push notifications.
To understand why push notification is called what it is called and how it functions, there is an important concept of push and pull protocols that we should be versed with.
Pull vs Push protocols
Basically, there are two common ways in which the information is transferred in this world and over the internet:
- Receiver pull
First type is when you request for the information. In real life, consider scouting for something on google. Here, you precisely know your information requirement and you request google for it. Google accordingly provides you the result.
Likewise, suppose you wish to watch Sopranos. To do that you request the content from HBO and HBO complies. (You have to although meet their condition but that’s secondary to our discussion today.)
The point I am trying to make is that in both the above two instances, the client connects to the server and requests for what he needs. When his request is fulfilled, he shuts down the connection. These kinds of information transfers in the internet environment are based on pull protocol, and information delivered via this protocol are called pull messages.
World Wide Web is based on HTTP which is a pull protocol. To load a page you type the URL on the browser which then initiates an HTTP request to the web server. The web server fulfills the requests and sends the content of the requested page on your browser.
- Sender push
Now consider another scenario where you don’t ask for anything but you still get an information because you allowed the publisher to do that.
For instance, recall the almost extinct RSS feed where once you subscribed to the RSS feed of the website, it could push information to your device whenever it chooses. You have activated the connection between you and the site. So, you get the feed even when you don’t ask for it.
This is a communication type based on push protocol.
It “gets its name from its ability to push information to a user’s desktop instead of waiting for the user to make a request.“ (Techopedia)
Email is sent using a push-protocol called SMTP. You don’t ask for it but still, you get it, don’t you?
What is mobile push notification?
In the context of mobile devices, push notification is the message sent by app server to the user’s device interface even when he is not logged in.
How mobile push notification works?
To understand how mobile push notifications work in action, let’s get three basic terminologies right
Client app– The app which receives the push notification.
App server– To be able to send push notification to the users who have installed your app, you have to create an app server. This server sends the message to the GCM (discussed later) which then transmits it to the client app.
Now, setting up the app server is secondary when you think of launching a push campaign. The things that matter are segmentation, triggered messaging, workflow set-up and hundred other things, building which would drain your tech resource unless you are Facebook, Amazon or something alike.
This is why there exist products like WebEngage that provide push notification engine as a service. Suppose you are using WebEngage, so the App server that we discussed in the above point would be provided by WebEngage.
WebEngage (insert your third party app server’s name) Client SDK– This is a piece of code that client adds to its app to integrate it with Webengage.
That’s it. Now, let’s understand the flow end to end.
- To be able to receive push notifications, the app must be configured and registered with a Push Notification Service Provider.
The most widely used service provider globally is GCM (Google Cloud Messaging), or FCM (Firebase Cloud Messaging), a Google-run entity. FCM is the advanced version of GCM with additional features. Then there is APNS run by Apple for iOS.
Registration with GCM provides you an API key that will be used in the next step.
- Once the client has configured with GCM, whenever a user installs the client app, GCM issues a unique registration id to this app-device combination. This registration is required so that the app can receive push notifications from GCM.
- After the device registration, an equivalent app server identification is needed. This is required so that the app server can send notifications to the user’s device on client’s behalf. This server identification is done using an API key in case of GCM/FCM, and a certificate in case of APNS.
Read #2 and #3 again to understand how we are linking two end points (app and server) with the GCM.
- Now, the registration id that we generated in #2 is unique to every app. GCM and app server identify this id to send notifications, therefore, it must be kept secret so that it is not misused.
- When the user launches the app for the first time, WebEngage’s client SDK sends this registration id to WebEngage’s servers. The same id is thereafter used by WebEngage to send push notifications.
- Now, a Push notification message is nothing but a piece of data called payload (4kb size in Android, 2k in iOS) which looks something like this.
- When WebEngage server sends the payload via GCM, WebEngage’s SDK on the client’s app processes the information contained in this message and extracts out the relevant pieces to render push notification on the device.
The above one is for GCM. The one for the APNS would obviously be different.
That’s all about how push notification exactly works. If you are already running push notification campaigns then the following guides may help you refine your strategy:
If you have a point to make or any doubt, please mention in the comment and we would be glad to address it to the best of our knowledge.