Build e-commerce sites for the modern web with AMP, PWA, and more (Google I/O ’18)

[MUSIC PLAYING] ADAM GREENBERG: Hi, everyone. Thank you for being here. We are excited to speak with you
about how e-commerce sites can take advantage of some of
the new, next generation web tools we’ve been working on
at Google in order to build more effective web sites. My name is Adam
Greenberg, and I work on partnerships for
mobile web technologies like accelerated mobile pages,
or AMP, and progressive web apps, or PWA. ROWAN MEREWOOD: Hey
there, I’m Rowan Merewood. I’m a developer advocate
for the web and Chrome. ADAM GREENBERG: So by now,
we’re on day three of I/O. And you’ve been hearing
a lot about what Google is up to this week
from driver-less cars to the assistant to the latest
on the Android platform. And the thread that
really brings together this wide variety of
products is connectivity. Google is in the
connection business, whether that’s someone
asking for the latest scores to a baseball
game, allowing you to message your
friends, or using your voice to ask Google to
play some music. And one of the most
important things we do is connect people to
goods and services that they want to buy
and connect businesses to a new customer base. Our goal here at
Google is to bridge the gap between users who
want to know something or find something and the companies that
have the information they’re looking for. And we do that via a
variety of services, including some of the ones
that you see listed right here. But our bread and butter
really remains the open web, which is the greatest
content discovery platform that’s ever existed. Now the open web doesn’t only
live in browsers or web views on a phone, but it
also powers much of the content that
drives services like search and the assistant. So, why the web? Well, it’s free,
it’s open, and anyone is welcome to come make
their mark on the web. But most importantly,
its reach is enormous. There are over five
billion devices connected to the open
web, and that number is growing at a steady rate. Now in e-commerce
specifically, there is a massive amount of
business taking place online. The majority of user time
spent on retail services happens on the web, and that’s
both desktop and mobile. And in that web
category, we all know that mobile is growing
at a pretty steady rate. We also know that while
we love apps at Google, not every user is going to
download new apps in a given month. So if you’re able to get a
user to download your app, that’s great. You should continue to
focus on building the best experience for loyal
users who have your app and working on a download
strategy for your apps on Android and iOS. But the reality is
most new users are going to come in via the web. And you want to make that a
killer experience for them, so that they engage with
your brand right away and that they want to
come back again and again. And that ultimately may lead
to them downloading your app. The web gives you an opportunity
to reach a huge, new user base. And that’s why we love it
for the commerce space. However, as great as the
web is for facilitating an open dialogue and ensuring
a level playing field exists for anyone who wants to
publish content, and as great as it is at allowing brands to
reach audiences they otherwise never could have,
there are challenges that place the future
of the open mobile web in an uncertain place. And the essence
of that challenge is engagement and
capabilities, which today just have not been on par
with the engagement and capabilities of apps. You get great, unparalleled
reach with the web, but a lot of the
time, the engagement isn’t where you’d
like to see it. But that is changing. The tools that allow you
to have great engagement on the mobile web exist, and
over the next 30 minutes, we’re going to talk
to you about how you can build this technology
into your web presence today. The ultimate goal here is to
improve engagement on the web so that it meets or exceeds
that of native apps, while still retaining that great
reach that the web has. Now, in theory,
this sounds great. Let’s keep our
fantastic reach, we’ll add in a splash of
staggering engagement, and in theory, it’s
a perfect world. But in practice, the
web has a lot of issues, and it’s a tall order to
combat all these problems. Now we’re approaching
the challenge head-on, but there is a lot going on. And you can see a
few examples here. Scrolling isn’t responsive,
pages load slowly, content bounces around when
late images or ads pop in, and the web doesn’t
really work well offline or on flaky connections. And on top of that,
while the technologies exist to improve the performance
and engagement of websites, we have not always made
it easy for developers to take advantage
of these solutions, so they’re not always
put into practice. We know that at times, these
solutions can be complex, that they’re changing
a lot, so there’s an awareness issue of what
the latest best practices are. And overall, that makes
it difficult to understand what the return on your
development investment will be or what the ROI might
be in terms of dollars. Today, we want to try to clear
up some of that confusion. Because enabling
some of these new web technologies can have
a meaningful impact for your business. Poor performance has
real life consequences. As you can see here,
over 50% of users will bounce from a site that
takes more than three seconds to load, and 79% of them will
abandon that site if they find it difficult to use. Now in terms of
revenue, we’ve seen that there is a 7% drop in
total revenue for every one second delay a user faces. So it’s a major issue. Users are often not finding
what they want either because a page didn’t load
or because the experience after load was
less than stellar. And they’re leaving sites sooner
than they otherwise would have, which is a huge missed
growth opportunity. Now lost revenue that affects
the growth of your business is obviously important, but
it’s not the only factor here. This slide runs through
a bunch of experiences that bring stress to people. And they include waiting
in line at a retail store, watching a melodramatic
TV show, standing at the edge of a virtual
cliff, watching a horror movie, and then experiencing
mobile delays. So that is correct. Somehow, the level of stress
caused by mobile delays was comparable
but slightly worse than watching a horror movie. And it’s only surpassed
by, of all things, solving a math problem, which is
not an experience anyone wants to give to users of their site. So you’ve got your business that
is operating on tight margins to begin with, needing to
capture every dollar it can. And you’ve got users who, when
they come to your slow site, are in need of some serious zen. So how do we reduce stress? Meditation, massage,
mindfulness is great, but may be a little
difficult to impart on shoppers of your site. So we can focus,
instead, here on what we can actually control– improving the overall
performance, UX, and the general experience of
visiting an e-commerce site to begin with. ROWAN MEREWOOD: OK, before
we dive into that, though, we wanted to take a
moment to clear up some of the terms
involved– specifically, AMP and PWA because we’ve
seen a little confusion here. Some people have been
thinking that, actually, it’s AMP versus PWA. And that’s actually
understandable. Both terms came about
the same sort of time, they’re both web-related,
and like Adam was saying, we throw new stuff
at you all the time, so it can be hard to
differentiate those. But let’s clear that up. It’s not AMP versus
PWA, so these are not exclusive choices. These are complementary
approaches when developing for the web. So it’s not AMP versus PWA. It’s AMP and PWA together. So let’s take a little refresher
on their relationship then. ADAM GREENBERG: OK, so
let’s start with AMP, or accelerated mobile pages. AMP is an open-source
project that began a few years ago to
help combat performance issues on the web. And there are two
key aspects to this. First, AMP is a
library of components built on top of HTML
specifically designed for performance. And second, the AMP
format mandates a number of rules about its
pages that are, again, focused on maintaining
performance but also on enabling caching. And this ability to
cache and serve remotely is what enables platforms
serving AMPs to pre-render them effectively. Now if that’s the
technical aspect, the business benefit
is that you can think of this as a team of 15
engineers devoted to managing performance compatibility issues
on your site, which leaves your own engineers free to
focus directly on the features that you’re working on. So the end result is
that when you combine caching and pre-rendering,
AMP content loads for a user, on average, in
about half a second. Now one additional
piece of AMP to consider are some of the
architectural choices you need to make when
adopting the technology. The most widely used
pattern at the moment is where you create a separate
version of your page using AMP and link it as a
related resource against your canonical HTML
page, the same way you might maintain multiple translations. That linked version is what
gets served on Google search or via Twitter or Bing or
any of the other platforms that link to AMP content. And while this provides an
unobtrusive and incremental way to get into the
platform, it does mean that you have two
versions of your site. And that can introduce
extra overhead. But like I said before, AMP
is a framework of components. And if you can use those
components to build a performant and
effective web page, well, aren’t those just the
requirements for your web page anyway? If AMP is working for you
as an entry point for some of your users, you
might just want to think about using it as your
front-end framework for all of your users. Now this approach is
gaining popularity, and a variety of sites
have done it to date, including the global
travel site, which you can see here. They serve over
300 million users in 13 different
languages, and they just launched a new site that
is built entirely in AMP. ROWAN MEREWOOD: OK, so if
AMP is a concrete library and platform, then
you can think of PWA as the overarching methodology
behind all of this. And hopefully you’ve seen us
mention these four pillars before, so I really want to try
and cement this in your mind now. These are the things
we really want you to consider when you’re
developing for the open web. So fast is up there, and that’s
a goal that we share with them. So performance really does need
to be built in from the start. Next up is integrated. And integrated means a
more app-like experience with your website. It should feel like it
belongs on the device. That means it opens
in its own window, or it can have icons on the
home screen or the desktop. Then there’s reliable. And that means that
you can give me an intelligent experience
regardless of my network connectivity state. So no more browser error pages. And finally, all of these build
to create engaging experiences. So that means notifications
when I need them, content that I can trust just
to display when I ask for it. And all of that is wrapped up
in a UI that feels familiar and at home on my device. ADAM GREENBERG: So we’ve
talked about what AMP is and what PWA is, and
it’s important to note that several different patterns
exist for combining AMP and PWA or for just using
one or the other, and we’re going to get
into that in a little bit. But to start, here’s your
classic user journey funnel. And we’re going to
focus today on using AMP at the top of the
funnel in the acquisition and browsing portion
of a user’s journey and on PWA at the bottom of the
funnel, when a user is looking to convert and when a business
is then aiming to build them into a loyal customer through
retention and re-engagement. Now this is a bit of an
oversimplification of the two concepts, but what
I want to give you here is a way to
frame these ideas in terms of where their
strengths are going to give you the biggest ROI. So ideally, you’ll be able to
pick something out of this talk and say, that’s what
we’re adding to our sprint when you get back to
the office on Monday. So in broad terms, AMP gives
you that easy development path for fast sites. That strength is going
to give you the most value at the top of the funnel. As you progress
through the funnel, the user is no longer browsing. They’ve made a decision, and
your priorities are evolving. Here, you want those PWA pillars
of integration and reliability to ensure that the conversion
portion of the funnel provides the best
experience possible, so you can build that one
happy transaction into a repeat customer. So let’s start with the first
step in an e-commerce journey, which is the acquisition of
a new user via entry points to your site. We’ll tell you a
little bit about what AMP looks like when
put into practice and some of the success
sites are seeing, and then we’ll dive into
some of the tech you can use to customize your pages. Now what matters most
here at the beginning is speed and performance. And this series of
two GIFs shows why. On the left, you have
the non-AMP version of a user finding a product
on the website for B&H Photo and Video, which is one
of the largest camera retailers in the world. And on the right, you
have the AMP version. When properly implemented,
the user on the AMP page is able to complete
their transaction before the non-AMP
user even gets to fully view the first page. So why is speed so important
in this first discovery phase? Well its at this point where
you’re really differentiating yourself from the competition. If I’m looking for a
particular brand of camera, then I’m looking through
a list of suppliers all selling the same
or similar products. If I tap on one of
those options and it doesn’t load immediately,
I might not wait around. I’m probably just going
to go on to the next site. And so the reality is that
most sites aren’t that fast. If you have a super
fast site upon load, it can really make
you stand out. And we’ve already
seen tons of sites do this in the commerce space. So you have three examples
here from three top sites across the globe. And we just want to point out
that when we say e-commerce here, we don’t just mean retail. We’re talking about travel and
other transactional verticals as well. So the first example is from
one of the largest retailers in Brazil, Magazine
Luiza, who recently launched AMP versions of most
of their product listing pages. We also have an example from
Priceline, a global travel site that serves 1.5
million daily active users, and they just
launched AMP versions for a bunch of their
hotel pages for cities, states in different countries. And they’re working on
growing that AMP presence to other types of
content as well. And then finally,
we see an example from Flipkart, the
Indian travel brand who’s no stranger to
performance boosting, as they were the first
site ever to launch a PWA. And when we talk
about entry points, we want to make sure that people
understand the point of entry is not limited to
referrals from Google. There are over a dozen
top platforms globally that will link to AMP pages. Some of them utilize a
cache, and some don’t. The fastest possible
version of an AMP page will load when a
cache is involved. But whether it is or not,
AMP pages on these platforms do mean a faster
experience for your content when users find it. Where a cache is
involved, however, we see the truly instant version
of AMP come into play. Google leverages a cache
nearly everywhere it links to AMP pages,
including in Adwords, which began to link to AMPs
at the end of last year. And the early results so far
have been pretty promising. As you can see here
from the experience of the online
retailer Merchology, AMP pages are faster,
and that means an increase in convergence. And Google is also working on a
beta to bring the power of AMP to product listing ads, or PLAs. And we’re excited to announce
that two of the top landing page providers,
Instapage and Unbounce, have both embraced
the AMP format. Instapage launched full AMP
support in their offering just last week. You can check it out. It’s live, it looks great. And Unbounce is alpha testing
AMP with a few of their clients before fully rolling out. Now as far as
results go overall, here are a few additional
metrics that sites are seeing. E-commerce merchants
like Ali Express, the global retail
marketplace, and Overstock, online home goods
store, are seeing increases in revenue
and conversion following their
deployment of AMP. And Twitter is seeing
an overall reduction in page load abandonment for
any AMP pages on its platform. Now it’s worth noting that
Ali Express’s example here is a mobile site
built all in AMP, so they aren’t using
the paired approach that we were referencing
a few minutes ago for the mobile version
of their website. They do still have a
separate desktop version. And given their strong
implementation and the success they’re seeing, we’re
going to use them as a reference implementation
in some slides to come. So now that we’ve talked
a little bit about how AMP leverages speed to drive an
increase in important business metrics, let’s dive into
some of the technology that allows you to
customize your AMPs and bridge together
an AMP and a PWA. And for that, I’m going
to hand it off to Rowan. ROWAN MEREWOOD: Oh,
thank you, Adam. OK, so we’ve created
our fast entry point, and that’s grabbed our
potential customer’s interest. But there are still
a few more steps before we can turn
that into a purchase. When I land on a
site, I don’t come with an exact product in mind. I come with a problem
that I want to solve. So maybe I’m thinking it’s
time to replace my old sofa, or perhaps I’m thinking of
getting some shirts that aren’t just black or gray. I’m not, but if I
was, what I would need is a way of narrowing down
that wider selection to the end product. So as Adam mentioned,
we’re going to take a look at Ali
Express and what they’re doing with their own content. So here, you can see how they’ve
done filtering and sorting. We can see the drop-down there
that lets me sort by price. And we can see the
sidebar coming out that lets me filter by color. So let’s take a
look at how we can create some of these
components inside of AMP. Starting with filtering, you can
see in this simplified example there are two main components. We’ve got the list
of products that we want to display at the bottom,
and we’ve got the controls to filter them at the top. So let’s take a look at
that amp-list tag first. The source attribute here is
specifying adjacent endpoint that will return the data
to populate our template. Now that first source attribute
is our default full list of products. The second source attribute
is in square brackets. And that’s because we’re using
the functionality of amp-bind here. The brackets tell
us that we want to bind the value of
the list source variable to the source attribute. And that means when
list source changes, we’re going to update our list. Now we need to provide some
UI to actually allow the user to change that variable. So since AMP is still HTML,
we can use our standard form controls here. And here we’ve got a radio
button to toggle the color. You can see that I’ve
populated the on attribute. This is amp-bind’s
for basically creating a sort of event listener and I’m
listening for the change event. When I get that, I’m going
to update list source to include yellow If
the option is checked. And that’s it. If I select color in the form,
that will update the variable, and my list will reload. So let’s generalize
that pattern. What you do here is
you set up your list with a dynamic
source, and then you add form controls to
update the source. And it’s pretty simple. It’s pretty flexible. So hopefully to
prove that, I’m going to show you a couple other
applications of this. If we jump over to
sorting, then, we’ve got the same list set up here
at the bottom and the form at the top. The difference here is that
instead of alternating the path on the Boolean variable
that I had before, I’m just pulling
out the event value and dropping that straight
into our GET parameter. So here, if we wanted to
add a new sort option, like sort by rating,
then all we have to do is support it
on our end point, and then we just add that
option into the form. And it’s going to work. OK, and it’s not just
static form controls either. We can use the
same functionality to take a value
that the user types and pass that along
to our back-end. We can see here Airbnb
experimenting with this to provide auto-suggest
on destinations. So let’s take a peek at
the detail of this one. We’re not making use
of the change event here because users
may well be typing a bit faster than the
service is returning results. So instead, we’re making use
of the input debounced event. And that allows us to smooth
that input out a little bit. And then it’s the
familiar pattern, right. User types their query, we
drop it into the GET parameter, we get the results. OK, finally, then, the
configuration of that list isn’t always based on user
input but actually user context. So in this example, from the
aptly named, we’re showing some geolocation. Now behind the scenes,
we’re doing a GeoIP look-up on our server– so it’s not precise location,
but general user area. This is perfect
for doing something like listing nearby stores
for product collection. The touch I like here
is the dummy items beforehand so that
we can see something as the content is loading. Now let’s see how that’s done. When that initial call
goes off to the server, an amp-list can display
fallback content using the placeholder attribute. So down at the
bottom, we’re using that to show those dummy items. When our request
comes back, we’re replacing that with
our populated template. But to the user, it kind of
looks like a smooth transition in. And also, for a
little bonus material, we recently announced
amp-geo, and so this lets you do geolocation at
the country level, which can be useful for doing things
like picking price formatting or delivery options. OK, so we’ll take
a little breather because we’ve made it through
the first stage of our funnel. And the one thing
we really want you to take away from this
section is that speed is key for acquisition. But that doesn’t mean you need
to sacrifice rich content as well. That simple pattern of
amp-bind with amp-list. Can let you combine the speedy
display of cached content with layering in of
personalized data. OK, let’s move on to conversion. That means we’ve built
our fast entry point. I found the product that I want. So let’s go ahead and buy it. The steps that I want to examine
here, then, is add to cart. So we’re going to
stick with Ali Express, and we’re going to see how they
built this in-page experience using AMP. First, we’re going to
need a data structure to store the product that we
want to add to our basket. Now we’ve populated that with
the data we know already. That’s the country name, the
price formatting, the quantity. And we have these
null placeholders, which are for the
additional options we’re going to configure in the page. We’re going to
use amp-bind again to fill in those placeholders. When the user taps on the size,
we’re grabbing that value, and we’re mapping it
into our data structure. We’re also mapping it back
to an element on the screen, so the user has some visual
feedback that something has happened. And we’re going to use amp-bind
as well to map those product properties into the hidden
inputs of our add to cart form. And finally, the
additional ingredient here is the
action-xhr attribute, which, again, is AMP’s
convention for allowing the in-page form request. So now, when the response comes
back, we can update the page, and we can trigger our
confirmation message. OK, so we’ve done add to cart
with in-page interactions in AMP. And that means we’ve set
a high bar for speed. But what happens when I make
the transition off of AMP? If we just present the
user with a slow spinner, then we’re burning
all of that good will that we built up
in the first stage. Now, instead, while we know
we’re making a transition, maybe from cached to hosted,
from AMP to the wider PWA world, we don’t want
the user to know it. We want this to feel like
a seamless, consistent progression. Conveniently, that’s
a perfect segue into a core concept
for progressive web apps, the service worker. Now, a service worker can act
like a caching proxy server between your app
and the network. And that means that
we can go ahead, and we can warm up that
cache before the user even gets there. In our AMP content,
we make use of the amp-install-serviceworker
tag to start this process. We’re providing both the service
worker location and an iframe on our domain because the
service worker can only be installed from our domain. Once the install starts,
we’re ready to start prepping that content. I’m going to show you a
super simple base here. And so in here, what we’re doing
is during the install step. We’re caching what I like to
call the site furniture– so that stuff like your fonts,
your header images, and so on. And then, we have
a fetch handler. So when the user taps
to go to the new page, the fetch handler
kicks in and starts serving our cached content. And this is just the very
tip of what you can do. So I highly recommend checking
out our workbox library to get some production patterns
that you can make use of here. OK, we’ve focused a lot on
the fast pillar from our [INAUDIBLE]. And that’s fine, but
it’s not the whole story. Caching can solve
some of these problems for browsing but not for state
changes like add to cart. And we don’t want
the user dropping out at this critical stage just
because our connection dropped. Now, this was the
problem that one of the real pioneers of commerce
on the web set out to solve. And eBay, as most of
you probably know, is the online
marketplace where you can find a 1.1 billion listings. And they saw over $23
billion of transactions just in the first quarter
of this year alone. So reliability is
absolutely core to that experience for them. And they’ve been working to
enable their add to cart button to work offline. Now, I really love this
use case because it’s not about trying to make the
entire site work offline or do some kind of
crazy user experience. They picked a critical
part of their user journey, and they focused on
making that reliable, solving a real business problem. And that’s the key. Don’t think of offline and
online as binary states. Instead, we should
be thinking about robust network-independent
add to cart. It’s just that’s not as
catchy for putting on a slide. So really, what happens
here is that eBay simplifies the shopping experience. I don’t have to consider
my cell phone signal when I press that button. All I know is I want a new
phone, I press the button, eBay takes care of the rest. Let’s look at how
we can do that. First, our default behavior. If I tap add to cart, but
the connection isn’t there, the request just
fails and drops out. So what do we need to do? Instead, when that
request fails, we’re going to capture
the details that we need to send it again and save them. When we reconnect, we
retrieve that data, recreate our request,
and we send it. Simple enough concept, so
let’s dive into a little code. First, I’m going to go back
to my fetch handler again. And what I’m doing is
I’m intercepting those add to cart post requests. Always be specific when you’re
doing something like this because you don’t
want unintended side effects by interfering with
other requests from your app. Next, we fire off that request. If it succeeds, great. We’ve got nothing else to do. However, if it fails, we want
to pull out the request details. I’ve cloned the request here
because the body has already been read, and you
can only read it once. I’m using the local
forage library just to give me a simple
key value store. And the current
time-stamp is my key, and I’m saving the request body. Now, we’ve saved our request. We want the matching
functionality to retrieve it as well. And this function– back
in my client logic– I’m iterating through
the existing entries, and I’m using the
time-stamp just to filter out the ones
from the last 10 minutes because I don’t really
want to randomly add stuff to the user’s cart hours later. I’m using that saved data
to just build a new post request for the same add
to cart action and send it. And finally, I’ve
attached this function to listen for the online
event in the browser. And that means when the page
registers as online again, it will kick in and attempt
send all of those requests. But you should also be hooking
this up in some other places as well, like page load or
service worker activation. For a bit more bonus
content as well, go and take a look at
the background sync API for what you might be able to
do with this in the future. OK, very briefly, then,
because we’ve worked hard to get the user this
far, we should probably take some money from them. That said, Adam and I
have already crammed way too much content
into this talk, so we just wanted
to give a shout out to some of the other
talks that are doing this. So, in fact, directly
after this on stage seven, there is a Google
Pay best practices talk if you want to keep
the e-commerce theme going. And with that, we’re on
to the home straight. Let’s take a look
at what we can do after the sale to try and
turn this person into a repeat customer. Now to have repeat
customers, they’re going to need to have a way of
actually getting back to us. And add to home screen
is a way to do this that is super easy to implement. But it’s not always relevant. The home screen is for
daily, quick access. And if you are someone like an
airline or a furniture company, then success for you is not
measured in daily active users. Your purchase patterns
are seasonal or periodic. So what if you could give me
something personal instead? Let’s say I’ve
ordered that new sofa. On the order
confirmation page, you could give me an option
to track my order. When I tap that,
I’ll be prompted to add the order
to my home screen. So let’s take a look at how
we can make that happen. On the confirmation page,
we’re linking to the manifest. But in this case, it’s
not a static file. It’s a dynamic
resource, and we’re going to populate it with
a custom name, an image, a StartURL, and so on. And we also don’t want
to just randomly trigger this add to home screen prompt. We only want to do it in
response to the user pressing the button. So this is something
you should actually add on all of your pages to
ensure that you’re intercepting the add to home screen event. We capture the before
install prompt event and prevent it from showing. And then we re-trigger
it for the click listener for track order button. And that’s it. Now I’ve got the order right
there on my home screen, and it’s not the home page
of the furnisher site. It’s going to the current
status of my order. The benefit here is
when my order is done, you can maybe just
show me a message saying that it’s fine for
me to delete the icon now. Or you can maybe show me
some additional products, and perhaps, I should get that
matching coffee table as well. Anyway, if you do this, you need
a way of measuring the success, and there are three places
you should be checking. First, let’s revisit where
we’re triggering that prompt. And it’s not just
fire and forget here. We can expand the
result of the prompt. In this case, I’m firing
a Google Analytics event for the installed
and dismissed events. Next up, you can use a unique
location for your StartURL that will only be
used by your manifest. Here, again, I’ve just added
some Google Analytics campaign parameters onto
the end of my URL. And For our final
signal, we’re going to make use of this display
standalone property, and that’s what’s causing our
app to launch in its own window without any of the
browser controls. And it turns out,
this property can be matched with a CSS media query. So here, we’re using matchMedia
to detect standalone mode and trigger another
analytics event. This is important because users
may deep-link into our web app, meaning they aren’t triggering
a lunch from the home screen. And there we go. With these three
signals, you are now measuring installs, launches,
and usage for your app. OK, since I mentioned
other routes into your app, I’d like to finish with a little
message about modifications. I’m not going to show code
here because that’s actually the easy part. Potentially, it’s even too easy
because I keep hitting sites that as soon as you
land on the domain ask you for the
notification permission. And this is spammy behavior,
which hurts the ecosystem. And when I say
hurts the ecosystem, I mean it hurts
you as developers because we start making it
harder to use these features. So I want to be able to get
useful push notifications. And to do that, it means I
need all of you to really champion the best
practices here. So I want you to make sure that
every notification you send satisfies these three things. Who– it should be
personal information to me, like it’s my delivery, or it’s a
sale an item that I’m watching. And then what, as in what
has actually happened? If you can give me
everything I need concisely in the notification, I may
not even need to tap it. And when– and that
means sending them at appropriate times
and expiring them when they’re no longer needed. So what does that look like
when you pull it all together? It looks something like this. It’s personal to me, it’s giving
me enough information to act without tapping, and
that five minute warning was worth interrupting me. So if that’s the case,
I’d better head over there so I can relax on my new sofa,
and I’ll hand it back over to Adam. ADAM GREENBERG: Thanks, Rowan. Excuse me. OK, so using the service
worker and building a PWA can mean an uptick
in business metrics, just like we saw
earlier with AMP. And Starbucks, for example,
launched a PWA last year, and they’ve seen their daily
and monthly active users in this format doubled. So that’s the full funnel,
going from acquisition via super fast entry pages using
AMP to converting and retaining users via PWA. We’ve talked a lot about
how these technologies work separately, but we
also want to highlight that they can work together. And there are a couple
of different patterns to do so because after all, in
the case of both AMP and PWA, we’re just talking
about web pages. The two technologies
are complementary ways of achieving different goals,
each with their own strengths and each with their
own challenges. But when they’re
combined, you get to enjoy the benefits of both. AMP and PWA give you a
feature-rich experience that starts fast and stays fast. So the first example
here is 1-800-FLOWERS, which delivers flowers and gifts
to over 150 different countries across the globe. They are linking AMP pages,
which serve as an entry point into their site, into a PWA. Within that PWA, they are
also leveraging Google sign-on as an identity solution,
and they’re allowing users to check out via Google Pay. It’s a great example of not only
utilizing AMP and PWA together but several different pieces
of the mobile web toolkit. In an early testing,
1-800-FLOWERS saw a 50% conversion
increase with their PWA. ShopClues, a leading
e-commerce player in India with a marketplace for Tier
Two, Three, and Four cities, also launched an AMP and
PWA integration last year. And similar to
1-800-FLOWERS, AMP pages are serving as entry
points to their site, and they then link into a PWA. And the framework helped them
see an increase in conversions, a reduction in load time, and
a reduction in bounce rate. Now the pattern of linking
your AMPs into a PWA isn’t the only solution. There’s another pattern for
combining AMP and PWA that is beginning to emerge, where
you use the two together in the same document. When a user visits such a
page through an AMP cache, they get the AMP page. When they continue their
journey onto the site origin, they get the full AMP
and PWA experience, including the speed
and TurnKey UX of AMP and the extended
capabilities of PWA. Now the simplest
first step to do this is the one we showed
earlier, which is just to add a service worker
with basic caching to an existing AMP page. From there, you can layer
on other PWA features as you like, including
push notifications, more advanced caching
and offline support, and an add to home
screen prompt. An alternate pattern
is to build your PWA to be a kind of app shelf
for your AMP documents, which themselves function
as content pages. This pattern can be a
little more complex, and it might require a little
bit more work to make it work. But we have seen some sites do
so, including, which is an online retailer
that makes phone cases, as well as the
global car brand BMW. And one benefit
of either pattern, on top of speed and
performance gains, is that they simply build upon
any investment you’ve already made with AMP, so you
can reuse that work. All right, so that is about it. Now we’ve learned a
few things today– how to start fast
with your AMP pages and stay fast with your PWA
so that you can successfully combine the entry points
of AMP with the down funnel engagement
tools of a PWA. We talked about how
to customize AMP pages and how to send notifications
via the web to your users. We talked about service worker
and AMP’s custom library, and we talked about companies
who are seeing success with each of these formats as
well as some seeing success by combining the
formats together. The bottom line is we know
the web has amazing reach, and the tools now exist to help
ensure its capabilities mean the web has great engagement
and profitability as well. Now you can check out technical
documentation on our websites, or feel free to stick
around after the talk to ask questions. Rowan and I will be
here, and then we’ll be in the mobile
web sandbox later. But we can’t wait to
see what you build. Thank you. [APPLAUSE] [MUSIC PLAYING]

, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Post navigation

8 thoughts on “Build e-commerce sites for the modern web with AMP, PWA, and more (Google I/O ’18)

  1. Google needs to package things better. everything is all over the places. Horrible naming, horrible interface. Non-intuitive. The technology is crapped when you don't name it right and package it for consumption.

Leave a Reply

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