Deep Engagment with Push Notifications (Progressive Web App Summit 2016)

Deep Engagment with Push Notifications (Progressive Web App Summit 2016)


Hi. My name’s Owen. And I’m a product manager on
Chrome’s Push notifications. So just before we
get started, I feel like now would be a good time
to clarify that we actually have two new features in
browsers, both with the name Push. I think it’s said that there are
three hard problems in computer science– no, two hard problems
in computer science– caching, naming things, and
off by one errors. And so I’ve think we’ve fallen
into the naming things trap here. So there’s HTTP2 Push, which
allows servers to send down data to the client before
they even expect it when rendering a page. And then we have web
Push notifications, which are about sending
notifications to our users. And that’s what we’ll
be focusing on today. So I’m super excited
that we’re all here in this room full of
amazing web developers and, I think, at last count,
five different browser vendor teams to talk about
progressive web apps. These are web apps that are
reliable, fast, and engaging. And I’m going to be
focusing on the third point today, engaging, specifically
sending Push notifications to your users. So Push notifications on
mobile aren’t anything new, but I’m really excited
that we finally have access to these as web developers. I’m sure there are a
number of you out there that have built great
mobile web experiences, and then had to wrap it in
some kind of Cordova wrapper, and suffer the friction
of an app store just so you can get that
notification capability. So our shackles are now free. We can now go ahead and do this. I think that’s really
exciting, especially when you look at the
services and apps that have been successful on mobile. And just look at the
top ones, and think about how many of them are
fundamentally successful, in part, because of
Push notifications. And we now have
the ability to take advantage of that in the web. And so there’s a bunch
of new opportunities that have emerged here
that I’m excited about. And this can be really
huge for business, as well. For example, if we
take a look at Jumia, which is a leading
e-commerce company in Africa, they had a problem
and their problem was that one quarter
of their users were adding items to their
cart, but then not actually checking out. They were abandoning that cart. And the site tried to deal with
this by sending those users emails and reminding them. But getting a user to type
their e-mail in on a tiny screen is really difficult. And then
the open rates on those emails were extremely low. So it’s still early
days, but Jumia have implemented Push
notification on the mobile web. And they found that
their notifications get a 38% open rate by
users, and that users that have enabled web
Push notifications convert on those previously abandoned
carts at a nine times higher rate. So I think these kind of
results are really exciting. OK, so, Push notifications is
this amazing new superpower that we have on the web. But everybody knows
that with great power comes great responsibility. So this begs the
question, what makes a great, engaging notification. And so we believe that great
notifications are timely, they’re relevant,
and they’re precise. And so for these penguins
here, a Push notification letting them know that there’s
a leopard seal behind them would really change the
course of their day. And so, as you’re designing
your Push notifications flows, just think about whether
what you’re sending is important enough to
warrant an interruption. Would you want to be
walking down the street and feel your pocket vibrate? And really use
that to guide you. And so let’s break
this down further. I said notifications work
great when they’re timely. So try and use
notifications primarily for time sensitive
events, especially if these are synchronous events
that involve another user. For example, being
sent a chat message. There’s another person out there
waiting for you to respond, and it’s something
that you care about, and it’s important that you
see it within the right time. So that’s a great use case. Calendars is another
fantastic use case, you know. You’re about to be
having a meeting, and you need to know
where you’re going, and be reminded to go there. So timely is really key. Secondly, being precise. Notifications should contain
all of the information that a user needs to
understand what just happened, and to take action
on it, if possible. And thirdly, relevant. It’s important to users that
the notifications they’re seeing are from people that they
care about, and about things that they care about. OK. So let’s give this a go. Here’s one example notification. What do we think about this? I think this is
pretty good, right? It’s timely. You know, I’m probably
at the airport and about to get on a plane. It’s precise. It tells me my flight number. It tells me when the flight
has been scheduled to. And it’s relevant. It’s my plane. It’s my flight. It’s super important to me. So I think that’s great. How about this one? Your credit card has
been compromised. Well, I think this
could have done better. You know, B minus on our scale. So it’s timely. It probably just happened. And it’s relevant, right? It’s my credit card. But it’s not very precise. Which credit cards? Why was it compromised? What’s going on? What action do I take? And so, if we re-imagine
this notification, we can add some
extra information. Let the user know that a
suspicious transaction has occurred, and give them buttons
that let them take action, and provide feedback
to the bank. OK. How about this one? Awesome Chat App. You have a new message. So, Awesome Chat App,
your notifications are not so awesome. It’s probably timely. I expected a message
was sent to me, but it’s certainly not precise. And who can say if
it’s relevant, right? Who knows. So we redesign this. And we get Jake says, I
heart service workers. Incidentally, I
think there should be an award for getting his
profile picture in the most number of talks today. I think he’s maybe at
three or four so far. So that’s a great
way to redesign this. How about this one? As a side note,
I think if Google does launch a
self-driving car service, we should definitely
call it Goober. And so, this one is great. It’s timely. You know my car is arriving. It’s precise. It’s telling me where
it’s arriving at. And it’s relevant. It’s my car. I’m going to get
in and drive away. And then here’s probably
the worst possible example I could conceive of. This is none of the above. And the risk here, really, is
that if you send notifications to your users that
don’t provide them value, that distract
them or spam them, they’re going to turn
off notifications. And then you’re going
to lose the ability to get the value from that
interaction in the future. OK. So we’ve talked a bit about
the kind of notifications which are good for our users. So now let’s take
a look at the flow, and really how this
works on a high level. So Push notifications on the
web is built on service workers. This is probably a
theme that you’re seeing emerging throughout the day. I think it talks to– it talks
to how service workers are becoming this fundamental
capability that– allowing us to extend the platform in all
these new and interesting ways. And so, once you get
everything set up, which will go into, sending
a Push notification, the flow is roughly
that your site first makes a network request to a
Push subscription endpoint. And that’s managed by
the Push server, which then magically wakes
up the user’s device and manages to fire an event
into their service worker. And then that service
worker runs some code, and it uses the
notifications API to show a notification to the user. So let’s break that
down a little more. The first thing that happens
when a user lands on your site is you have to check if the
user’s already subscribed, so you know whether to
show them the opt-in flow. Once you’ve checked, if they
haven’t already opted in, you just wait until
it’s a good time. Maybe the user has just
done a search for flights. And you give them a
button that says, get notified when the price drops. And then once the
good time comes, you ask the user to subscribe. You explain the feature to the
user that they’re opting into, and then you eventually show
them the permission request. And then, once you’ve
subscribed the client, it generates a
subscription object. You’ll then pass that
subscription object up to your server and save it
somewhere in the database. And then on your server, when
you’re ready to send a message, you just generate the message. You send that message
to the endpoint that you were given previously. And that endpoint–
essentially the Push servers keep a persistent– one
persistent connection open with the device. And then they use
that connection to tell the device to
wake up the browser, wake up the service worker. And so this part is
special because it means that we’re sending
Push notifications, but the browser
doesn’t even have to be running on the device. The site doesn’t
still have to be open. It doesn’t use much power. And so it’s a really great
performance feature, as well. And then the Push message
is received by the browser. And when the Push
arrives in the browser, it wakes up the service worker
and fires an event into it. Your code then handles that
event and decides what to do and shows a notification
to your user. Easy, right? OK. So now let’s take a look
at subscribing for Push, and when you should prompt
your users to opt in to get Push indications. So I think that this
step is super important because if you’re going
to be successful with Push notifications, you have
to get users to turn them on in the first place. And so it’s really
important to focus on this step in the process. And I think it’s important
to be clear and intentional and treat this like any other
part of your UX process. The key is not to just add a
permission prompt on page load without thinking about it. So make sure that
the user understands why they’re being asked. Make sure that they understand
what they’re opting into. And so, we’ll take a look at an
example of the Weather Channel. So the Weather Channel
have built this page where you can choose to
enable Push notifications and control some options. So I think this is great
because it’s specific. You know, you have this page
where you know what’s going on, you have all of the
context that you need. And the permission request
itself is user initiated. So when the user
goes ahead and checks that box saying activate
browser notifications, they see a permission request. No surprises, right? They’re very likely to
click through at that point. So that’s great. And we think it’s really nice
how they give users options. I can opt into a breaking news,
or government issued alerts. If you’re never sure
about what users are going to want to enable,
just give them options, and let them decide. OK. So we’ve talked about
this on a high level. And we’ve talked about UX. Take a look at the code, and
how we actually subscribe for Push notifications. So the first thing
I said that we’d do is we check whether the
user’s already subscribed. And because these are
progressive web apps, the first thing
that we do is verify that service workers are
available on this client. If their service
worker is available, we go ahead and register
our service worker. If a service worker’s
already registered, this will just return
with the registration object of that service worker. And then we can call
Push manager subscription to get a Push– the
existing Push subscription for the user if one exists. And so now we know whether
they’re subscribed or not. We can store this in a
cookie, use it later, or use this to decide whether
to show them an opt in flow. OK. Now we’re deciding to subscribe
the user for the first time. So, again, we’re going to get
the registration of the service worker that we’ve
registered, and then we call pushmanager.subscribe. Essentially, this is
setting up that connection with the Push server so it knows
how to talk to this client, it knows that this
service worker wants to be able to be woken up. And then there’s an
option here, which says, user visible only true. Essentially what
we’re saying here is we’re promising
to the browser that when we send a push
message down to the device and our service workers
runs the background, that the user will
see something. So we’ll either show
them a notification or maybe, if they’re already
looking at the web app, then we don’t need to do that. And the idea here is
allowing– making sure that browsers can show that
permission request saying, this site wants to
send you notifications. Not this site want to
run in the background permanently on your
device silently and use all of your battery. So that’s why that exists. And then, once you’ve
subscribed– actually when you call
subscribe, that will be the point where
that permission request is shown to the user. And if they accept that
request, the promise resolves, and we get back a
subscription object, which we can then
send to the server. And, of course,
we catch the case where they deny,
and we can decide what to show them in that case. So, I recommend
you all check out the propel sample code up
on the Google Chrome section of GitHub. And this shows some
great sample code to manage those
subscription states, gives you a really nice
API to manage them. OK, so next, once
we’ve subscribed, I said you get that
subscription object. What is that? What does that look like? So this is how it looks. It essentially gives you all
of the information that you need to identify the
user to the Push server, so it can wake up
the right device. It starts with an endpoint. This is like a magic URL. It acts kind of like the user’s
phone number or email address, but for Push notifications, as a
way of identifying and reaching out to them. It starts with the URL
of the Push service that this operating
system uses, in our case here, Google Cloud Messaging. And then it has a long
string of random letters that identify the current
user to that Push service. It also includes a bunch
of encryption keys. And this is so when
you’re sending data down to the user’s device, so you
know what notification to show, that message can be
encrypted and can’t be read by anyone in the middle. OK. So let’s take a look at sending
that message from the server. There are two ways that you
can send a notification. Firstly, there’s what
we call a tickle. This is essentially
a Push message which arrives with no data. So the service
worker gets an event that says a Push
message arrived, but it doesn’t get to
find out what happened. And the second kind
is Push with payload. This is where you
include data, you let it know what
happened on the server, and why it’s being woken up. And if you’re sending payload,
it’s encrypted with the keys that we talked about earlier. And so, let’s take a look
at actually sending those. Just before I do,
it’s worth calling out that the sample code I
show here is for using the web Push protocol. So the web Push protocol is
about to start working around now in Chrome, but as the
standard’s been evolving, and the implementation
has been evolving, it hasn’t been the exact
same implementation in older versions of Chrome. So there’ll be a
link at the end which shows you how to do a backwards
compatible implementation. But I’m going to focus
on the future facing and what’s really going
to be happening from now. So when your server wants
to send a push message to the user, it sends a request
which looks roughly like this. It’s a put request to that
endpoint we were given earlier. It has a time to live,
which essentially tells the Push server
how long should you keep trying to send
this to the device for, and give up if it’s
taken more than two minutes. It includes the content
type and encoding. And then it includes
the public key and salt used to encrypt the
message, a vapid signature, and the encrypted payload. I’m not going to go too
much into the details on those last
encryption aspects now, but, again, there’ll be
a link at the end which gives you the full
breakdown of how this works. And at this URL, you
can find sample projects to handle the encryption and
message sending on the server side. We have them in Java,
in node.js, in Python. So go and take a look. This is kind of contributed
by the open source community. There are contributions also
from Mozilla and from Google, and they’re a really great
set of libraries that will get you up and running. OK. So now we’ve worked out
how to subscribe the user, and send a Push message. But how do we receive
it on the client? What does the service worker do? So in your service
worker, you just add a new event listener
for a Push event. When that event fires,
you call this magic method called WaitUntil. So WaitUntil– I had to
look at this a couple times the first times I was trying
this– WaitUntil essentially says, I’m going to run
some code for a while, it’s kind of asynchronous,
and I’ll let you the browser know when I’m done. And when I’m done,
you can go ahead and kill my service worker. I don’t need to be kept running. So this allows us to be very
performant and efficient. And you basically pass
into WaitUntil a promise, and you resolve
that promise when you’re finished
doing the work, when you’ve showed the notification. So here we go ahead and we
just generate a notification. And this returns
that promise that will resolve when
it’s been shown, so the browser can
kill the service worker at the right time. But actually if you look
here, this notification I’m showing basically
breaks all the rules we talked about earlier, right? It’s static. It doesn’t say anything useful. So how do we read the payload? How do we know
what we’re supposed to be showing the user? It’s pretty simple. So you just check if
event.data exists. If it does, you call .JSON to
convert it into a JavaScript object. If it doesn’t exist,
then that’s the point where you want to make a
fetch request to your server to ask, hey, what happened. What should I be
showing the user? And then once you
have that data, you, again, just call
show notification with the correct
title in the body. And note, in this case, that
we actually need to return that show notification to
the event .WaitUntil, to make sure that the browser
knows that we were still doing work. If you don’t do this, you
might notice in Chrome that you get a little
notification saying, this site updated in the background. That generally happens if
you resolve the promise to WaitUntil before you show
the notification, because that’s Chrome checking and saying,
hey, did you show notification. Oh, they didn’t. We’ll share one on their behalf
to make sure the user knows. That’s the user visible only
true thing coming into play. So we also have support for
action buttons on web Push notifications. These make it easy for
users to complete a task without even opening the app. Here we can see that a user
can confirm their reservation. You could also use this to
have users like or retweet something, to pay
a bill, increase their bid on an auction. There’s many interesting
opportunities there. And using action
buttons is super easy. In the show notification
call, you just pass in an action’s object. And you give the title, the
icon, and this action string key thing that
we’re going to use to recognize when the user
taps on one of those buttons. So then if a user does tap on a
button or on the notification, a notification click
event will be fired. And that’s where we’ll say,
hey, if the action was liked, then we’ll reach
out to the server and let it know
that it was liked. And if there’s no
action, then we know that they just tapped
on the notification. In this case, we’re just
going to open a new tab to the notifications
page on the server. OK. So we’re almost there. We’re just going to wrap up now. And I don’t think that we can
do this talk without talking about browser support. So it’s worth
noting that web Push notifications are
already supported today in Chrome and Firefox. I was excited to see that Opera
shipped web Push notifications last week. Samsung browser shipped web
Push notifications earlier in browser 4.0. And I read last week that
the Edge team have just announced that they’re
currently implementing Push notifications on the web. And, at this point, you might
be looking at and saying, that looks great,
but there’s maybe one missing that we care about. What do we do? And I think that there’s
a big takeaway here, which is that progressive
web apps are fundamentally progressive. So when you invest in
your web experience, you make the experience better
for your users everywhere. And if you use progressive
web app features in the browsers that
support those features, it’s going to be
even more awesome. And this actually
turns out to be true when you look at the data. Earlier this year, AliExpress,
very big e-commerce company, rebuilt their site as
a progressive web app. And in Safari, they saw an
82% increase in conversions on average. And that’s a browser
that doesn’t currently support service workers
and these new features. But I think it just goes to show
that there’s a huge opportunity in investing in the mobile web. And if you build a
great progressive web app, like they did,
you can get that value across all of the
browsers and even more value in the browsers that
support these features. OK, so, we’re going to build
better engagement on the web using web Push notifications. We’re going to send
notifications that are timely, precise, and relevant. Just think about these things
and ask yourself, would I want to receive
this notification. Are my users going to be
delighted by this experience? We should make sure to ask
for permission in context, so the user knows what
they’re signing up to. And they’re likely
to click through because they see the value
proposition in what you’re giving them. And be awesome, you know? We have these new,
amazing superpowers, use them to build awesome,
amazing, new experiences for your users that
you’re going to love, your company is going to love,
and that they’re going to love. And with that, I’m going to
leave you with a few links where you can read
more about this. We have a guide
for getting started with Push notifications. And then some details about
the encryption aspects. Tomorrow, we’ll
have some code labs where we’ll go through
some of this stuff. And coming soon, on
Udacity, there’ll be a course there so
you can learn about that if you’re watching from home. So thank you very much.

Danny Hutson

4 thoughts on “Deep Engagment with Push Notifications (Progressive Web App Summit 2016)

  1. he made a nice joke about the 2 hard problems in computer science at the start and nobody laughed… tsc tsc 🙂

Leave a Reply

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