5 Critical Mistakes to Avoid Before Starting Push Notifications on your Website
A list of 5 most critical mistakes done while making the decision on browser push notification provider and setup.
1. Using a Free Service Without Realising your Customer Data are Being Sold and Becoming Accessible to your Competitors!
According to the main market research tools, the push notifications provider serving the most websites in the market is a completely free service. It sounds great, right? Why would you pay for it, if there is a similar one for free?
But have you ever thought why could it be free, while others are paid? You should! As they say, “There ain’t no such thing as a free lunch”. When you are using one of these completely free services, you allow your provider to collect & sell all the data on your website or app including all the personal data of your own customers including their e-mail addresses, cookies, etc. Technically, via the javascript code that you install on your website or via the SDK that you install on your mobile application, the provider is able to collect all these data.
The worst is that, as you gave the permission to sell your data, they can sell the data of your customers on any platform including DMPs and even your direct competitors can access your own customer data easily. Instead of taking advantage of using a free tool, you can lose all your customer data to your competitor.
The answer lies behind the Terms of Services that you sign when you start using the service. Here is an example:
This data collected includes: End Users’ mobile advertising identifiers, such as Apple IDFAs and Android Advertising identifiers; End Users’ email addresses End Users’ IP address, device push token, precise location (e.g., GPS-level) data, network information, language, time zone, product preferences, and privacy preferences. The Parties shall jointly own the SDK Information, and each Party shall be entitled (without further compensation to the other) to use, share, market, license, sell, store, and otherwise exploit the SDK Information to the maximum extent permitted by law, which shall include using the SDK Information for cross-app, cross-device, and other interest-based advertising, analytics and market research.
2. Collecting Subscribers Under the Sub-Domain of your Service Provider Instead of your own Domain
In order to use web push notifications, browsers need to install a service worker, which is a script that your browser runs in the background. They require HTTPS setup on your server, by default. Today thanks to Let’s encrypt you can have a TLS certificate for free, and setup on your server not more than 5 minutes.
Moreover, browsers use the web push notification protocol in order to validate the ownership of the subscribers to that domain. In order to fulfill this, you had to add a file named “manifest.json” to the root folder of the website in the early versions of Google Chrome; but currently there is also public/private key encryption as an easier replacement.
But apparently, most of the service providers offer a totally contrary solution, that uses another domain they control as the base domain where the subscribers are technically collected at and bound to. It could be fair enough to offer this workaround solution only to the websites who don’t have SSL certificate. But most of the service providers, offer this as their default setup that you cannot change unless you request for it.
So basically, you are forced to collect your subscribers under a subdomain such as mywebsite.os.tc or mywebsite.myprovider.com instead of mywebsite.com. This might sound technical and trivial, but it is massively important.
If you collect your subscribers under a domain which you don’t own, all the subscribers from whom you asked permission WILL NOT belong to your website, they will belong to the website of your service provider. It will be impossible to migrate these subscribers to your own domain and it will mean the loss of all the collected subscribers if you’d like to change your provider. To sum up, you get stuck and stay desperately at the hands of your service provider forever.
If you are already using push notifications on your website, check which sub/domain is shown on the native opt-in box. If that’s your domain, it’s fine. If it’s another domain, change your provider ASAP before you collect more subscribers on somebody else’s domain.
3. Directly Requesting Native Subscription and Being Blocked by All Your Future Returning Users
There are some different methods that you can ask your users to opt-in. But here are the most common 3 type of methods:
A) Direct Native Opt-in Box: In this method, you basically show the native opt-in box of the browser directly without any other context.
B) Notify-Box or Similar: In this method, you show a pop-up to explain to the users why they should opt-in to notifications and if the user clicks on yes, then triggering the native opt-in box.
C) Custom Button or Event: In this method, you trigger the native opt-in box after the user clicks on a custom button or check-box that you created.
It is a fact that if you trigger directly native opt-in box of the browser, you get a higher opt-in rate in the short term because it requires just one click while the other methods require two clicks. However, for all other users who are not ready to opt-in at that moment, they would click on the negative choice on the opt-in box, which is to “Block”. As a result, you lose the chance to ask these users to opt-in for ever. This can be summarised as giving up a higher number of subscribers of the long term for the profit of the short term. That’s why for the benefit in the long term, it makes more sense to be patient and ask your users to opt-in after giving some context by using Notify Box or similar.
4. Choosing a Service Provider without Dynamic Personalisation and Automation Capabilities
Sending the same push notification for large groups of users can be still useful for certain type of websites such as newspapers or digital media, who don’t have any customer information. However, there is a huge opportunity cost not using dynamic personalisation for any kind of website who have the information about their customers such as e-commerce, travel, B2B, etc. This is due to the fact that notifications which are personalised with dynamic parameters -such as customer name, product/service name, product/service category, etc.- have much higher Click Rate and lower opt-out rate.
The opportunity cost is even higher for the case of not using notifications triggered automatically by user behavior. Websites can at least multiply by 3x their revenue from push notifications by using triggered notifications such as cart abandonment or retargeting notifications. Moreover, there is a time cost of sending push notifications manually.
5. Trying to Develop an In-House Push Notifications Solution
Most of the service providers of push notification marketing have periodic subscription fees (monthly / yearly). Some of the companies consider if they should build their own push notifications solution in-house, just to get rid of this recurring cost. At first glance, it might sound like a very cost-effective option. But in fact, it is definitely not. Why?
- It’s not the expertise of your IT team and you have to allocate the time and effort of your valuable IT resources for months, and it will cost a lot of money.
- You will be late for months to start collecting subscribers and the opportunity cost of this is higher than the cost of taking the service from a provider.
- It’s also obvious that the solution to be developed is going to under-perform compared to your competitors and market average.
- It won’t be cost-effective for you to develop for other browsers. You would develop for only Google Chrome and you won’t be able to reach half of your users.
- It won’t make sense for you to develop state-of-the-art capabilities such as personalisation, automation, analytics, custom events for a single website.
That’s why it makes much more sense for each of your finance, marketing and IT departments, to use a service provider rather than building an in-house solution.
This article is originally published on the Blog of Frizbit.
