How to Migrate Web Push Tokens to our platform From a Different Platform

You may want and need to change the web push service provider due to its insufficient functionality, poor performance or high price. At the same time, you may be afraid of losing the token base and getting stuck with data transfer.

Below, we will describe the migration of web push tokens we’ve made for one of our clients that has recently switched from another service provider. For clarity, we’ll take all steps of the transfer procedure to our service.

Reasons to Change the Service Provider

The client used our platform to send campaigns via all channels except web push notifications. And although they stored all the contact data in our system, they couldn’t use web pushes for

• omnichannel workflows;
• segmentation by contact behavior;
• additional contact data collection.

A significant increase in prices of the old provider was also an important factor.

Why migration was possible

Our client used a different service, but they had their own Google project in Firebase. They needed to configure simple settings so as not to lose device tokens and keep the communication with the customers.

Note. Tokens for Safari require different settings, and the token export is also a bit different.

Token Migration

Note! If you don't need to import tokens collected before migration to our platform, or you don't have the corresponding capacity, you can set up a new web push subscription right in your profile in one click. The below process applies only to migration of the tokens previously collected in another service.

We built the process as following: created a chat with the customer and their developers and completed each step together.

How to Integrate With the Website and Save Existing Tokens

1. The script on the website (manifest.json) remained the same as it was under the previous provider.

2. Our content sw.js should be available at the same URL that was used for the previous service worker of the old provider.

3. The integration script body looks as follows:

<script>
    (function(i,s,o,g,r,a,m){
        i["esSdk"] = r;
        i[r] = i[r] || function() {
            (i[r].q = i[r].q || []).push(arguments)
        }, a=s.createElement(o), m=s.getElementsByTagName(o)[0]; a.async=1; a.src=g;
        m.parentNode.insertBefore(a,m)}
    ) (window, document, "script", "<INTEGRATION_SCRIPT_URL>", "es");
    es("pushOn", {
               'service-worker': {
            'relUrl': '/push-worker.js'
        }
    });
</script>

where

`INTEGRATION_SCRIPT_URL` is the URL of the integration script (individually generated for each application in the settings in the personal profile in our platform);

'/push-worker.js' is a relative path to the service worker used before.

4. The existing contacts were imported to the system via the API method Search contacts. This method is suitable for all tokens (basic and with additional contact info).

After import, we continued to send web pushes to all active tokens and also started collecting new subscriptions via our platform. Sending of scheduled automated campaigns didn’t stop.

How the Token Base Changed After Migration

At migration, we found out that the old token base was of a poor quality. Half of the web tokens were no longer valid. When sending a web push to such contacts, we received error alerts, such as "the token does not belong to the current project", "the token is no longer active."

Of 800,000 contacts, only 500,000 were active. This means that almost half of the campaign budget was wasted before migration to our platform.

We can confidently say that the percentage of the token loss during migration depends only on validity of the imported contact base.

Result

The whole process of migration with eventual testing took 2 days. Such data such as language, browser, subscription page, and OS version got immediately available for segmentation.

Why to Send Web Pushes via our plarform

1. Web push notifications are used as part of an omnichannel strategy along with email, mobile push, Viber, and SMS. Comprehensive data coming from each channel increase the individual effectiveness of each of them. Our platform collects information about user behavior on the website where subscribers go from your marketing message. All collected data is stored in the contact card.

2. Campaigns are segmented by

• website activity;
• purchase history;
• average check;
• location;
• device type, etc.

3. Web push notifications are automatically personalized using dynamic content: viewed products, personal discounts and bonuses.

4. Statistics for all campaigns is updated in real time, which keeps the contract base clean: you only send messages to active contacts.

5. You can set up both sending time and time to live: if a user remains offline for a long period, they won’t receive a no longer relevant push.

6. You get support in your time zone which not only helps with token integration but also enables to use web notifications in a combination with other channels.

Conclusion

After we helped several companies migrate their push notification tokens from other services, we made sure that the process is:

• Safe – tokens are not lost during import;
• Fast – the process takes about two days;
• Useful for the contact base validity – invalid tokens are deleted.

And most importantly, the process is easy because you have the support of our team throughout every step.