Playbooks & Whitepapers

Blog

Last update: November 2020

4 mins to read - 2020/11/11

What Is a Pull Notification?

We’ve all heard of notifications, mostly generally called push notifications. And, as we’ve explored before, notifications are fast on their way to becoming the #1 method of real-time communication between mobile device users and brands whose apps they have installed. Less spoken about are pull notifications, a form of PC or mobile messaging that originates from the end user.  So what are pull notifications? What are their use cases? And how can developers use them to complement push notifications in a robust, multi-channel mobile marketing campaign?

Pull Notifications Explained

First we better explain the types of notifications that can be delivered to an app user or player of a mobile game on their phones, and how they work behind the scenes.  There are really two types of notifications: local notifications and push notifications… even though mostly people just refer to push notifications to cover everything. For the end user, they all look the same – so sometimes people say user notifications as the catchall phrase.  

The former, local notifications, are where the app itself delivers a notification to the user.  A push notification, or sometimes referred to by techies as a remote notification, is where push notifications originate from the app’s backend. In this scenario, developers send messages to user devices on a schedule which they set.  This is by far the most popular way to send notifications to users in their billions every minute of every day.

Pull versus Push

Conversely, the delivery of Pull Notifications to individual devices is prompted by an action on the device side. This action is triggered either by the user or the server. This would explain why pull notifications aren’t talked about nearly as much as push notifications… waiting for users to invite you to send them communications isn’t a very effective marketing strategy.

Because they are initiated on the device’s end, pull notifications often require a base version of the software to be installed on the device. This software then periodically checks for updates. This is very resource heavy, as the software in the app needs to keep checking or polling the backend servers to see if a notification is waiting. As such, this is a killer for the user’s battery. Most devices will stop the app from continuing doing this for that reason. Doing an internet call with either Wi-Fi or mobile data is the second biggest battery drain, after the screen being on.

And because the 3-tier design of pull notification architecture is structured on the backend receiving requests from the users, the enormous amount of mobile devices doing this can result in a strain on network and server resources. Not very practical when compared to the reliability and versatility of user notification technology, be it local or push notification implementations.

pull notification three-tier structure
Image source: https://www.wired.com/insights/2013/12/mobile-design-patterns-push-dont-pull-part-1/

What Are Pull Notifications Used For?

While user notifications are certainly more of a powerhouse in the mobile marketing domain, pull technology also has its place. Developers generally use pull notifications for delivering non-essential updates and communications. Or they are also useful in delivering sensitive or private information that a user doesn’t need on a regular basis… For example, the latest content for game, bank account updates, or health insurance information, etc. 

Outside of mobile apps, pull notifications are also more commonly used for HTTP page requests on websites. Push technology is more prevalent with mobile devices. Web feeds (e.g. RSS) are an example of pull technology. In this, the RSS reader polls the server, continuously sending out feelers for new information. As stated above, polling requests often exceed the bandwidth of the RSS feeds. This can then overwhelm the servers and lead to shutdown.

Pull technology is also the structure behind podcasting, which use RSS feeds. Podcasts publish new episodes to a feed. But users’ feed readers or mobile apps need to request delivery of the episode before it goes out to individual devices. Podcast directories such as iTunes regularly request the RSS feed for updates. In doing so, they replicate a sort of facsimile of automatically generated push technology. (At least, from the end user’s standpoint.) In this way, new podcast episodes are available for subscribers to access via their apps, regardless of when iTunes made the request.

Does OpenBack Do Pull Notifications?

OpenBack is actually a hybrid of local and push notification technology. We take the best of all worlds by using local notifications for the massive deliverability gains, reliability, better metrics. Then, we enable developers to personalize the moment of delivery with lots of real-time signals. Combine that technology  with silent push notifications for backend real-time situations where the backend servers know something that the app doesn’t yet know. (Like the latest score in your favorite game.) The server will use a push notification to tell the app to fetch the latest messages, campaigns and business rules. 

In some senses, the app does privately pull down those messages and content. But it then keeps all that information in the app. The app then applies the business logic until the right moment, meeting signals to deliver the message.  However, these aren’t true pull notifications, as the OpenBack software isn’t constantly pulling notifications and data down. In fact, OpenBack’s use of device-side edge computing enables reliable, real-time delivery of notifications, as well as preserving user battery life. 

To learn more about how you can up your mobile marketing game with OpenBack’s dynamic notifications, get in touch with one of our experts.

Leave a Reply

Your email address will not be published.

twenty − nineteen =

For our definitive push notification best practices download the OpenBack Mobile Marketing Playbook 2020!

Submitting...