OneSignal's CEO, George Deglin, goes over how upcoming changes to browsers like Google Chrome will affect web push notifications. The transcript of the webinar can be found below. Register for our webinars today!

Overview of Upcoming Browser Changes

[00:00]

Cool. So, as most of you probably know. This webinar will cover some of the changes happening in various browsers. Some of these changes happen towards the end of last year, and some of them are happening early this year. So, I'll go through the details of the changes, what to expect and also how to prepare yourself to be successful in adapting to the changes in your usage of web push. At the end, we'll have time for questions. So, please keep in mind anything that you might be curious about, anything you want to know more about. I'll make sure to take a few minutes and answer as best as I can. If you have any issues with the webinar or with the audio or anything like that, feel free to write a message into the chat, but I assume it's all working smoothly. So, we'll dive right in.

Cool. So, first, we'll cover a little bit of information about OneSignal for those of you that are more or less familiar. We'll go through the current state of web push. And then we'll go through the browser changes coming to web push this year across Firefox, Safari, Chrome. We'll also cover some best practices in additional resources to help you out. And then we'll have Q and A.

So, first, a little bit about us: OneSignal has been around since 2015. We actually started as a mobile game development studio looking for a good solution to send push notification to our users, with the aim of increasing our re-engagement and not really finding anything that was good for a business like ours. We sought out to build the platform that we wish we had ourselves. It's been very, very successful. Today, we're the most widely used vendor in this space across both mobile notifications, web push, and we recently introduce in-app messaging. We’re approaching almost a million developers on our platform. So excited to be getting close to that milestone. But today, you can see we're quite prevalent in the market.

When it comes to web pushes technology, this was introduced in 2015 as well and it's been adopted very, very widely. Web push is now being used by 4% of the top 100,000 largest websites. It's also being used by 8% of the largest 10,000 websites. So, as you can see, even in just a few years, it's been very widely adopted. OneSignal was one of the first vendors to support it. It's been something that we've been investing in continuing to support better and better. So, now we're the most widely used vendor in the space.

Many websites today have implemented web push by using the native browser prompting mechanism oftentimes right when a user lands on our website. So, you can see an example of that down here where when the website is loaded, you might just see this native prompting mechanism come up.

So, browser vendors have recognized that this isn't an ideal user experience. In Firefox 70, which was released in October 2019, replaced the default "Not Now" option on the Firefox pop up with a button that says "Never." So, that means if you show the native prompt to people that visit your website and they click "Never", you can never get a chance to show them that native prompt on your site again. Instead, users would have to go to their browser settings to enable notifications. So, obviously, that's not as good of the user experience.

There's also a few different changes that they'll be introducing since then and I'll cover those as well. By the way, this webinar is being recorded and we'll be posting it on our website. Also, I think we'll send out a follow up with the video. So, if you want to cover any content later on to share it with your colleagues, it will be available too.

So, let's take a look at some of the changes happening to web push in 2020. So, Firefox release version 72 on January 7th of this year. This version changed the way that websites can prompt for notification permission such that, if you, as a website, ask for permission without a user action, instead of seeing that native prompt like I showed earlier, you'll see a little icon in the address bar like you see up here.

So, as you can imagine, this isn't as visible to users and they're not as likely to click on it and opt-in. Instead, what Firefox is asking web developers to do is to only ask for permission if the user does an action on the page. So, for example, you could put a button on your page. And when the user clicks on it, then you can show them the browser permission dialogue and it will work as before.

OneSignal actually provides a few prebuilt options to make this easier to implement, so you don't even really have to change any code or anything like that. It also had been well tested and look nice so that you can continue to have a good user experience even as you sort of have changed your prompting mechanism, and I'll cover that as well.

Web Push Prompting Best Practices

[05:19]

Similarly, in the Safari version 12.1, which was released in late 2018, they did a similar requirement. In the case of Safari, users actually have to click on the page or click a button somewhere on the page before the permission prompt is shown. So, for the exact same reason, we encourage websites to implement a two-step prompting mechanism that I'll cover.

And then finally, one of the more complex changes that is going to take place is going to be in Google Chrome. This is going to occur in Chrome 80, which is currently scheduled to be released in early February of this year, so in just a couple of weeks. In Chrome, when a website frequently shows the native permission prompt, if a lot of users click "No" on it, which means that their opt-in rate is very low, then users will instead see a quiet notification permission prompt up in their address bar similar to Firefox.

Also, if there are users that have seen a lot of native permission prompts and click "No" across many, many websites, then future websites that ask for notification permission for that user, the user will also see the client of notification permission prompt like you can see in this little animated video.

You might be wondering what does that look like on mobile. So, instead of being the address bar on mobile, it appears as a little dialogue at the bottom of the browser window with "Notifications blocked". Users can still enable notifications by clicking on that dialogue and clicking "Allow". Similarly, users can still enable notifications by interacting with the icon in the address bar, but it does reduce the opt-in rate because it's a little less visible to users when it's shown to them.

So, the reason underlying these changes is that browser vendors have realized that a lot of websites are not using best practices when they ask users for notification permission. They've observed that since a lot of websites ask for permission using the native prompt. As soon as users visit the website, most users click "Dismiss" and it's not a very good user experience.

So, the changes are being put in place to encourage websites to ask for permission in a user-friendly way that doesn't detract from the experience for their website, for the overall user experience, when browsing from the internet. We see these changes as a really positive thing.

Right now, web push notifications, unfortunately, have a pretty negative perception amongst a lot of users because they're seeing problems across a lot of websites in a non-user-friendly way. How are these changes roll out? We expect that the perception for notification will start to shift that users will understand that notifications are something they can easily opt in and out of without being a disruptive experience for them. Also, the quality of the notifications that users become opted into will get better. So, we see this being very good for the ecosystem and creating an environment where more websites can implement web push in a user-friendly way.

So, in order to adapt to these best practices and in order to be one of the websites that benefits from this, there's three recommendations that we have here. The first is, don't immediately prompt users for permission when they first arrive on your website. In particular, make sure not to use the native prompts. Don't try to display that as soon as someone visits your website because not only will that tend to have a pretty low opt-in rate, that's also going to result in users likely seeing quiet prompts in Firefox and Chrome. We're not seeing a prompts at all in Safari.

Next, make sure to wait until users understand the context and the benefit of receiving notifications before you prompt them for permission. And then finally, if you're implementing a two-step prompting mechanism, even though that does get around some of the browser changes that are occurring, we recommend that you've tried that. Make sure to show the initial prompt during a point in the user's journey on your website when they are expecting to see it and they're more likely to opt-in, and I'll cover what I mean by that right there.

So, OneSignal encourages all websites to adopt a two-step prompting mechanism and we've made it very easy to do that. We provide a variety of easy to use permission prompts that you can implement just by changing the settings on the OneSignal dashboard. If you use OneSignal today and you use our typical setup settings, you can just log into our dashboard and switch the pumping mechanism that you're using and you can customize it. You can customize the text, you can implement both a button or a slide or a custom link, a real variety of options for you that you can adapt to your website and customize. All of these prompts and mechanisms are actually available for free to all of our free and paid OneSignal users. There's no additional fee. So, we definitely recommend, if you're not taking advantage of them already today, that you do implement them.

[10:37]

Finally, the ideal prompt to use is probably the Custom Link prompt. That's a prompt where you can put a link somewhere on your web page where users can click on it to opt in to notifications. If they're also opted in, the custom link can be designed so that you can actually also click the link to turn off notifications if they wish to stop receiving them. Now, the nuance here is that the custom link does require a more clear user action. So, you may find that depending on how you implement the custom link, your opt-in rate may go down. So, be thoughtful about how to show the custom link. You may want to show it at a moment in time when the users are most likely to want to opt-in. You may want to take the opportunity to explain to users why they should allow notifications from your website. All these different things can increase your opt-in rate.

The nice thing about using the custom link or this the subscription bell is that the users that do opt in to notifications from your website are really going to be interested in learning about the notifications that you want to send to them. They're going to have a much higher engagement and it's going to be a great user experience for them. This also aligns with the best practices that have been published by Mozilla Firefox and Google Chrome.

We also provide a variety of additional resources and prompts in our documentation at OneSignal. So, as you saw, there's a basic implementation of the slide prompt, subscription bell, custom link or the pop-up prompt. We also provide custom code so you can really fine-tune when these different prompting of mechanisms are shown at what frequency. We've also seen some of our clients when they use [12:25 inaudible] and then giving them a coupon code in exchange for allowing notification from the website.

Another implementation, we've seen our websites to ask for permission only once a user has finished reading the article or only after a user has visited a website a certain number of times. All of these are great ways to ensure that you have a high opt-in rate and a good user experience in your notification permission prompts.

So, summarizing, web push is becoming increasingly prevalent, already being used by 8% of the top 10,000 websites and it will be rapidly growing this year. Many websites are still using the native prompt either with OneSignal or with their other solutions. We definitely encourage users to move towards using the two-step prompting mechanisms that OneSignal offers. The dates for these are coming up. So, Firefox already released an update that is showing quiet prompts for websites to ask for notification permission without user action. In Chrome, we'll release an update that has similar effects in February of this year.

So, as far as best practices go, make sure to switch from using the native prompts to using the two-step prompting mechanism and make sure to not immediately prompt when users visit your website. You should wait until users have taken an action.

I'll open it up to Q and. A. So, if you have any questions about web push or some of the prompting mechanisms that I discussed, please feel free to type it into the chat.

It's like not a lot of questions so far. If you think of anything or if you have questions as you implement the different prompt mechanisms, you can always reach out to our support team.

Constantine asked: Will slide prompt work on the new Firefox version?

Yes. The one single slide prompt works across all browsers, including the new version of Firefox. It actually also works on mobile devices. So, on mobile, rather than sliding down, it will slide up. In our dashboard, we'll show you what that'll look like and you can customize it as well.

Vlad asked: Could you provide some more details on employing the custom link instead of the two-step prompting as it exists now?

OneSignal Prompting Mechanisms

[15:00]

So, OneSignal offers a variety of prompting mechanisms. The slide down prompt, it's very easy to implement. You can just turn it on and users will see a slide down and you can customize the text. But one of the other ones that we provide is a custom link. So, this will give you code for a button that you or your developers can play somewhere on your website. You can put it at the bottom of your website or at the bottom of an article. You can put it on the side. It's really up to how you want to design it. It works a lot like our other prompts. But it gives you more control over where you want to put it on your website.

Skylar asked: are there any updates related to iOS web push?

Unfortunately, there hasn't been any news on that lately. However, when we think about some of the changes happening with web push more broadly, some of the changes that these browsers like Chrome, Firefox, and Safari on desktop are making, we see these as being a positive thing for the ecosystem and something that may encourage Apple to implement web push on iOS in the future. I think Apple cares a lot about user experience and they don't want users to have a bad experience on mobile when they browse the websites and maybe getting prompts that they don't want to see. So, perhaps if these changes with Chrome and other browsers have a very positive effect, it will encourage Apple to also implement web push on iOS. That's it. Apple isn't very transparent about their plans and sometimes they take a little while to make these changes, but it may still be awhile before we see any updates.

Antonio asked: Can I download this presentation?

Yes. We'll make it available later today on YouTube and we'll also send it out by email to all the participants in the webinar.

Madonna asked: Do you know how low the opt-in rate has to be to change over from the normal prompts to the quiet prompts?

That's a great question. That is actually something that Google has not yet published and it will be something they refine over time. We've actually looked at the code of Google Chrome to try to better understand these changes. This is something that's decided on Google servers. We don't know what they've said it to yet. That said, one of the things that we have noticed, and that is clear from the coaching that they're making, is that if a user visiting different websites, sees the native prompts on three websites in a row and clicks "No" on those three websites, then on the fourth website, even the fourth website implements a two-step prompting mechanism, they will still see the quiet prompt. Now, we don't know exactly how many users this will effect because it's possible that users will be seeing the quiet prompt on those other websites and they won't be clicking "No", but I think we'll have to see how that happens over time.

One of the nice things though is, if you do end up getting the quiet prompt on your website because your opt-in rate has been too low, Google has implemented that mechanism where some users will still see the native prompt. If we're not with those users, click "Allow" and your opt-in rate goes up. They'll restore your website to having the normal prompting permissions over time.

Similarly, it's not quite clear exactly what the rates have to be. We definitely encourage people to implement a two-step prompting mechanism or an improved prompting mechanism today so that they don't risk falling into this bucket. But if for some reason it does happen and your website does get penalized, you can still fix it and it'll resolve itself over time. I know that's a little bit complicated. We've shared a little bit more information in our blog. Also, Google has published a couple blog posts about it as well. You can search on the internet and get some more information.

Someone asked if they can use notifications to get people to register for webinars on their website. Yeah, that's absolutely possible. In fact, that's one of the things that we do on our website is you can try out notifications, web push notifications on our website. We also use that as a way to notify people about upcoming webinars.

Crystal asked or mentioned that they implement a custom link on their website, but when a person clicks on it, it isn't clear what happens. There isn't a message after the click indicating that the person has been subscribed or message telling them that they are already subscribed, for example.

So, if the custom link is working properly, the custom link text should actually change based on user's permission that the user has not granted it. You can set the text to what you want. I think the default is "Click here to subscribe to notifications". If the user has allowed notifications, the text is "Click here to turn off notifications". You can customize that text to do like, when the user allows notifications, we have the ability for you to send them a welcome notification. So, they have a notification that they get as soon as they subscribe, "Thanks for subscribing." It's also customizable.

[20:13]

We also have a callback in our JavaScript code so that if you would like to make some changes on your website to users that are opted in the notifications to say, "Thank you for subscribing on the website," or something like that, you can do that by implementing that connector through our JavaScript API.

Amanda asked whether the slide prompt or the bell have styling to match your brand styling.

Yes, absolutely. The slide down can have a custom image that you upload and we definitely encourage you to use an image that's relevant to your brand. You can also use CSS to style it. So, if you do want to change the colors, the size, things like that, you can use CSS to change that. We also have a bell prompting mechanism and you can customize that as well. You can customize the position, the color, and the text to make sure it matches your brand. finally, if you want to get even more customized with it, you can implement the custom link, which you can customize a lot or even you can use our JavaScript API to use none of our prompting mechanisms at all and implement your completely own prompting mechanism. It's really up to you, but of course, it does require a little bit more web development work.

Raquel asked: How do we guarantee that you have a good notification delivery rate?

The best way to do to make sure delivery rates are good are, make sure that the users that are granting you permission are expecting your notifications. That's really probably the best thing you can do. After user has subscribed, delivery rates, at least once a month, are 100% reliable. If it is possible to reach a user with a web push notification, then they'll receive it. That said, there are some cases where a notification doesn't get delivered to a person. It could be because they cleared their browser settings completely and they have no longer granted permission to your website. There are rare cases where there could be a network issue that the user has and they might not see it, but these are pretty rare. Most of the time, if a user is subscribed to notifications and you send one to them, then they'll receive it.

One more note there, I guess, is users can turn off notifications from your website, of course. So, make sure you're sending good content and that'll help contribute to having a lower opt-out rate.

Eros asked that one of our best practices is that websites don't immediately prompt users when they arrive on their web page. But what about if users are visiting the website with a lot of returning users and users that are used to being connected and updated when there's new content, wouldn't it be good to instantly invite them to turn on push notifications?

Yes. That might be the right thing to do. In that case, we would still strongly encourage you to use a two-step prompting mechanism, but you may want to show the two-step prompt as soon as the user visits the website. We see this. I think there's a lot of websites. I think a good example would be Facebook, for instance, where they implement web push and they ask users right when the person, like fans on Facebook and is logged in because most people probably do allow notifications from Facebook. That's it. Even Facebook, I'm sure, is going to implement a two-step prompting mechanism. So, what will happen is probably you'll visit Facebook, you'll see some Facebook dialogue that'll say, "Do you want notifications?" You're like, "Yes, I do." And then they'll show you the native prompt. So, we definitely recommend following that practice as well.

Jonathan asked: Do you have any idea of the anticipated loss of opt-in volumes on average?

Not at this point, unfortunately. It's something that we've looked at a little bit, but it's varied a lot from one customer to the next. So, for some, they haven't had any loss. For some, they've seen much higher loss. I think the difference is a little bit based on the website that you have. So, for example, if you have a website where most of your subscribers are people that opted in on accident and probably don't really want notifications from you, you're going to have a higher loss of opt-in rates. Whereas if you're website where people frequently visit or they like the content that you're publishing or they would like to receive notifications from you there'll probably be no loss. In fact, you might even experience higher opt-in as users develop a better perception of their notifications, in web push notifications, the channel.

[25:01]

So, it depends a little bit on the website. Of course, it also depends on your implementation. You may want to experiment with a couple of different notifications and see what results in higher opt-in rates. Our SDK provides callbacks. You can send events to your analytics system and track what your opt-in rate is over time if you want to fine-tune it.

Bruce asked: Is there a risk about being banned by having a two-step subscription prompt?

No. At this time we haven't seen Google take any action against websites based on the content that the website is showing within the site itself. I think Google has tended to shy away from analyzing websites based on the user experience. That website is like [25:46 inaudible] as long as that website is not doing something that it's very misleading to users. That's it. I think the greater concern, I don't think there's any risk of really even like Google taking action on you. I think it's more about making sure that your website has a positive user experience for your users. Also, that you're taking the steps to ensure that your opt-in rate stays good even suddenly, browsing changes occur.

One of the questions asked is: If other sites are doing it incorrectly, then as a result of this, you can actually suffer due to it?

As I mentioned that if users are getting annoyed by notifications on the websites, then they might start seeing the quiet prompt on your website. It's actually true. The idea that Chrome had, or one of the realizations that they had is there are some users that really don't want to turn on notifications across many websites and they don't want to see that prompt frequently and they're clicking "No". Therefore, the balance will take steps to not show them as frequently. We actually don't think this will affect too many users. I don't think it's Google's intent to have this affect many users.

One of the reasons why I think the impact of this is going to be lower is because these other websites are actually going to get analyze themselves and users won't be seeing notification prompts on them. It doesn't see the quiet prompt instead. Therefore, they're not likely to ever have the opportunity to click "No". Therefore, they'll continue to see the native prompts when a website shows that in response to a two-step flow.

Time will tell a little bit about what the percent impact of this is. But we've been in close contact with Google. Their intent is definitely to make sure that you just have a good experience and also that websites are implementing notifications in a user-friendly way and don't experience any loss in the subscription rate. I think if it doesn't go that way, we will take steps to refine their implementation so that websites are not unfairly penalized.

Someone asks whether OneSignal can be used on a click funnels registration page.

So, I'm not familiar with click funnels. I think that'd be a good question for our support team. They can take a look and provide some additional details.

One of the questions asked is: If you use a custom link, does it still stand that it should appear after the user takes an action on the website or is the custom link enough to be okay with Google because the link is definitely sufficient on its own?

Because it's a link that you can put some on your website and users have to click on that link where the prompt is shown, then that's perfect. That'll work just fine on its own.

Amanda asked whether we have examples of the custom link implemented on eCommerce sites, [28:47 inaudible] homepage, product listing page or product detail page.

I don't have an example that's coming to mind right now. But if you reach out to our support team using that chat widget on our website, I'm sure they'll have some examples for you. Also, you can also find some of the best practices on our blog, which walk you through different ways to implement it.

Constantine asked whether it be possible to get the location of the subscriber by more than just the country. For example, the segments on a city.

That’s not something that's built into OneSignal today. If you do have something that you can implement on your website to get that information yourself, either if the user provides it to you or there's some third-party services that help you estimate user locations, you can implement those and then send us that information as a user tag. So, we know that some of our clients do either ask either their location or they use a GoIP location service that estimates where that user is, and then they provide that as the OneSignal tag and we can target notifications based on it.

One of the questions asked: Do you have any statistics through different categories? What the click rate percentages or I'm thinking you might also be thinking about opt-in rate.

[30:13]

I don't have those off the top of my mind. I think it really does vary quite a bit on the website. I think of the things that someone mentioned earlier is you might have a website that has tons of repeat visitors, the content and very relevant visitors, and maybe people have a real clear interest in having notifications. In that case, that the opt-in rate and click rate will be very high. If you have a website where the content is lower quality, you'll have to be more [30:42 inaudible] for promotion and you can expect a slightly lower often rate. That's why I think web push notifications are still a great re-engagement channel for all websites. The implementation and opt-in rates will just vary a little bit based on content.

And then another question here, I think the last questions was: According to the Google blog post, you can automatically opt-out it by prompt if you improve the opt-in rate. What's the ideal opt-in rate?

You're right. If your website is being shown in the quiet prompt to your users, but your opt-in rate greatly improved, then it'll go back to the normal prompt.

The question I guess is, what's the ideal opt-in rate? I'm not sure actually. What sort of criteria Google is looking at for the ideal native prompt opt-in rate. That said, as long as you're using a two-step prompting mechanism, then your opt-in rate should be very, very high, right? Because users don't want to opt-out. We'll just close the initial part of the two-step prompt and they won't have an opportunity to click "No" on the native prompts. So, you really don't have to worry about it if you're implementing a two-step opt-in. If you're talking to try to just show the native prompt without two-step prompting, it's almost certain that you're opt-in rate is going to be very, very low. You'll probably get that. But I don't know what the exact numbers are there at this point.

A few people have asked for a copy of the webinar and we'll make sure to send that out. I hope all the information was helpful to all of you. If you have additional questions, feel free to review the webinar again, contact our support team, or take a look at our blog for more details.

Thank you again, everyone, for joining and I look forward to seeing all of your web push implementations. If you have any additional questions, I look forward to helping you out more.