This post originally appeared here on the Monk WebEngage blog.
Not too long ago, Marketers the world over were holding crisis meetings trying to understand why user engagement with their apps was falling. Their Email & SMS blasts were becoming inefficient with each passing campaign. The problem was ‘Too Much Information’ — Inundated by endless offers from brands via Email & SMS, the consumer learnt to ignore such communication.
The emergence of a new system was soon going to shake things up. RIM, the makers of the popular Blackberry device created a push messaging service for emails. Emails received would appear in a small tab on the mobile screen in real-time. Earlier, there was a time lag in receiving emails on your mobile device, and one had to constantly hit refresh to request updates. Soon, Apple picked up on this revolutionary development and launched the APNS (Apple Push Notification System). iPhone users could now get on-screen alerts from apps on their phone. This has now become the standard mode of interaction with apps on phones, tablets and desktops.
So, what classifies as a push notification? “Messages that are pushed to the user’s device in a heads-up manner on desktop and mobile are called push notifications.”
Now that you are well versed in Push Notifications definition and history, let us analyse the technology that powers it.
Push vs Pull
There are 2 ways in which information is transferred online:
- Receiver Pull (Pull Protocol) — In this protocol, a user connects to a server and requests for specific information on their device. For example, I search Google for an answer to my question, “What is the best sci-fi film franchise?”. Google receives the request, and rightly replies with a search result of “Star Wars” (no doubts here).
- Sender Push (Push Protocol) — Here, an ‘always open’ connection is established between the user and a server. All information is automatically ‘pushed’ towards the user, irrespective of whether the user actively requested for that information or not. Example: Your service provider and your mobile device. A push protocol allows messages and phone calls to appear on your device in real-time.
How do Mobile Push Notifications work?
Notifications sent to a mobile device by a server even when a user is offline is a mobile push notification. We will attempt to simplify the workings of a push notification, and how they work on WebEngage, a Marketing Cloud platform.
There are 3 key components in Push Notifications:
- Client App — This is the app which will be receiving push notifications.
- App Server — To send push notifications to app users, creation of an app server is mandatory. It sends messages to the GCM (explained further down), from where it is routed to the users app. WebEngage comes with an App Server so that you don’t have to spend time and money trying to design one for your business.
- Client SDK — This is the code that client needs to integrate into their app that will hook up their system with WebEngage.
This flow denotes the science behind Push Notifications:
Now, let us understand the flow in detail. In order to send push notifications, an app must be registered and configured with a Push Notification Service Provider. So, there are 3 popular options that can be used:
- GCM (Google Cloud Messaging) — Probably the most popular and widely used system.
- FCM (Firebase Cloud Messaging) — Google run entity with more advanced features than GCM.
- APNS (Apple Push Notification System) — Apple’s system run exclusively for iOS devices.
→ Registering with GCM will give you access to API keys.
→ Post registration, GCM assigns a unique ID for every user installing the app, marking that device-app pairing.
→ Post registration, a corresponding app server identification becomes necessary to enable its ability to send push notification to the app user on client’s behalf.
→ The API keys are required for app-server identification for GCM & FCM; APNS requires a certificate.
→ Now, the registration ID for the device-app pairing is identified by GCM & app server so that push notifications can be sent.
→ When a user launches the app for the 1st time, the registration ID (device-app pairing marker) is sent to WebEngage’s server by the client SDK. Now, our system has identified the user for sending push notifications in the future.
→ The WebEngage server sends the push notification in the form of data that is called payload via GCM.
→ WebEngage’s SDK on the client app receives this information, processes it and renders it accordingly on the intended device as a push notification.
That, is what happens behind the scenes when you send a push notification. Hope this helped you become a tad bit more informed about Marketing Automation. If you are out there looking for a tool to create and send push notifications, check out WebEngage. It is a Marketing Cloud platform that uses data to create highly personalised, targeted and contextual push notification campaigns.
Also Read:
- 8 Worst Push Notifications that Justify App Uninstall
- Make Behaviourally Targeted Push Notification to Achieve Desired ROI
- Why Your Push Notification Sucks?
- 3 Unique Push Notification Use-cases to Automate Customer Feedback
- In-App Notification v/s Push Notification: What’s Best for Customer Engagement
- 5 Push Notification Use-Cases for Online Travel Agency with Examples
