The 5 Dangers of Installing Web Push Notifications Incorrectly

Introduction

For a seasoned web developer, adding support for web push notifications to your site via a push notification provider is a piece of cake. You simply:

1. Add some JavaScript to your site.
2. Add the service worker file (ie aimtell-worker.js)

However, according to most stats, only about 0.25% of world’s population are developers – so we don’t blame you if you needed some help getting set up.

That’s exactly why we not only offer installation via Javascript but built a WordPress plugin and Shopify app to take care of the entire installation process for you.

However, even still – we see more and more website owners these days cutting corners and deciding to use a push notification provider that lets them skip step #2 instead opt for a “quick installation” by enabling a “pop up” version of the push notification opt-in like the example below.

Well, we’re here to tell you that while you may think this is harmless, it’s not. In fact, it’s quite the opposite. It’s a recipe for disaster.

After seeing countless website owners fall victim, we decided it’s time we help educate the world and outline the 5 Dangers of Installing Web Push Notifications Incorrectly.

Note: If you installed Aimtell on your site (whether manually or with one of our plugins/apps) you’re all set. This article explains the dangers had you not installed it correctly and opted for one of the shortcuts provided by other vendors.

Danger #1: Web Push notifications don’t come from you anymore

Every browser handles the design of notifications differently. Some support large images, some allow for more text. But while they may all look slightly different  – you can see how they look here – they are all required to show the domain that the user initially subscribed to.

That becomes a problem if you are using the “pop up” work around as many browsers these days simply ignore the “subdomain”. As a result, if your visitors subscribed to yourwebsite.pushvendor.com, on the push notification it will simply show pushvendor.com.

That means your push notification would look like this:

Instead of this:

Ouch! Why on earth will your subscribers want to click on your notification if they don’t even know who “pushvendor” is?

Danger #2: Your subscribers can’t (easily) manage their subscriptions

One of the most fascinating built-in feature sets of website push notifications is that the subscriber has full control of their subscription. In cases like email, while a person may click “opt out” of an email, the reality is that technically anyone can still send an email to that individual. Regardless of their “opt out” status.

Web push was built from the ground up with a solution to this problem. With web push, the subscriber decides when they want to opt in or out of a website.

For most browsers, there are two ways for a web push subscriber to opt out of receiving notifications from you.

1. They click the padlock icon next to the url in the browser, and change the “notifications” option to their desired setting (ie block).
2. They click the settings button/cog icon that is automatically delivered with every push notification, which takes them to a page where they can view and manage push permissions for every site.

Now, here comes the problem.

If they try to manage their subscriptions directly on your website via either option , they will see your website’s notification permissions still marked as “default” as opposed to “accepted”.

That means, #1 no longer becomes a viable way for the subscriber to remove permissions. Instead, they’ll need to do #2. And what’s more –they’ll need to search for yoursite.pushvendor.com in #2, not just yoursite.com.

What’s worse, some vendors even allow you to specify a custom subdomain so although visitors opt-in when on yoursite.com, they may need to look for random.pushvendor.com when unsubscribing.

Talk about disgruntled customers and ways to quickly tarnish your brand!

Danger #3 – You may end up asking permissions again, and again, and again

With web push notifications you can’t tell if someone has subscribed to a different website. Generally speaking, we have no idea if you have subscribed to web push notifications on cnn.com if you are on Aimtell.com.

The problem is, that the same thing happens to the push vendor when you use that non https workaround. If a website visitor is on yoursite.com, they don’t know if they’ve opted in to yoursite.pushvendor.com

As a result, they may end up occasionally prompting your subscribers who’ve already opted in!

Danger #4 – Vendor migration hell

People switch products and vendors every so often. While we have a fantastic retention rate here at Aimtell, we know it’s just a fact of life.

Generally speaking – if set up your fcm keys – exporting subscribers and moving them to a new push vendor isn’t all that hard. (That is, assuming you didn’t do any sort of non https workaround.)

However, if your subscribers previously subscribed to yoursite.pushvendor.com, we can’t import them. As a result, if you ever want to move push notification providers you’d have to start completely fresh and will lose all your existing subscribers!

Yes, you hear that right. Just because you didn’t spend the extra 30 minutes to get set up you now are stuck with that push vendor forever.

Why? Because in reality they aren’t your subscribers anymore. The visitor came to your website, clicked away to another site (yoursite.pushvendor.com) and subscribed to them.

Essentially, the push vendor is just giving you a way to send messages to their subscribers. Ouch.

Note: yes, technically you can still send push notifications to old subscribers who opt’d in on yoursite.pushvendor.com. The problem is that since the push notification logic sits on yoursite.pushvendor.com – we can’t update the code. As a result clicks can’t be tracked, subscriber tokens can’t be updated, old vendors could stop pushes, etc. And if the subscriber token expires you’ve officially lost that subscriber.

Danger #5 – It’s an unsupported standard which may eventually be removed.

People are clever. They come up with hacky solutions to everything.

When web push notifications first started gaining popularity, many providers started to embed iframes websites as a way to request for permissions to end push notifications on a site even if it wasn’t https and/or didn’t install the required files.

That wasn’t intended functionality and it wasn’t long until the Chrome team (and W3C community) removed support. As a result, many people lost those subscribers entirely. (read more on the Chrome release blog)

Hacky solutions never last. And when the time is up, it causes 100x more headaches than what it would have been to just spend the extra time and do things the right way.

Wrapping up

This article by no means is meant to speak negatively on any push provider offering these types of solutions. Rather, we simply want to educate you – the user.

Shortcuts rarely pay off, and this is certainly one of those cases we’d recommend you avoid it. If you’re going to get set up with web push notifications, spend the extra 30 minutes and do it right.

If you have any questions about the above or need any help getting set up, please don’t hesitate to reach out. We pride ourselves on not only a great product but also great customer support. Between our live chat and our detailed documentation center we’ll make sure to are all set with web push.