The State of Browser Push Notifications

Learnings from implementing browser push notifications for MinecraftList.org

Posted by Nick Jasuja on Jul 17, 2018

Quick background for those not familiar with the site:
MinecraftList.org is a directory of multiplayer Minecraft servers, both for the Java edition and Pocket Edition (PE) of the game. Servers are ranked in the order of the number of votes they receive. Server owners incentivize their players to vote for their server by giving them some in-game freebies and rewards.

A player can vote for a server once every 24 hours. Often players do not remember when they last voted, or exactly when 24 hours are up. This results in the players trying to come and vote, but failing to do so because their vote is not accepted.

An animated graphic showing a frustrated person on a chair saying Ugh

This seemed like an ideal case for browser push notifications. As soon the voting window for the player is open, we let the player know by sending out a push notification to the her browser.

The Technology

When I first started out exploring how to do push notifications, I wanted to use a service like PushCrew or PushEngage. Why bother learning about the intricacies when you can just outsource it to someone who will do it better than you?

But there are problems with PushCrew and services like it:

  • Neither PushCrew nor PushEngage support Microsoft's Edge browser. About 10% (and growing) of the website's user base uses Edge on Windows, so I wanted to support them.
  • PushCrew's free trial does not support mobile browsers. Alibaba's UCWeb and Samsung Internet browser both support push notifications.
  • PushEngage's website is completely borked for users of uBlock Origin. Perhaps their service is too. When you use a third-party's Javascript on your site you never know how it's going to break.
  • There is a learning curve for using the service provider's API. It is no easier than understanding how push notifications work in vanilla JS.
  • Once you use a service like this, it is virtually impossible to export all your data out. It is nice that PushCrew lets you have 2,000 subscribers for free. But if you ever grow tired of PushCrew, you will have to ask all your subscribers to resubscribe to push notifications using a new service. Ugh!

The Solution

Push notifications used to be handled differently for each browser. Google required you to use GCM (Google Cloud Messaging), then FCM (Firebase Cloud Messaging). But none of that is required any more.

It is 2018 and browser push notifications have -- thank God! -- standardized. Google has some excellent documentation on how to do push notifications correctly in modern browsers:

Web push notifications guide

Introduction to Push Notifications - from Google's Progressive Web Apps Training

With the sample code in Google's tutorials, it was super easy to set up push notifications in a cross-browser fashion.

An animated image of two software engineers saying that was easy

Tracking Metrics

Push notifications can be somewhat complex so every step in the interaction should be tracked. The workflow is:

  1. First ask the user if they would be willing to allow push notifications.
  2. If yes, trigger the browser push notification dialog. (Triggering the browser dialog directly is not recommended. If the user clicks "Block", you will never get a chance to ask them for permission again.)
  3. Once they approve notifications in the dialog, the browser gets the information about the API endpoint. You then log this info to your back-end system.

Use Google Analytics to track every step of this interaction. I track the permissions in steps 1 and 2 with the event action Permission 1 and Permission 2, and event labels "accepted" and "rejected". Step 3 is tracked as "Browser service".

When you send out push notifications, tag the URLs with Google Analytics' utm parameters. This will let you use the Campaign tracking features in Google Analytics to easily see traffic patterns from the push feature.

Results

Here are the results for the initial steps of

  • asking if they would be open to push notifications (Permission 1)
  • the actual browser dialog (Permission 2),
  • and the endpoint/credentials returned by the browser service.
The numbers are from Google Analytics so they don't all add up nicely to 100% but give you approximate numbers. More than 10% of users agreed to push notifications. That's a great conversion rate!

Metrics for permission events showing 16,630 rejections and about 2,600 acceptances from users for push notification permissions.

Among users who converted, here is the browser breakdown. I was pleasantly surprised to see UCBrowser and Samsung Internet in the list. A breakdown of the number of subscribers by browser. Chrome has the highest at 1,616 subscribers, which is not surprising. 227 Firefox, 224 each for Edge and Opera, Samsung Internet has 73.

TLDR

  1. Seriously look into rolling your own solution for browser push notifications; it is not so hard and Google has good documentation to help you get started.
  2. Track every step of the process using Google Analytics