Crafting Effective Push Notification Messages: Tips and Techniques

In the bustling digital realm, push notifications are no longer pop-ups on our screens. For businesses and marketers, they’re indispensable tools that can dictate user engagement, brand recall, and even revenue flow. Imagine being a store owner and having the ability to tap a customer on the shoulder, drawing their attention to a special deal or reminding them of an item they’ve forgotten. That’s the power a finely crafted push notification holds.

However, the potency of push notifications isn’t merely about the message itself; it’s about context, timing, and relevance. A poorly timed or irrelevant push can turn away even the most loyal customers. Advanced users like you recognize this delicate balance. In this age of information overflow, the challenge isn’t just about reaching out; it’s about standing out.

Drawing from two decades of copywriting experience and countless case studies, we’re set to dive deep into the nuanced world of push notifications. This article will provide actionable techniques for creating compelling push messages and underscore the art of personalization, timing, and frequency. For those looking to transform their push notification game, this comprehensive guide is your first step.

Understanding Your Audience

In the vast ocean of digital communication, understanding your audience is the guiding star that ensures your messages don’t just reach the shores but resonate with the inhabitants. Just as a seasoned sailor reads the winds and tides, marketers and businesses must comprehend the subtleties of their audience’s preferences, habits, and behaviors.

Diving into Demographics

First and foremost, more than a surface-level understanding is needed. Knowing that many of your audience comprises males aged 25-35 or females in their early twenties is a start, but it barely scratches the surface. Advanced users need to dig deeper. What are their online habits? Do they interact more during work hours or in the evening? Answers to these questions form the foundational knowledge needed to tailor your push notifications effectively.

Psychographic Profiling: Beyond Age and Gender

One size does not fit all. Especially when it comes to digital communication. While demographics provide a skeletal framework, psychographics breathe life into the profile. Are they fitness enthusiasts, minefield, or perhaps weekend chefs? Understanding hobbies, interests, and even emotional triggers can significantly enhance the impact of your messages.

Harnessing Technology for Insights

Fortunately, technology today offers sophisticated tools that can provide in-depth insights into user behavior. Analytical tools and platforms offer real-time data on how users interact with your app or website. Observing patterns in these interactions can provide valuable clues about when and how to reach out to them. For those keen on further enhancing their understanding of audience analysis, click here for a detailed deep dive into some of the cutting-edge tools available.

Understanding your audience is not a one-off task but an ongoing process. With the rapidly changing digital landscape, preferences evolve, and behaviors shift. Staying updated with these changes ensures that your push notifications remain relevant, engaging, and, most importantly, effective. As we progress, remember that each user behind the screen has unique tastes and triggers. Tailoring your notifications with this perspective can make all the difference.

Crafting the Perfect Message

The foundation of any effective push notification is, undeniably, its message. The voice calls out to the user, the whisper that attempts to draw them in. Advanced users recognize that there needs to be more room for verbosity in the realm of mobile notifications. Every word must resonate, and every phrase should entice. So, how does one weave the magic within such limited confines?

Conciseness: Brevity is the Soul of Push

In an age of fleeting attention spans, your message must make an impact within seconds. For example, instead of saying, “Check out our latest range of summer clothing now available in our online store,” a more concise version would be, “Summer collection out now! Dive in!” It delivers the same message but with more punch and immediacy.

Personalization: Speak to the Individual

Studies show that personalized messages can boost engagement rates significantly. Data analytics can derive patterns like past purchase history or browsing behavior. A message saying, “John, your favorite brand just dropped its new line!” is far more engaging than a generic promotional notification.

Use of Emojis: A Picture Speaks a Thousand Words

Emojis can add flavor and emotion to your messages when used judiciously. A simple thumbs up or a heart emoji can convey feelings more effectively than words. For instance, “Loved your last purchase? ❤️ Check out what’s new!” has an emotional touch.

Urgency and Exclusivity: Creating a FOMO Effect

People inherently want to take advantage of it. Crafting messages that create a sense of urgency or exclusivity can boost click-through rates. Statements like “Flash Sale! Only for the next 3 hours ⏰” or “Exclusive sneak peek for our premium members!” effectively play on this psychological trigger.

Engaging CTAs: The Final Nudge

An effective message is only useful with a compelling call to action (CTA). Instead of generic phrases like “Click here,” use more direct and enticing CTAs like “Grab yours!” or “Unveil now.”

Crafting the perfect push notification message is an art backed by science. It’s about understanding human psychology, using data-driven insights, and then presenting it all concisely and engagingly. While the tips above provide a roadmap, continuous testing, and feedback are essential to refining the process. After all, evolution is the only constant in this digital age. So, keep experimenting, analyzing, and, most importantly, connecting.

Timing and Frequency

Imagine crafting the perfect message, but it gets lost amidst other notifications because it popped up at the wrong time. Or consider sending too many notifications, causing users to become overwhelmed and opt out entirely. This is where timing and frequency make or break your push notification strategy.

Understanding the Importance of Timing

It’s not just what you say but when you say it. Sending push notifications requires an understanding of your user’s behavior and lifestyle. For instance:

  • B2B Notifications: If your audience consists primarily of professionals, sending notifications during work hours might be effective. A productivity tool might find its users most responsive during the morning, signaling a fresh start to the day.
  • B2C Notifications: Conversely, an e-commerce platform targeting home users might see better engagement during the evening or on weekends, when users are more relaxed and open to browsing.

Global Audience? Consider Time Zones

For apps and platforms with a global user base, it’s crucial to send push notifications based on the recipient’s local time zone. For example, a gaming company with a worldwide audience might announce a new update. If they blast the notification at 10 AM PST, they’ll miss engaging users in Europe, who’d receive it at an inopportune time.

Frequency: Striking the Right Balance

It’s a tightrope walk. There are too few, and you risk being forgotten. There are too many, and you risk being intrusive.

  • User Preferences: Some advanced platforms allow users to set their preferred frequency. This customization ensures that users feel in control, reducing their chances of opting out.
  • Relevance Over Quantity: Instead of bombarding users with daily updates, send notifications when you have something precious to offer. For example, a weather app doesn’t need to notify a user about predictable sunny weather every day. However, an unexpected rainstorm or significant temperature drop is worth a heads-up.

Analyzing and Adapting

Always be prepared to adapt. Use analytics tools to gauge when your users are most active and receptive. By understanding your notifications’ “open rates” and “click-through rates”, you can adjust your timing and frequency accordingly.


Crafting effective push notification messages is not just an exercise in creativity—it’s a delicate art rooted in understanding, precision, and timely execution. Throughout this article, we delved deep into the intricacies that define a successful push notification strategy.

From the outset, understanding your audience emerges as paramount. As the bedrock of your notification strategy, it helps shape your messages’ tone, content, and delivery. By truly understanding the wants and needs of your users, you ensure that your messages resonate with relevance.

Next, the crafting of the message itself must be noticed. With limited real estate in terms of words and attention spans, every word must count. Balancing clarity, value, and a touch of persuasion is essential. A well-crafted message can differentiate between an engaged user and a lost opportunity.

Yet, even the most meticulously crafted message can fall on deaf ears if not timed right. The frequency and timing of your notifications play a vital role in ensuring your message gets the attention it deserves. No one wants to be overwhelmed by constant notifications, nor do they want to miss out on something of value. It’s all about striking the right balance.

To encapsulate, mastering push notifications is akin to mastering a musical instrument. It takes practice, understanding, and fine-tuning. As the digital landscape continues to evolve, so will the best practices surrounding push notifications. Yet, the core principles will remain: understanding your audience, crafting a compelling message, and getting the timing right.

The rewards for those dedicated to perfecting this craft are plenty: engaged users, higher retention rates, and a deeper connection with your audience. As you move forward, always remember that a person is at the heart of every notification, and every beep or buzz on their device is an invitation to a conversation. Make it count.

Does Instagram Notify When You Screenshot a Story

Instagram has made it possible for users to share photos and videos that disappear after a set amount of time. This feature is called “Stories.” It has become very popular, especially among young people. One question that many people have asked is whether or not Instagram notifies the person who posted the story when someone screenshots it. In this blog post, together with SpyBubble, we will answer that question and provide some other information about screenshots on Instagram Stories.

Is There a Notification When You Screenshot a Story?

The short answer to the question of whether or not Instagram notifies you when you screenshot a story is no. As of right now, Instagram does not notify anyone when someone takes a screenshot of their story. This means that if you take a screenshot of someone’s story, they won’t find out.

That being said, it is important to keep in mind that Instagram is always changing and updating its platform. It’s possible that this could change in the future and they could start notifying people when a screenshot is taken of their story. Therefore, you should always be aware of any changes that Instagram makes to ensure that you are following the platform’s rules and regulations.

It is also important to note that Instagram does notify users when someone takes a screenshot of an image or video in their direct messages. This means if you take a screenshot of something sent to you in a direct message, the other person will receive a notification that it has been taken.

How Can I Avoid Notifications When Taking A Screenshot?

If you don’t want to be notified when someone takes a screenshot of your story, there are several things you can do. For starters, you can choose not to post stories on Instagram at all. This will mean that no one will be able to take a screenshot, and you won’t receive any notifications.

You can also turn off screenshot notifications in the app settings. This will stop you from receiving notifications when someone takes a screenshot of your story, even if you have posted it. Finally, you can make sure to adjust your privacy settings so that only people you approve can view your stories. This way, you can ensure that only people you trust will be able to take screenshots.

Ultimately, there is no way to stop someone from taking a screenshot of your story on Instagram, but it is possible to limit who has access to it and disable screenshot notifications. By taking these steps, you can make sure that only trusted individuals view your story and that you won’t be notified when someone takes a screenshot.

Remember, if someone is taking screenshots without your permission, you can always block or report them so that they won’t be able to view any of your content again. Taking control of your privacy settings is the best way to protect yourself and make sure only the right people see your story.


In conclusion, Instagram does not notify users when someone takes a screenshot of their story. However, there are ways to limit who can view your story and disable screenshot notifications so that only trusted individuals have access to it. Taking control of your privacy settings is the best way to protect yourself and make sure that you don’t receive unnecessary notifications. By taking these steps, you can enjoy peace of mind while using Instagram.


Does Instagram Notify you When You Screenshot a Story?

No, Instagram does not notify users when someone takes a screenshot of their story.

Q: Is there any way to prevent people from taking screenshots of my story?

A: Yes, you can limit who can view your story and disable screenshot notifications in your privacy settings. By doing this, you can control who has access to your story and avoid unnecessary notifications.

Q: What should I do if someone screenshots my story without permission?

A: If someone takes a screenshot of your story without permission, you can block or report the user. This will help protect your account from potential abuse or harassment. Additionally, you can contact Instagram directly if the situation escalates and you need additional help.

Q: Are there other ways to protect my privacy on Instagram?

A: Yes, in addition to limiting who can view your stories and disabling screenshot notifications, you can also keep your account private or customize who can see what content on each post. Additionally, you can turn on two-factor authentication for extra security.

How to Fix Delayed WhatsApp notifications on Android?

We all use WhatsApp messaging service quite frequently and stay connected with our friends. Many times we reply to the WhatsApp messages from just the notifications. But, due to some reasons, these notifications don’t come timely and hence we miss getting them.

Almost every one of us has experienced this issue that delays the messages and the only way to see whether you’ve received any message is to open the WhatsApp application. Opening the app to check if any message has come is really annoying. There could be important messages that need to be replied on time but due to this issue users miss out reading and responding to them at the earliest.

Now, before you read the solution to it or how to fix WhatsApp delayed messages. You should know why these delays actually happen.

Why are my WhatsApp incoming messages being delayed?

Well, there can be many reasons that prevent WhatsApp messages to be delivered on time. So, it’s difficult to tell exactly what’s causing your messages to come or send on time. But, the first and foremost reason could be a poor internet connection that is causing your message to be delivered and received on time.

Also, not receiving the WhatsApp notification on time could be due to the restriction of background data use. This setting stops the app to sync data in the background over the mobile data connection.

How to ensure the prompt delivery of WhatsApp messages and notifications

So, I am writing here several troubleshooting ways that you can try and bring those timely WhatsApp notifications pop-up on time back for you.

  • First off, Reboot your device
  • Check your internet connection, if it’s unstable then try switching to Wi-Fi
  • Go to Settings > Tap Data Usage > Tap Mobile data usage > Select WhatsApp > Tap Background data (demoed on OnePlus 3T running Android 8.0 Oreo)
  • If you still find the issue in getting app notification timely then try deleting the app cache, which you can do by following the steps – Settings > Apps> WhatsApp > Storage > Clear Cache (this can take some time).
  • You can also reset the app preferences by going to your phone’s Settings app > Apps > Menu Button > Reset app preferences. (When you relaunch the WhatsApp, it will show you only contact numbers. Don’t worry, just click, little icon present on the right-hand side of the app, this will refresh your contact list )
  • WhatsApp also tells you to log from WhatsApp Web by going to WhatsApp > Menu Button > WhatsApp Web > Logout from all computers if you face delaying of messages.

Do let us know if any other solution worked for you.

How to Use PHP to Send Web Push Notifications for Your Web Site

Many sites need to keep their users up to date about new content even when they are not looking at the site.

Web push notifications can solve this problem by showing notification windows with short messages telling the user there is something new on the site that they authorized to be notified when new content is publishe.

Read this tutorial article to learn about how you can implement Web push notifications in your sites using PHP.

In this article you can read about the following:

  1. Overview
    • A brief view on web push notifications
    • How web push notifications works
      • The subscription process
      • Sending notifications
      • The required key pair (VAPID)
  2. Implementation
    • The subscription on the client side
      • Check whether push notifications are available
      • Obtain permission to deliver push notifications to the user
      • Registration of the service-worker
      • Implementation of the service-worker
    • Receive and save subscriptions on the server
    • Create and send notifications
      • The header
      • Encrypt the payload
      • Send the notification via HTTP-request
  3. Appendix
    • How long is a Subscription valid?
    • Standardbrowser settings to display notifications
    • Debugging and testing the service-workers

1. Overview

To implement web push notifications on your site page, appropriate functionality must be provided both on the user client side and on the server.

The user client must first subscribe to the notifications and then receive and display them. On the client side, JavaScript is used for this. The standard web push API is implemented in almost all popular desktop and mobile browsers.

Subscriptions must be saved and managed on the server side and the desired messages sent. In this tutorial, the server side is implemented with PHP, since this is the most used platform and therefore this could be the easiest way to integrate into an existing system.

Packets found on the Internet all have multiple dependencies on other packets (signing, encryption, asynchronous sending of HTTP requests) and therefore also a very high overhead of unused ballast. For this reason, I decided to create a package based on the available sources that has no further external dependencies.

The complete source code of the steps described below and the PHP package for sending push notifications can be found here (PNServer).

1.1. A brief view on web push notifications

Web push notifications allow messages to be sent directly to users, even if they are not currently visiting the sender’s site page.

Offers, news or other relevant information can be sent at any time and users can be redirected to a desired URL. From the user’s point of view, push notifications have the advantage that the entire subscription process is anonymous (the provider does not need names or contact details such as an email address or other information) and the service can be terminated at any time.

In order for a provider to be allowed to send push notifications to a user, the user must first explicitly take any action on the sender’s web site to confirm that he wants to receive these messages.

In addition, a unsubscribe option is automatically integrated in each delivered push message (how and where this unsubscribe option is offered depends on the users operating system and/or browser).

The push notifications are not displayed within the web site area of a browser, but either in a separate popup window or via a service provided by the operating system (this varies depending on the device, operating system and browser and some browsers allow marginally settings – see also in the appendix).

A notification usually consists of a title, a short text (optionally with an icon and/or a picture) and usually contains a direct link to the web site it relates to.

The notification system is an extremely powerful medium for interacting with users. However, the provider should always take care not to publish too much on this medium, otherwise users will deactivate all notifications.

1.2. How web push notifications works

An external push service is connected between the browser at client side and the message provider’s server. The push service is responsible for delivering messages from the server to the respective users.

When requesting information about the subscription from the web push API, the public part of a key must be passed. With the help of the private part of this key, the server in turn has to encrypt the messages before sending them.

1.2.1. The subscription process

Code for two tasks must be integrated on your site page. The first is to give the visitor the opportunity to subscribe to the web push notifications. In addition, the site page must install a service (‘service-worker’), with which the client is registered on the server and received messages are processed. The service-worker is downloaded in the background to the client platform so that it can be executed outside of the context of the site page.

If the user subscribes to the service, the service-worker is registered (1). The service-worker in turn requests all required information through the web push API (2) and sends this via an HTTP request (3) to the server. The server stores this information in his database (4) so that notifications can be sent to the client.

1.2.2. Sending notifications

Notifications can now be sent from the server to all registered subscriptions with a HTTP request (2). In order to correctly identify yourself, a signature must be transmitted in the request header. This signature is generated from the public key used for registration together with the private part of the key (1). The actual message and possibly further information are transmitted as user data – also encrypted. If the formatting and encryption are correct and the signature validated, the push service sends the notification to the client (3).

1.2.3. The required key pair (VAPID)

A key pair containing a public and a private key is required for the whole process. These two keys are called VAPID keys (VAPID: Voluntary Application Server Identification for Web Push; RFC 8292 – and have to be generated once for a web site.

There are various tools available for creating a VAPID key pair. Alternatively, online a key pair can be generated e.g. at The private key should never be visible to the end user (e.g. in a JS script or somewhere else), but should only be used on the server for encryption when creating notifications. VAPID protection ensures that notifications can only be sent to clients from the authorized server.

Very detailed information about VAPID can be found in the following blog post:

2. Implementation

After the general consideration in the previous chapter, we now turn to the actual programming.

2.1. The subscription on the client side

Since the client side runs in the web browser, everything on the client is implemented in JavaScript. Note that the integration of the functions within the UI of the web site is not part of this tutorial!

Some functions in connection with the web push API are processed asynchronously, which is why the promise pattern is used several times in the following code. Numerous articles on this topic can be found on the internet – at beginners can find a very good explanation.

2.1.1. Check whether push notifications are available

First of all, it must be checked whether all requirements are met in order to be able to receive push notifications on the current browser. To do this, the browser must support the web push API and the Web site must run in a secure context (HTTPS).

For more info about the API and the availability in the current browsers see and pnAvailable() {
var bAvailable = false;
if (window.isSecureContext) {
// running in secure context – check for available Push-API
bAvailable = ((‘serviceWorker’ in navigator) &&
(‘PushManager’ in window) &&
(‘Notification’ in window));
} else {
console.log(‘site have to run in secure context!’);
return bAvailable;

2.1.2. Obtain permission to deliver push notifications to the user

Due to the misuse of push notifications in the past, consent to display notifications should only be requested after the user has deliberately acted on it (e.g. by clicking a button – not automatically when the page loads!).

The following function should therefore best be integrated on your own Web site using a link or button in a separate area with corresponding explanations for the push notifications. This should be seen as a rule and not just as ‘best practice’.

As a provider, it should be borne in mind that many (… most) users are more likely to reject an early request without detailed explanations. And once the request has been rejected, it is difficult to get the user back on board later.

If the user has already rejected the display of notifications, he should no longer be bothered with further information regarding the subscription to the push notifications, since he must first deactivate the blocking of the notifications via the respective browser function! If necessary, this can be explained in more detail at a suitable point (e.g. under FAQ’s).async function pnSubscribe() { if (pnAvailable()) { // if not granted or denied so far… if (window.Notification.permission === ‘default’) { await window.Notification.requestPermission(); } if (Notification.permission === ‘granted’) { // register service worker await pnRegisterSW(); } } }

The browser remembers the user’s last selection. This can be determined at any time via the notification.permission property. If the user has not yet made a decision, this property is set to ‘default’, otherwise to ‘denied’ or ‘granted’. With most browsers, the decision can be reset by the user in the title bar or in the page settings.

2.1.3. Registration of the service-worker

In order to receive and display push notifications, even if the user is not on that site page, a service must be registered running in the background outside the context of the website and is therefore always ready to respond to notifications.

The so called service-worker is a separate javascript file that the browser copies from the origin location on the web to the local computer and executed there.async function pnRegisterSW() { navigator.serviceWorker.register(‘PNServiceWorker.js’) .then((swReg) => { // registration worked console.log(‘Registration succeeded. Scope is ‘ + swReg.scope); }).catch((e) => { // registration failed console.log(‘Registration failed with ‘ + e); }); }

It is not necessary to check whether the service-worker has already been registered. The browser (… the web push API) takes care of it. After registration, everything within the context of the website is done. All further steps are carried out within the service-worker.

All required functions and some helpers while testing included in PNClient.js.

2.1.4. Implementation of the service-worker

In the context of our site page, we have registered the service-worker so far and are now dedicated to his tasks. When registering, the specified javascript file was downloaded and executed. The registration succeeds only if the script could be executed without errors.

The only code in the service worker that is executed directly is to register listeners for several events:// add event listener to subscribe and send subscription to server self.addEventListener(‘activate’, pnSubscribe); // and listen to incomming push notifications self.addEventListener(‘push’, pnPopupNotification); // … and listen to the click self.addEventListener(‘notificationclick’, pnNotificationClick); Subscribe to push notifications and send subscription to the server

In the listener of the ‘activate’ event, the notification is subscribed using the web push API. The public VAPID key (see 1.2.3.) is required for this. In addition, the function requires the boolean value ‘userVisibleOnly’ as parameter, which must always be set to true.

Comment on this parameter
When designing the web push API, there was a consideration if this parameter can be used to control whether a message generally has to be displayed to the user or whether certain actions can only be carried out in the background.

However, there were concerns that this would create the possibility for developers to perform unwanted actions without the user’s knowledge. This parameter can therefore be regarded as a ‘silent agreement’ that the user always get a message when a push notification arrives.async function pnSubscribe(event) { console.log(‘Serviceworker: activate event’); try { var appPublicKey = encodeToUint8Array(strAppPublicKey); var opt = { applicationServerKey: appPublicKey, userVisibleOnly: true }; self.registration.pushManager.subscribe(opt) .then((sub) => { // subscription succeeded – send to server pnSaveSubscription(sub) .then((response) => { console.log(response); }).catch ((e) => { // registration failed console.log(‘SaveSubscription failed with: ‘ + e); }); }, ).catch ((e) => { // registration failed console.log(‘Subscription failed with: ‘ + e); }); } catch (e) { console.log(‘Error subscribing notifications: ‘ + e); } }

The public VAPID key must be transferred to the push manager as a UInt8 array. If successful, the push manager returns a subscription object. This object contains all information the server needs in addition to its own VAPID keys to be able to encrypt and send push notifications to this client. For this purpose, the information received must be sent to the server.

The data is sent to the server as JSON-formatted text in the body of a POST HTTP request. For transmission, we use the fetch() method of the javascript Fetch API. This method allows resources easily to be accessed or sent asynchronously over the network.async function pnSaveSubscription(sub) { // stringify object to post as body with HTTP-request var fetchdata = { method: ‘post’, headers: { ‘Content-Type’: ‘application/json’ }, body: JSON.stringify(sub), }; // we’re using fetch() to post the data to the server var response = await fetch(strSubscriberURL, fetchdata); return response.json(); }

The target ‘strSubscriberURL’ is a service that has to be provided on your server. It accepts the transmitted data and stores it in a database. The implementation of this service is described in section 2.2.

If additional specific information is required in addition to the current subscription (e.g. login data of the user, a reference to a specific order or reservation, …), this should also be transferred here, since this is the only direct link between client and server. Displaying the received PUSH notifications

In contrast to the server side, on the client side the web push API (and the push services) takes over all tasks regarding verification and decryption, which enables us to concentrate on the display of the notification.

When a push notification arrives, a corresponding ‘push’ event is triggered to the service worker. So the first thing to do is to set up a listener to this event. All relevant information is passed to the listener in the ‘event’ parameter.

In addition to some internal properties, this object primarily contains the data sent by the server. The format in which the data is transmitted is the sole responsibility of the sender. At this point, pure text is assumed – this may also can be sent for test purposes from some tools or from some browsers developer tools. (See appendix).

After we have implemented the sending of the notifications in chapter 2.3. we will switch to an object encoded as a JSON string. Through this object we are able to control most of the properties of the notification to be displayed. First of all, it’s just about displaying a simple text message.function pnPushNotification(event) { console.log(‘push event: ‘ + event); var strTitle = ‘Notification’; var strText = ’empty Notification received!’; if ( { strText =; } var promise = self.registration.showNotification(strTitle, opt); event.waitUntil(promise); }

To display the message the showNotification() function have to be used, which is passed the title and an option object. This option object can contain properties to control the content, format and behavior of the notification.

A more detailed description follows in Chapter 2.3 when notifications are sent from the server. The final call of waitUntil() ensures that the (asynchronously generated) notification was actually displayed before the function exits and the browser terminates the service-worker. Respond to user actions

In order to be able to react to user actions, a listener for the ‘notificationclick’ event must be set up. With the ‘event’ parameter, this function receives all data for the notification in the ‘event.notification’ property. User-specific data can be passed within ‘’. This data for example can contain an URL to be opened when the user clicks on the notification.function pnNotificationClick(event) { console.log(‘notificationclick event: ‘ + event); if ( && { const promise = clients.openWindow(; event.waitUntil(promise); } }

The function clients.openWindow() is available for opening a URL in the browser. Here, too, the waitUntil() must be used to wait for the call to end correctly before the service-worker can be terminated.

Further possible actions inside of the ‘notificationclick’ event are discussed in chapter 2.3 when messages are sent from the server.

2.2. Receive and save subscriptions on the server

To receive and save the subscriptions, a service is set up on the server that receives the data posted by the HTTP request from the client and stores it in a database. It must therefore first be checked whether it is a POST request. In addition, it must be checked whether the content of the request has actually been identified as JSON data.

If the request is correct, the data will be saved. For the sake of simplicity, we use a SQLite data provider here, since it creates its own data file and can be used without further configuration. By using the same data provider, the subscriptions will be accessed later to send the notifications. 

To integrate the package into your own system, you can use the MySQL data provider or your own data provider that implements the PNDataProvider interface.
// only serve POST request containing valid json data if (strtolower($_SERVER[‘REQUEST_METHOD’]) == ‘post’) { if (isset($_SERVER[‘CONTENT_TYPE’]) && trim(strtolower($_SERVER[‘CONTENT_TYPE’]) == ‘application/json’)) { // get posted json data if (($strJSON = trim(file_get_contents(‘php://input’))) === false) { $result[‘msg’] = ‘invalid JSON data!’; } else { $oDP = new PNDataProviderSQLite(); if ($oDP->saveSubscription($strJSON) !== false) { $result[‘msg’] = ‘subscription saved on server!’; } else { $result[‘msg’] = ‘error saving subscription!’; } } } else { $result[‘msg’] = ‘invalid content type!’; } } else { $result[‘msg’] = ‘no post request!’; } // let the service-worker know the result echo json_encode($result);

2.3. Create and send notifications

To send push notifications we have to follow the definitions of the web push protocol (see Basically, two steps are necessary when creating the push notification.

In order to identify yourself with the push service, a signature must be transferred using the VAPID key in the header of the request. The notification itself is transmitted in encrypted form and corresponding information is also passed in the header so that the browser can decrypt the received data. If the notification was decrypted correctly, the browser triggers the ‘push’ event to the service-worker.

2.3.1. The VAPID header

In order to identify with the push service, the server has to sign some information in JSON format with its private VAPID key and pass it in the header. The push service verifies this and, if successful, forwards the notification to the user.

The signature is given in the form of a JSON Web Token (JWT). A signed JWT is nothing more than a string, which consists of three components separated by dots:

JWTInfo . JWTData . Signature

The first two strings are JSON formatted data, which have to be ‘URL safe base64’ encoded, the third part contains the encrypted signature.

JWT Info

This contains information about the JWT itself and the encryption algorithm used.

JWT Data

Contains information about the sender, the recipient (not the final recipient, but the push service!) and how long the message is valid.


The signature is generated from the first two unsigned parts. To do this, they are encrypted with the ES256 algorithm (short for: ECDSA using the P-256 curve and the SHA-256 hash algorithm) using the VAPID key.

The push service now validate the JWT by decrypting the signature using the public VAPID key and comparing it with the first two parts.

The complete JWT (i.e. all three parts separated by a dot) is passed as authorization in the header. In addition, the public VAPID key ‘URL safe base64’ coded must be transferred in the crypto-key value.

The required VAPID headers are generated with the PNVapid class. The VAPID keys are passed once in the constructor since they do not change. The end point (i.e. the recipient) is passed on again for each notification to be generated.
// info $aJwtInfo = array(‘typ’ => ‘JWT’, ‘alg’ => ‘ES256’); $strJwtInfo = self::encodeBase64URL(json_encode($aJwtInfo)); // data // – origin from endpoint // – timeout 12h from now // – subject (e-mail or URL to invoker of VAPID-keys) $aJwtData = array( ‘aud’ => PNSubscription::getOrigin($strEndpoint), ‘exp’ => time() + 43200, ‘sub’ => $this->strSubject ); $strJwtData = self::encodeBase64URL(json_encode($aJwtData)); // signature // ECDSA encrypting “JwtInfo.JwtData” using the P-256 curve // and the SHA-256 hash algorithm $strData = $strJwtInfo . ‘.’ . $strJwtData; $pem = self::getP256PEM($this->strPublicKey, $this->strPrivateKey); if (\openssl_sign($strData, $strSignature, $pem, ‘sha256’)) { if (($sig = self::signatureFromDER($strSignature)) !== false) { $strSignature = self::encodeBase64URL($sig); $aHeaders = array( ‘Authorization’ => ‘WebPush ‘ . $strJwtInfo . ‘.’ . $strJwtData . ‘.’ . $strSignature, ‘Crypto-Key’ => ‘p256ecdsa=’ . self::encodeBase64URL($this->strPublicKey) ); } }

2.3.2. Encrypt the payload

Since the push notifications are sent by various push service providers, the actual user data is transmitted in encrypted form. The push service is unable to decrypt and read this data.

This is defined in the ‘Message Encryption for Web Push’ (see

The techniques that are used during encryption are beyond the scope of this tutorial and are therefore not explained in detail. You will find a good explanation in the web push book by Matt Gaunt ( in chapter 4.2.

All required functions are provided by the PNEncryption class. This class also provides the additional request headers that are required so that the notification can be decrypted. In the constructor, this class requires the public key and the authentication code that was generated by the browser when subscribing, and of course the user data to be encrypted.

2.3.3. The payload

At this point we are now going to take a closer look at the user data that we want to send with the notification. As mentioned in section 2.1.4, the possible options that can be passed to the showNotification() function in the service-worker are explained in more detail now.

Since the format and content of the payload can be freely defined (as long as the length of the user data does not exceed approx. 4000 characters), I have decided to include all information for displaying the notification on the server side together in an object. In addition to the title and the target URL to which we want to direct the user, this object also contains the complete options for the showNotification() function.

Everything together is then JSON-encoded and sent as payload. This gives us the greatest flexibility to determine the display and behavior of the notification from PHP without having to make changes to the service worker. The options of showNotification()

In order to address the user with a clear notification, this should consist at least of a short, meaningful title, a symbol with recognition value (-> preferably a company or product logo) and a short, precise text.

The title is passed directly as a parameter, the other two values are part of the option object. A clear recommendation regarding the format of the symbol cannot be made. In any case, a square format should be chosen, since most browsers or platforms crop other formats accordingly.

A size of 64dp (px * device pixel ratio – this gives 192px for a value of 3) has proven itself. The text should not be longer than about 200 characters. Here, too, the browsers and platforms differ in behaviour when a longer text is provided. Some limit the text to a certain number of characters, others to a certain number of lines. It should also be keep in mind here that a text that is too long usually does not receive the necessary attention from the user.

With the ‘tag’ option, notifications can be grouped for the user. This ensures that only the most recently received notifications with the same indicator are displayed to the user so he will not be “flooded” with a sequence of several messages of the same type. If the ‘renotify’ option is also set, the user will be notified, and the notifications will still be grouped in the display list. If not set, no notification will be displayed.

The support of the following properties, which can be defined to format the notification or its behaviour, varies widely between the several browsers/platforms and should therefore be used with caution.


URL to a larger image, which is usually displayed below the text. Again, it is difficult to give a rule about size or format.


URL to a (often monochrome) badge. The badge is used to better classify the sender of the message. So far, this is only supported by a few browsers – most of them display their own icon.

Additional actions

Some browsers allow certain actions to be displayed within the notification so the user can select one of it. The respective javascript code must be defined in the service worker in the ‘notificationclick’ event. If this functionality is used, an alternative display and handling should always be provided if the browser or the target system does not support this function.

An action is defined by:
– action:    internal ID used in ‘notificationclick’ event.
– title:        text to be displayed.
– icon:       [optional] URL to an icon assigned to the action.

The count of actions that can be displayed within a notification vary as well. An interesting article on this topic can be found at


This allows you to set the time when the message was generated. If this option is not set, the time at which the message arrived at the user is set.

Require Interaction

This property specifies that user interaction is required for the notification. The popup is usually displayed immediately and disappears after a certain time. If this option is activated, the popup remains until the user answers. This property should be used carefully (for very important or security issues only) as the user may find it annoying and may block the notifications permanently.


No sound is played or vibration is triggered.


A vibration pattern to run with the display of the notification. A vibration pattern must be an array with at least one member. The values are times in milliseconds where the even indices (0, 2, 4, etc.) indicate how long to vibrate and the odd indices indicate how long to pause. For example, [300, 100, 400] would vibrate 300ms, pause 100ms, then vibrate 400ms.


URL to a sound file. So far I have not found a browser that supports this. Extend the ‘push’ event listener in the service-worker

To generate the notification, the PNPayload class provides all methods to define the properties described and create the Object.

Since we initially assumed pure text as user data when creating the service-worker in section 2.1.4, the event listener must now be expanded for the data contained in the notification. All that needs to be done is to decode the received JSON-formatted data and pass it on when calling the showNotification() function.
function pnPushNotification(event) { console.log(‘push event: ‘ + event); var strTitle = strDefTitle; var oPayload = null; var opt = { icon: strDefIcon }; if ( { // PushMessageData Object containing the pushed payload try { // try to parse payload JSON-string oPayload = JSON.parse(; } catch (e) { // if no valid JSON Data take text as it is… // … comes maybe while testing directly from DevTools opt = { icon: strDefIcon, body:, }; } if (oPayload) { if (oPayload.title != undefined && oPayload.title != ”) { strTitle = oPayload.title; } opt = oPayload.opt; if (oPayload.opt.icon == undefined || oPayload.opt.icon == null || oPayload.icon == ”) { // if no icon defined, use default opt.icon = strDefIcon; } } } var promise = self.registration.showNotification(strTitle, opt); event.waitUntil(promise); }

2.3.4. Send the notification via Http-request

The last step is to send the notification(s) to the respective push services via HTTP request. In order to be as independent as possible, this is done directly using cURL.

To have as little idle time as possible even with a large number of notifications to be sent, all pending messages are first generated completely, encrypted and then sent using a cURL Multirequest.

Since PHP does not support multithreading per se, this is the most elegant solution without complex external PHP extensions. After all notifications have been sent, the response codes of all requests are read in order to filter out any subscriptions that are no longer valid and, if so configured, to delete them from the database.

The complete process to send notifications

  • create the VAPID header signature
  • generate the notification payload
  • encrypt the payload
  • send via HTTP request
  • If necessary, delete expired / no longer valid subscriptions

is implemented in PNServer by using the respective classes.

3. Appendix

3.1. How long is a Subscription valid?

In principle, the information provided by the browser for a subscription also contains a time stamp when it expires. Almost no browser assigns a valid value to this data field (a correct value only was set by MS Edge).

According to the specification for subscriptions that have an expiration date, the push service sends a ‘pushsubscriptionchange’ event to the corresponding service-worker before the expiration. In this case, the service-worker should re-subscribe the notifications.

If a user quit an existing subscription (generally by blocking the notifications for the page in the browser), this is forwarded by the browser to the corresponding push service. If the server then tries to send a notification to this endpoint it is not forwarded to the browser but the push service send a response code of 410 back to the server instead.

For those cases, the Notification Server has the option of removing subscriptions that are no longer valid from its database in order to avoid unnecessary data traffic.

However, if a browser is no longer in use, uninstalled or the system is no longer used for another reason (reinstallation, outdated, defective), the existing subscriptions that do not have an expiry date are retainedin the database.

The W3C and standard browser providers are considering getting this problem under control. Unfortunately, the notification server itself doesn’t have a reliable way to detect inactive subscriptions.

3.2. Standardbrowser settings to display notifications

Most (desktop) standard browsers offer the option of setting whether a service provided by the operating system or an own implementation should be used to display the notifications.

3.2.1. Firefox

Type ‘about:config’ in the navigation field for the Internet URL and search for ‘alerts’. The value ‘alerts.useSystemBackend’ controls the behaviour. If set to true, notifications are displayed by the operating system, otherwise the browsers internal implementation is used to display the notifications.

3.2.2. Google Chrome

Enter ‘chrome://flags’ in the navigation field for the Internet URL and then search for ‘notifications’. The setting ‘Enable native notifications’ controls the output.

3.2.3. Microsoft Edge

Since the Edge Browser is very much integrated into the Windows operating system, it basically uses the Control Center to display the notifications.

3.3. Debugging and testing the service-workers

There are various options for debugging and testing the service-worker in the developer tools of the standard browsers.

3.3.1. Firefox

Type ‘about:debugging#/runtime/this-firefox’ in the navigation field for the Internet URL. All registered service-workers are displayed below the list of the extensions.

The service-worker can be started or logged off here. Once the service worker is started, an (empty…) test message can be pushed, or the console and debugger of the service-worker can be opened.

3.3.2. Google Chrome

Open the developer tools when the page from which the notifications are subscribed is open. The registered service-worker is displayed under the menu item ‘Application’. Here you can start, stop, update or unregister the service-worker. A test message can also be sent and you can switch to the source code / debugger.

3.3.3. Microsoft Edge

Similar to Chrome, MS Edge has a item in the main menu of the developer tools named ‘Serviceworker’.

4. Conclusion

Web push notifications are a great means to keep users coming to a site that publishes content that they like.

Implementing Web push notifications using PHP and JavaScript it is not hard. It requires some work but the package PHP Web Push Notifications Server was created to simplify this jobs.

You can download or install this package using PHP Composer tool by going to this download page to get the package code.

Good Luck!

Exit mobile version