If you ask a room full of mobile marketers- what’s the most powerful engagement channel they have, the unanimous response would be- push notification.
Yes, the ability to push messages to the user’s device when he is not actively using your app was a critical mobile feature that was missing from the web. So, when web push was first introduced by Google for Chrome in early 2015, it witnessed enormous adoption by marketers, especially from the publishing industry.
What makes Web Push the new Retention Marketing favorite?
We have covered this in detail in our blog on WebEngage Monk. I will add the gist here.
- It’s easy to set up
- It kills the need to launch an app just to be able to send notifications to the user.
- It doesn’t carry the risk of ending up in the spam folder or blocked by ad blockers.
- It can be targeted to an enormous degree natively or by a third party targeting engine (like WebEngage).
However, to be able to send notifications, a web-app has to take explicit permission from the user via an opt-in prompt as shown below.
Web push’s opt-in prompt cannot be invoked once user ‘denies’ it
Now, amidst the immense potential that browser push presents to marketers, it also comes with a challenging drawback. I have discussed them below:
Push API gives only three options to users to engage with the prompt:
- Default– When the user ignores by pressing ‘escape’ or by canceling the notification
- Granted– When the user clicks on ‘Allow’
- Denied– When the user clicks on ‘Block’
However, the catch is that once the user clicks on ‘block’, browser API doesn’t allow you to launch the opt-in prompt again similar to iOS permission dialog box which cannot be invoked again once the user clicks on ‘Don’t Allow’.
Now, for the user to reverse his decision, he has to go through a complex UI and allow notification manually, the probability of which is the guess of any pragmatist. So, technically a user clicking on ‘block’ entails that you lose the channel of web push forever to engage with him.
Now how to crack this? Do the right thing. Send targeted opt-in.
Why companies are not implementing targeted opt-in?
It’s a no-brainer that a targeted opt-in would perform way better than a non-targeted one. Yet, it is very common for websites to pop opt-in prompt on the user’s face right when logs into the website. The untimely, untriggered opt-in naturally leads to high rejection rates and ultimately poor UX.
However, the publishers can only partly be blamed as almost all the standalone push notification engines don’t offer deeper segmentation capabilities. In fact, they don’t provide any option at all to target your opt-in on the dashboard. Segmentation is not their primary USP.
What these engines essentially do ,instead of providing targeting capabilities, is provide an API which lets you write a script to create targeting rules yourself. (not all of them do this either)
So, in order to layer your opt-in with any rule, you have to write the script yourself which entails involving dev team, tiresome deployment phases and annoying need to write a script for every rule you want to create.
Introducing ‘Opt-in Rules’
At WebEngage, we introduced some new features for web push that would allow our clients to target their opt-in prompt in the most efficient manner possible. Using those features, a marketer would be able to ask for permission for web-push from the user when he is most likely to say yes.
Let me walk you through the targeting options one by one:
1. On specific pages
This allows you to target your user when he lands on a specified URL. Via this option, you would be able to ask for permission only on those pages where the likelihood of user allowing is the most. For instance, nudging users
- For promotional notifications when he is on checkout completion page.
Note- You can do launch the prompt both ways. Either, you can you launch it directly on the checkout page or, you can layer it with a pre-permission dialog box. We went with the former way in this case.
- For blog updates when the user lands on help page and so on and so forth.
- For product updates when the user is on the product search page.
2. Time delay
Time on page is an indicator of the user’s engagement level with the website (obviously not the only one). So, this targeting option allows you to fire the prompt when a user spends a certain amount of time on the page. This option, when coupled with the previous one, can create very powerful use-cases which could enormously increase the probability of user opting in. For instance
- Targeting users who have spent more than 2 minutes on the product page.
- Nudging users for blog updates who has spent more than 150 seconds on help domain.
3. On scroll
This allows you to fire the prompt when a user scrolls the specified percentage of the page. This can be extremely useful to the single page web apps or websites with infinite scroll functionality, which are mostly SaaS and news websites respectively.
Again, WebEngage allows you to couple any of the aforementioned rules and the one below to create a customized rule.
4. On event
Events are the actions performed on the website- either by the user such as ‘add to cart’ or by the system such as “tracking user’s inactivity on check-out page”.
By using events as a behavioral trigger, you can conceptualize infinite ways to nudge your users for web-push. You can fire the prompt upon the completion of any critical event that increases the likelihood to allow. For instance,
- You would able show opt-in to user when he submits a subscriber form
- When the user creates an account on the platform.
- When the user adds more than x items in the wishlist.
And there could be countless such use-cases, varying from industry to industry, with a solid assurance that the opt-in rates are going to be high.
That’s all. Please try these features out and share your feedback either in the comment or firstname.lastname@example.org.