Things to Keep in Mind When Migrating to a New Web Push Platform

Web Push is a relatively new communication channel, and there are brands that feel cautious about it, fearing technical issues and general process complexity. However, below you’ll see that sending web pushes is simple and time-effective, and you can simply add it to your marketing routine.

First, let's look at the main participants of web push marketing:

On the client's part:

• subscriber,
• browser + service worker.

Service Worker is a script run by a browser in the background, beyond the web app, thus providing functionality that doesn’t require direct interaction with a user or the need for a web application to be active at the current moment (by active we mean the presence of uploaded/open website pages). Today, service workers include features such as push notifications and background synchronization.

For more information, visit developers.google.

On the sender's side:

• web push notification platform,
• service provider.

In our case, the service provider is Google Firebase Cloud Messaging (FCM) - a platform with wide functionality, including that to work with apps on iOS and Android.

Note. Safari uses its own service to receive and deliver notifications. We’re reviewing the example only with FCM used by Chrome, Opera, and Yandex.

To start working in Firebase, you need to create a project in it. You can use multiple projects to support several different applications.

Customer Journey: From Subscription to First Notifications

The moment a user visits the company's website, they are shown a prompt offering to allow web pushes from this website.

A click on Allow confirms subscription and creates a token. The token is transferred to the web push platform which sends notifications through the corresponding provider.

If there is a new notification, the corresponding Service Worker handler is triggered.

There are two ways to receive the notification content:

1. Directly from the service provider.
2. Via a special API of the web push platform.

When you click Send in your account, you actually send a request to Firebase that you have a message for this token. Service Worker receives information about the available message, requests the message content from the push platform, and shows it to the subscriber.

Migration Problems

The main problem: a Firebase project may belong not to you, but to the web push platform.

Some platforms connect all tokens to their domain or the project which belongs only to them. When you migrate to another platform, your tokens are left to the old platform. This happens not because services are bad, but because they have such a technical routine.

Even if you take away the collected tokens, the platform you’re migrating to won’t have access to the Firebase project previously used for campaigns. You won’t be able to send to these tokens.

To migrate the base:

1. The project should belong to you.
2. You should be able to get a list of tokens to transfer it from one platform to another. More details on how to do it.
3. Subscription must be managed through your domain.

What to Do If the Firebase Project Doesn't Belong to You

In this case, you can continue to send promotional campaigns from the old platform, and collect new tokens to collect at the new one.

The average expiration time of a token is 3 months. Often, up to 50% of tokens get inactive within a month. The reasons may be:

• blocking your web pushes in the browser settings;
• change of the device;
• removal of Service Worker, etc.

Thus, you will be able to completely migrate to a new web push platform in about three months. And the sooner you decide to take control of your own contact base, the better!

Make a special note in web-guns from the first moment of your life. For example, by launching a welcome series for web-push.

If Migration Was Successful

It doesn’t mean, everything will go smoothly. There are nuances here, too.

In the new platform, you create a message and click “Send”. Firebase, that belongs to you, receives a signal that you have a message for the token. Service Worker receives this signal in a second way, namely - through the API of the web push platform, and goes for content to the previous web push platform. This scenario will continue until the script is updated.

So How Do I Send Content From a New Push Platform?

You need to "train" Service Worker to request message content not from the old but from the new platform. There are two ways to do it:

1. The Subscriber must visit the company's website again, and Service Worker will be updated automatically, provided more than 24 hours have passed since the last check of browser updates. The downside is that users rarely visit the website without particular needs. You can send subscribers an email campaign, and Service Worker for those who click will be updated. But then again, that's just a part of the subscribers.
2. You need to send a push campaign. Then, thanks to the updated content in Service Worker, when the next notification is received, the handler will go for the content to the new platform. The downside is that for the first time the handler will still turn to go the old platform and subscribers will receive not your beautiful campaign but a technical notification.

In this case, some web push platforms have a neutral default message that is sent if there is no prepared message for tokens, but the request is received.

But still, it is better to build proper customer communication from the start, so choose the right push service wisely.

Things to Keep in Mind When Choosing a Web Push Platform

1. Access to the token base. Make sure that Firebase is yours and you have access to all tokens. If the platform doesn't allow you to use your Firebase project, you won't be able to export contacts and migrate them to another service if needed.
2. Functionality for push notifications. For example, is it possible to set the time to live (TTL), use CTA, big images, etc.
3. Automation. Is it possible to use automated pushes and add dynamic content. For example, launching abandoned carts/browses/welcome series.
4. Segmentation. By what parameters you can set up segments and whether it’s possible to do it using the particular platform.
5. Multichannel. Will you be able to use web pushes in multichannel and omnichannel workflows.
6. Base storage. A very important moment - whether the base is cleaned. For example, whether inactive tokens are detected. make sure you don’t pay for sending to inactive contacts.
7. Statistics. What metrics are included in the statistics after sending and how to work with them.

That's why we have expanded the functionality for sending push notifications. So that our users don’t face the above problems and have no issues with base storage.

If you need any advice on how to migrate the base to our platform or how to work in our system - contact our support team.