How to Migrate Your Users to SendMsgs

migrate-users

Now that you’ve started using SendMsgs push notifications, you may be worried about losing users as you migrate from your old system to our new one. We totally understand that concern. That’s why we’ve decided to put together a little directory to teach you how to migrate users to our system. Here, we will give an in-depth explanation of how to migrate your HTTPS push notification subscribers in Safari, Chrome and Firefox.

Safari:

In Safari, if you have an apple developer account and use the APN certificate from your own account, you can migrate without any code change. For Safari OS X, push notifications can be used on both HTTPS and HTTP sites. Here, sign-ups are connected to Apple Push Notifications, or APN, and then kept at an end-point URL. To create the APN accreditation that you’ll need, you’ll need to use your Apple developer account.

When an unsubscribed user accesses your site. They are prompted with a notification to allow push notifications. That permission is sent to the server so the server knows to push your notifications to that user. When you transfer to the SendMsgs system the notification is sent to the APN. Then the notification is delivered by the APN to the OS X system where the user will receive a notification that you have previously scheduled.

Chrome and Firefox:

This system works differently in Chrome and Firefox. Chrome recently updated their system so that developers have control over back-end management and offline practices. This update came with the introduction of service workers, a back-end code that, once installed, governs a domain’s webpage. Firefox uses a similar service worker to manage push notifications.

When a user visits your site, a small prompted notification pops up in the corner of their screen, asking them to approve notifications. Once the user agrees to notifications, the service worker starts to run. Each time a user is set to receive a notification, the service worker retrieves the notification, sends it to the subscribed user and then redirects the user to your domain.

It’s important to keep in mind that service workers are only available for HTTPS, not HTTP. For HTTP sites, you’ll have to use a different, third party domain. So, instead of having the script on your HTTPS site, your subscriptions for http://examplesite.com would be sent to http://examplesite.sendmsgs.com.

As you’re setting up your service worker on your HTTPS site, remember that subscribers are linked to domains. Make sure that you’re starting subscriptions on your personal domain, or a subdomain linked to your site. So, you can set up service workers on https://www.examplesite.com or https://www.blog.examplesite.com. But don’t set them up on https://www.examplesite.serviceprovider.com.

Subscription:

Chrome subscription notifications are run through a configured Firebase Cloud Messaging, or FCM. Because of this set up, it’s incredibly important that you use your own FCM or GCM, Google Cloud Messaging, Sender ID as you set up your subscriptions. If you don’t use your own FCM or GCM Sender ID and try to use a vendor’s instead, your subscriptions will not register correctly and you won’t have control over the push notifications.

When a user allows notification, a personal subscription code is created specifically for that user. The service worker will use this code to send notifications to.

Migration:

Now that you have your shiny new service provider set up, you’re ready to migrate your customers. As you migrate over users, make sure to keep the service worker URL as it is. If it was being accessed like https://www.examplesite.com/sw.js with the old service provider, then the new service provider URL should be https://www.examplesite.com/sw.js . The only difference is the content of the service worker file. Before, it was the old service provider, but now it’s the new service provider. After you’ve done this, all your repeat subscribers will automatically be migrated to the new service provider without any new prompt being shown to the subscriber.

Once you have this set up and the service worker from your new provider is live on your site, new users will be automatically added to that file. For all your old users, they will simply continue to be sent push notifications. They won’t need to opt back into your push notifications since they’re already subscribed and they won’t receive multiple notifications as soon as you’ve fully transferred over to the new notification system.

You can, of course, send notifications from both your old and new tool. But, this may cause complications with old users receiving notifications from your old and new system. These complications can cause more loss in users than you would receive by simply migrating completely to your new system.

Migrating subscribers is an important part at maintaining your engagement with users. Luckily with service workers and APNs, the transfer of power from one system to the next is simple and streamlined. That way, you can quickly get back to business, while keeping old and new users included.

Join the Discussion

Your email address will not be published. Required fields are marked *

arrow