LISA WANG: It’s a long
title, so we’re just going to make it AMP
Loves E-commerce. It’s a little easier. I’m Lisa. I’m a product manager at Google. And I lead our
e-commerce initiatives. And today, I’m
just going to walk through some of
our best practices for building e-commerce
experiences in AMP. So by now, I’m sure
that you’ve heard that AMP is built on
user-first principles, so today, we’re going
to start with the user. When we look at the
mobile web today, 53% of mobile-site visitors
will leave the site after 3 seconds, which is to
say that if you leave them with a loading spinner
or a blank page, they’re out of there. In e-commerce specifically,
79% of shoppers will not return to a site
that had performance issues, so if they have
problems browsing, if they have trouble
purchasing a product, then they’re likely
not going to come back. And just a one-second
delay in load time can lead to a 7%
drop in conversions, again, saying that if you
are wasting your user’s time, if they’re not getting
the information that they need, they are going to go
to a competitor’s site and spend their money there. And to put this in a
more visual context, I’ll show you an AMP and a
non-AMP version of a product details page from B&H Photos. So here on the left, we
have the non-AMP page, which is going to take a
little bit of time to load. On the right, you see
that page is loaded. I can look through
some information. I’m going to add
that to my cart. I’ll actually start
the checkout process. And I will place my order,
see a confirmation message, before the non-AMP
page has loaded. And so you can see
already that, if you can get that information in
front of your user faster, they can make a purchase,
be on their way, in a much quicker way. And we really think
that that’s the value of AMP for e-commerce. And in the last
year or so, we’ve seen that sites everywhere have
seen great success with AMP, so from pure-play retail,
to ticketing, to shipping services, sites across
verticals and across the world have been able to boost
their revenue by using AMP. We’ve also seen that building
AMP experiences for e-commerce can be challenging. It’s not always easy. There are things that come
up that can block progress. And so today we’ll walk
through the best practices for everything from choosing
which pages to start with, to building dynamic and
interactive experiences, to testing them out,
and then finally, to launching
discoverable experiences. And we’ll also bring
up some guest speakers to give you a firsthand account
of what it was like for them to build out their AMP pages. So getting started and choosing
what pages to start AMPing is often a really easy
question to overlook, right? You could just randomly
choose a few pages and start AMPing them, throw
them out into the world, and see how they do. But in fact, this
is the first step that you take to building AMP. And you want to set
yourself up for success, so there are a lot
of nuances that go into making this decision. And to give you a
firsthand account of what it was like
for Zalando to do this, I’d like you to welcome
me and joining– join me in welcoming
Ralph to the stage. [APPLAUSE] RALF OHLENBOSTEL:
So my name is Ralph. I’m the tech [INAUDIBLE]
lead for Zalando. And I do a lot of first pages. And when AMP came
up, I thought, OK, let’s just try this
for e-commerce, see where we are going. And the idea was
to really see what pages do we have at Zalando. So this is basically
what Zalando is. It’s a home page. We have a lot of hub pages. So if you think of, like,
say, tennis as a topic, we have everything regarding
to tennis on the hub page. We have categories, editorial
content, and product. So and then you start your
journey, and think, OK, where should I start with AMP? And for us, it
was, like, we want to get this testing very
fast to the customer. So I didn’t want to
over-engineer this, but really make it happen in a
few weeks, that we have an AMP page out there. So we thought, let’s
go really simple. So we looked at all
our pages, and we thought, maybe those editorial
guides are a good way to start, because this is mostly text,
pictures, slide, video, so we can start very
easily and don’t have to have a lot of hassle. And also, we have to set
up a store environment for AMP, so for
example, the tracking, the deployment pipeline. So that was our
first initial test. We got some insights. And that was a good start. Also we thought, let’s not build
the next big thing at Zalando with AMP, because you
don’t have historical data. And you want to test the
page where you really know what this page is about,
and you have very stable CTR, response rate, organic rankings,
and traffic, so that you really know how this page performs. So if you take an AMP page and
build something from scratch, it would be hard for you to
compare historically for sure, so we took a page where
we thought we know exactly like this page behaves. And when we switch
to AMP, we would know what the impact would be. Also, this you
will hear probably a lot during this conference. You have to aim
for feature parity, because I saw a
lot of AMPs where people started with a
rich mobile experience, and then went to
a very light AMP. And this doesn’t fly. So if you then have
a fair comparison between the performance
of both pages, you have to make
really sure that you build the full experience
so that the customer gets basically what he’s used
to, used to at Zalando. So the customer knows exactly
how a product page at Zalando works, or a guide,
and if it’s, like, just giving the half
of the experience, he would probably bounce more. And you would get maybe even
worst results on the AMP. And you don’t want that, so
always aim for feature parity. We also had a lot
of constraints. So we were thinking about, let’s
maybe start with a home page, because the homepage is, for
us, the most important page. There’s a lot of traffic
flowing through the home page. Then we looked at the home
page with all those modules like campaign steering, styles
of the day, editorial guides. And these are all
different products teams, so I would have to align
with all of the product teams what they are planning to do
in the next months regarding their product. And that was too much of
a hassle in the beginning, so we x-ed out the
home page for now. And then also when I identified
the editorial page, let’s say, OK, this is the page
we want to build. I went to the engineer,
said, hey, guys, let’s build this AMP page. And they said, yeah,
but we are already doing this and that,
so no time for building those pages actually. So I asked them, would
it be fine for you if we hire a freelancer, they
sit with you and your product team so that you have the
full control of the story, but still we get
this focus on AMP. That worked very well, so we
have basically not [INAUDIBLE] internally, but used
freelancers as help. And it was a great
success so for. We made a video because this
page speed is not so tangible. If I say to you, yeah,
it’s one second versus six seconds, you, know
probably what does it mean, but we wanted to make
it really tangible and also show internally
at Zalando how fast this experience, so we
made this video. It was just for
internal purposes, but we liked it so much, so
I want to show it to you. [MUSIC PLAYING] So what do you do with it? So I spread this video in
our internal social network to just say to
everyone, guys, we need to work on mobile
site performance. And we need to work on AMP
so that were very well, so it was a good move. I don’t know if everyone can
produce a video like this, but it was a good thing. And after we were confident
with AMP, we said, lets go from fast to maximum. And maximum for us means
building product pages in AMP. And product pages, we have
a lot of products live. So we have around 300,000
fashion products in 16 markets. And you only have to
build one AMP renderer, because the template
is very fixed. It looks almost always the
same, so we can scale it up very easily
across 16 countries, so that was a very
good starting point. Also what I like
about product pages is that the customer has
a very high intent to buy. So if you search
for Nike Air Max 97, you can be pretty sure that
this customer really wants to know about this product. It’s about what are the
prices, availability, so I think, if you can
deliver the product on Google, like, in under 1 second
and your competition can’t, so that’s a huge
winning point for you. And also, what I really like
about choosing product pages, that we can integrate this
in all our performance channels later on, because
every performance channel aims for product page. So we will talk with
[INAUDIBLE] Google shopping display so that we can leverage
this AMPs across all channels. That’s the idea here. Our product pages are, I
would say, pretty standard. What you have, you have a slider
with the product info details. We have dynamic pricing. That’s very important,
because if you serve on AMPs, like, a different price, that’s
not good– a good experience. And recommendation engine
was very important for us, so our initial build was
without a reco engine. And we saw that the customers
don’t love this page so much. And then we looked
at the data, and we saw that people come
to our product pages. And then they start browsing
around different products, so we built this
recommendation engine on AMP. And you jump from
one AMP to another very fast so that you
have a fast experience, and can look at a lot of
products in a very little time, so that was very helpful. When it comes to
scalability, what we are doing at the moment,
we are basically here now at 10,000 AMPs in Germany. And we have, like, a cycle
where we release some more, then we do some
feature improvements. We try to complete our tracking,
make it better a little bit. Then we release more and more. And at the moment,
we are basically waiting for the developers
to build a complete feature parity so that we have
product reviews in there. And then we will
scale up, basically, Germany up to 300,000 AMPs. And then its
basically just a click to go to 16 markets with our
pages, so that’s our plans. And further down the road, we
are looking at those page types as well, because now we are
very confident about AMPs. And I think categories will be
our next thing we will tackle. Thank you, guys. [APPLAUSE] Back to Lisa. LISA WANG: Thank you, Ralph. So I think, really,
the moral of this story is that choosing which
pages to start with can be a rather
complex question. You have resourcing
to think about. You have impact that
you want to think about. Really take the
time and make sure that you’ve chosen the right
pages to really start building with. And once you have chosen
that, the next step is to really build
out the features and choose which features
you want to go on this page. And I think, by now, most of
you are familiar with what’s possible in AMP, but I want to
touch on one quick refresher. So last year at AMP
Conf we launched amp-bind, which
basically enabled a whole new world of
interactive experiences that you could build in AMP. And looking back,
we can kind of think of AMP-free e-commerce,
and the history of it, in terms of two phases. So before bind, or BB, you could
build this really beautiful lead generation page with
carousels, with forms, with a sidebar navigation. You can do a lot of really
beautiful and user-friendly things, but nothing
that’s too much more interactive than that. Once we launched amp-bind,
you could start building experiences like
this one here, where you can have interactivity, you
can change parts of the page based on user interaction, you
can build filtering, sorting, everything that’s necessary
for an e-commerce experience in AMP, everything that
your user expects to see, which is to say that you should
build all of these experiences on your page. So if we looked at
just this mock product page that I put together,
and we took a look at a heat map, let’s say, of
user interaction on it, I would bet that it
would look something like this, where anything
that’s necessary for your user to browse or
purchase that product is going to be heavily
interacted with. So they’ll be
tapping on that image to really get the details on it. They’ll be tapping
through colors and sizing to see what
their options are. Maybe they’ll go
through, like Ralph said, the recommended
products carousel to get an idea of what other
products you have available. And then ideally, they’re adding
that product to their cart. And they’re purchasing it. So if you build a page like
this where all that’s left is a big image and a button that
leads you to the non-AMP page, you’ve done one of two things. You’ve either scared
your user away because this doesn’t
look like a page that they are familiar
with, or you’ve added– you’ve strictly added
an extra step to purchasing a product on your page, right? AMP will do all
the heavy lifting of delivering your pages
quickly to your users, making that transition from a
discovery platform to your site as seamless as possible. But to take full advantage
of that fast transition, you have to give
your user everything that they need to
make a decision or to continue
browsing with you. If you just link them from
the AMP to the non-AMP page, all you’ve done is added
friction to that experience, and when, in fact,
you could have done so much more for them. So don’t do this, but
I’m also not saying that you have to
build an exact carbon copy of your non-AMP
page in the AMP version. You should take this opportunity
to build a better page. So look at what features are
getting a lot of interaction, which are proving crucial
to the browsing and purchase experience, and make sure
that you include those. But then maybe you find that
some features are actually a little distracting
for your users or aren’t as mobile-friendly. Then you can get
rid of those, right? We’re optimizing for
the best experience. We’ll do the speed part. And then you focus
on the features. And so once you’ve decided which
features that you’re building, the next step is really
building them out, right? And this, I think, is where
we see a lot of the challenges emerge, because
building personalized and dynamic experiences
in AMP, you really have to change your
mindset from building with JavaScript to building with
a more declarative framework. And so we’ll walk through some
of the different experiences that you can build here in AMP. The first one I want to start
with is the date picker. So this, we recently
released into experimentation to better support travel. And it works exactly
as you would imagine. So when you tap on
the input field, you can see a date
picker emerge. You can block off
dates that maybe you want to disable for your user. You can even set a
minimum number of dates so that dates that don’t fulfill
that constraint are disabled. And then you can trigger
visibility of other components as the user is interacting. Now, I’ll through how to build
all of these experiences, but first I want to show
a quick comparison of what it’s like to initialize
and construct this date picker in jQuery
versus today in AMP. So with jQuery, the code
that’s required just to initialize the date
picker– and we’re already using their
built-in library. But just to
initialize it and then to set the constraint that
you can’t choose an end date before your start
date or start date after and it takes more code than I
can fit on this slide, right? But for AMP, I can do
everything that I’m getting on the left and more
with just four lines of code. So let’s dive right
in to setting this up. With the date picker,
you can enable two types of experiences,
selecting a single date or selecting your
range of dates. And you can specify that
with the type attribute. Then you can do a whole
lot of customizations to just make sure this
fits your look and feel, so you can do things like
change the orientation from vertically-scrollable
to horizontally-scrollable. You can set the number
of months that you want to show initially. You can set the first
day of the week. You can set the language. You can set a ton of
things here, basically. We can do a little bit
fancier stuff as well. So setting the minimum
number of dates, we set that as three
in the demo before. You can do whatever
makes sense to you. And you can also
change this based on how the user is
interacting, so maybe they’ll set the minimum number of dates. You can also block off dates
using the blocked attribute. So let’s say that you
don’t conduct business every other Sunday or something
like that, you can easily specify that there. And then again, there’s a
lot of other customizations you can do. I encourage you to check out our
spec that we posted on GitHub. Feel free to comment and
give us any feedback that you have on that. Now on to the more dynamic parts
of the date picker, so let’s say that you have special
deals on certain dates, but that these dates are
constantly changing, right? Maybe you don’t want
this to be cached. You really want to get the
freshest data to your user. In this case, you can easily
specify the JSON endpoint you want us to fetch those dates
from within the date picker configuration. And then all you need
to do is make sure that the IDs that you’re
using in that JSON file match the IDs that you’re
using in your markup. So in this case, we’re
matching that deals ID so that the CSS we
apply is getting applied to the right set of dates. You can also construct bindings
between other components on the page and how the
user is interacting. So in this case, we want to
show basically a great price banner whenever a range of
dates is selected that includes one of those deals. And so here we’re
going to leverage the on attribute, which basically
says, when this event happens, trigger this action. So here we’re saying,
when a range of dates is selected, change
the value of tooltip to be true if it includes
a date with the deal on it and false otherwise. We then toggle the visibility
of the great price banner such that it shows if
there was a great deal and false otherwise. We also built in an info
panel into this date picker. So below that
calendar view, you can include a box with static
information, say, just as, like, a legend of what the
markup on the dates means. Or you can include more
dynamic information. So here we just want to show the
user the start date and the end date that they’ve selected. And again we use
the on attribute. So we’re saying, when that
date range is selected, set the value of start date to be
the first date in that range and end date to
be the last date. And then we’re showing that
within the info template. And again, all of this changes. What the user is
seeing will change as they’re interacting
with the date picker. Now, I know not all of you
are a travel companies, so maybe a date picker is not
necessarily applicable to you. But I think that
personalization is something that’s top-of-mind
for every e-commerce company. And when I think
of personalization, I think eBay is a site that
does this really well, right? You can see recently
viewed items. You can see what items
you’re explicitly watching so that
you can continue on the journeys for
each of those products, but how do we
build these in AMP? So in this first example, we’ll
use the amp-access component to trigger visibility
of different components based on signed-in status
and also facilitate signing in and signing out. So with amp-access, the first
step that you need to take is to actually
specify the endpoints you want to use
for authorization, ping back, sign
in, and sign out. You can also set the
fallback response, so what do you
want certain values to be in case authorization,
for some reason, fails? Then you can start
marking up this page based on the signed in status. So you can hide
content that you only want to show logged in users
and show content that– or hide and show content
based on the logged-in status. And so in this
example, we’re going to use amp-access,
which basically will trigger the visibility. When it’s set equal to true,
it will show that component. When it’s set equal to
false, it will hide it. And here we’re setting
it to the value of logged in, which we will set using
the authorization response. But you can also return
a lot more information in that response. So if the value of
logged-in is true, we’re actually also going
to return some information on personalized deals. So we’ll return the name of
the deal, an image, and a link to it. That way, we can render
it easily for the user. Then below that, we have
a section that we’re only going to show logged-out users. And so we’ll show them
a prompt to log in. And then we’re also going to
show them a link to do that. And here we’re going to use
amp tap equals amp-access login sign-in, basically to trigger
that log in flow that you specified earlier in the
amp-access configuration. Now let’s say that you want
to personalize this page based on user behavior regardless
of whether or not they were logged in or logged out. And so something like this where
you’re showing users products that they’ve recently
viewed to let them continue on this journey. So first, we’ll use amp-pixel
to track product views. Basically, every time
they view a product, we’ll send a ping to this URL. And you’ll notice that
we’re specifying a client ID here so that we can
properly identify that user. It’s what we use in
AMP to track users. Then on maybe the home
page or the product– or the user’s profile
page, wherever you want to show
this module, we’re going to use amp-list
to then render all the products that they’ve seen. And we’re setting the
source here, again, to an end point that’s
specific to that client ID so we’re only
fetching the products that this particular
user has viewed. And then we can return any
other information here, so products, we’re showing
the link, again, the image and the name of the product. Anything that you think is
important for that user, you can then show
and render here. Now, suppose that
you don’t really want to personalize this
page based on who the user is but rather where they are,
so some form geovariation. If you’re doing
page-level geovariation, so if you’re showing
a different page to a user in the US
versus a user in France, then we can use
hreflang, the same as you would for any other page. And if you’re using
canonical AMP, so AMP is the only
version of your page, this is actually super easy. For just pure AMP discovery
and distribution reasons, you need to first include
the link– the canonical link from the AMP document to itself. And we need to do this
for the English version and the French version. Then we need to include a
link from the English version to the French version
with hreflang set to fr and then we do the same from
the French to the English, just so we know that there
is an alternate version of this document in
another language. And this will let us send
the right one to the user depending on where
they’re coming from. If you’re not doing
canonical AMP, you’re likely going
with a paired approach, so you have an AMP and a non-AMP
version of any given page. In this case, this diagram
here shows the steps that you need to take
to make this happen. First, again, for AMP
distribution and discovery reasons, we need to include
the canonical and the AMP HTML links between the AMP
and the non-AMP versions for English and then the
AMP and the non-AMP versions for French. Then we’re going to include
a link from the English to the French version. And we’ll do this for both
the AMP and the non-AMP pairs, so we need to make sure that,
for all these documents, we know, first, that there
is either a non-AMP or an AMP version, and then second,
what the alternate languages we have available are. And I’ve included
a link to the AMP by Example for this
as well, if you want to take a picture of it
and then check it out later, for the detailed guide
on how to do this. So in some cases, I know
that we don’t actually want to vary the
whole page, we just want to very part of
the page based on where the user is coming from. In this case, we can
use amp-list to render geospecific data. And the first step is to, in
the amp-list server endpoint, we’re going to approximate
the user’s location using their client– using their IP address. We then alter what
we’re responding back with to amp-list in order to
render the geospecific data. So in the amp-mustache,
in this example here, we’re varying what
the value of location is. And so we’re setting
it to Amsterdam, because we are, in fact,
in Amsterdam right now. And then we can use that through
the amp-mustache template and show the user
where they are. In this case, you
are in Amsterdam. And then one more example
that I want to go through for personalization
and geovariation is altering the page
based on user input, so based on what
the user is doing, changing what information
we’re showing them. And in this case,
basically, we want to show the user a
shipping price that’s specific to the country
that they want to ship to. So if you’re shipping something
from Amsterdam to the US, it’s probably a different
price than if you’re shipping it from Amsterdam
to Berlin, or something. So the first step
here is that we’re going to show the user
the set of countries that they can select from. And here you can
actually use some of what we showed in the last example. So say you already know
the user is in the US, maybe the first option you show
them is the US based on where they’re coming from,
because it’ll be easier for them in that case. Then we’re, again,
using the on attribute, so when a user
selects a country, we’re updating the
value of list source to be an endpoint that is
specific to that country. Then we’re again using amp-list
to render this information. And we set this endpoint
equal to list source, so it’ll change depending
on what country the user has selected. And then what is
returned will also vary and will show them
exactly the information that they’re looking for, so
shipping to whatever country they’ve selected will cost
whatever price corresponds to that. And now the last
experience I want to highlight that
you can build now is just a check out
payment experience in AMP. And this is actually
really easy. We’re just collecting
information using amp-form. We can even do some fun stuff
like showing a different credit card image depending on what
card the user is inputting. And then we can easily submit
this, handle the payment processing server-side,
and then show the user a confirmation message
on whether or not that payment was successful. Really, all you need is a form. All of the heavy lifting here
is being done server-side, so the only thing that’s– you need to make sure
that you’ve done correctly is setting the action-xhr
attribute equal to whatever endpoint is going to handle
the payment processing. You can obviously also
change how this page looks based on the success response. I’m not going to
include all of that here, because we do have a
really detailed guide on AMP by Example. And I’ve included the link here. It will show you how to do
everything that you likely want to do with forms,
including validation, including error handling, all
of that good stuff. Just for fun, I did
include the code that we used for updating that
credit card image based on what number the user is typing in. Because they’re kind of small, I
only included the visa example. But here, basically,
the first step is to create a custom
CSS class for visa. So in this case, the
ccInputContainer.visa will have a background
image that is the Visa card. Then we’re going to use
an amp-bind macro just for ease of marking this up. But basically, is visa
will return the value visa, if that card number is a Visa
card, and an empty string otherwise. We then have this input– we then have this
element, that’s the ccInputContainer that
includes both that credit card image as well as an input field. And you’ll notice
that we’re setting this class equal to
cctype, so remember that. As the user is typing,
we’ll use the on attribute to basically evaluate that
amp-bind bind macro is Visa. And if it is a Visa
card, then we’ll add– we’ll change
that class to Visa. And in this case
then, we’ll apply that CSS markup to have that
background image of a Visa card. And then you’ll see
it change and appear and disappear based on
what that card number is. And you can easily
expand this to include MasterCard, Amex, all the
different cars that you are accepting on your site. So those were the main examples
that I wanted to highlight. I’d like to now bring my
colleague Michael onstage to talk a little bit
about AliExpress’ product pages and the different
ways that they built that experience. [APPLAUSE] MICHAEL YEUNG: Thank you, Lisa. So I’m Michael. I’m a developer
advocate at Google. And unfortunately, the engineers
from the AliExpress Web Development Team could
not be here today because it’s Chinese
New Year [INAUDIBLE],, and so I’m lucky enough
to represent them until then at Amsterdam,
so it’s good, good stuff. So AliExpress, let
me just kind of bring a broad background on
what the company does, right? It’s a global B2C retail
powerhouse, really, part of the Alibaba Group in China. And the main mission is to
connect Chinese merchants with consumers from all
over the world, right? And they launched the
aliexpress.com property in April in 2010, has since
then has seen explosive growth in a really short history, to
date has served more than 100 million customers worldwide
across numerous languages and numerous countries,
so that’s great. And their web
traffic is obviously nothing to sneeze at, right? Like, today, they are
ranked number 48 globally on the Alexa Traffic Ranking. So all seems good, but not
really on the engineering side, right? As engineers, we
all know what it’s like to accumulate
technical debt. And the AliExpress
is no different. Now their frontend code has
been modified by generations of engineers, each bringing in
their own favorite tech stack, right? And this worked for a
while in the earlier days when code health, code
maintainability was not a big deal, kind of took a
back seat to aggressive drive for growth. But at the scale
today, a hodgepodge of frameworks that they
were using held together by duct tape is just
not good enough. It’s expensive to maintain. And a couple years ago, they
introduced asset caching with service workers to try
to improve their second load, provide a more consistent
and reliable user experience. That went great. That went well. They saw uplift. But ultimately, the
fundamental problems that comes with loading and
parsing too much JavaScript exists. It is a problem. And they need to address
that, need to fix that. So time to start over, right? Now as they went looking
at the different frameworks and different paths
they could take, AMP was one of the
paths they could. And they wondered whether
AMP was the right answer. Now, the most obvious
thing that made them ambivalent towards AMP
is AMP’s guided constraints, primarily restriction of
third-party JavaScript. Now without JavaScript,
how can they even begin to offer
a feature set that is similar to what they had? What comprises
they have to make? And secondary to
that is that you also know that, like, the AMP
for e-commerce vertical is somewhat raw. It’s new. Not many companies have
done it, and so there will be pain and growing
pains along the way. And they recognized that. The risk tolerance level has
to be a little bit higher. But think of it harder, right? Like, there are a few things
about AMP that stood out. That’s just shown. Probably the single
most important thing is just performance. A framework that guarantees
consistently high performance. AMP not only provides
it, AMP enforces it– and that’s valuable–
through AMP validation. If it validates, you have
good confidence [INAUDIBLE].. If it doesn’t validate, you
don’t already know, right? So that’s something you
shoot for, validation. They are big fans
of web components. And the wide adoption of
web component standard within browsers today
is encouraging for them, for the web development team. Now, AMP components
are web components, so that is– that’s great. That’s something
they want to do. Now, tying the main product
to any framework is scary. And so they needed one that
they can at least meaningfully participate in, but better
yet, they can influence. And AMP has a track record of
that, lots of contributors, lots of changes, quick fixes. And they also face a lot of
internal pressure to ship. They started thinking about
this in November last year. And they shipped in
January, 2 months, right? So there were a lot of changes
that went on in the back end, in front end. But at least on the front end,
client stack– client framework they can pick, they want
to [INAUDIBLE] easier to work with. AMP fits the bill here. So considering the
pros and cons here, they decided to revamp their
mobile site to an AMP site on the pages which drive
the most user traffic, so those would be the home
page, the product list page, the product detail pages. So before I go on, let’s just
look at what the results are. Everything on the right, all
the pages are all valid AMP. There’s the home page. The user clicks into a category. The category pages show up. You pick a category as
a user, scroll down, pick more categories,
subcategories in this case. And then this is the– this is the page that drives
the most traffic from– as a user, the
product list page. And they have this, like,
massive filter with two layers, with very many dimensions
that they filter to us. It’s quite complicated,
but it’s on AMP. Pick the sizes. And click through
to the product, which is the third set
of pages that they AMPed, the product detail page. And here will be a typical
[INAUDIBLE] which you would see on typical e-commerce sites,
all valid AMP, all of it– very nice. Now, I guess the only
question that really matters is this one question, right? Did AMP help their metrics? Everything else is really
irrelevant, as a business. And the answer is, yes, it did. Technical metrics
first, just load speed. Time to page load
decreased by 40% across the board on those
pages which they AMPed. And that’s great. And on some– on the
product list pages which drove the
most traffic, they saw page load speed decrease
by 50%, even higher than 40%. So that’s great, faster
pages, but what about business metrics, conversions? The translated to an
increase in conversion rate by more than 4.3% for new
users to their website. And for users who visit through
non-paid, non-search channels, that conversion rate
goes up to up to 20%. Conversion rate here means
purchase rate, so the people that actually buy
stuff, so that’s awesome, really exciting. So how did they
get there, right? So we’ll talk about
some features. So on the right, you see
one of the detail pages. A lot of animations going on,
but look at a top action bar. As the user scrolls up, the
action bar goes from opaque to transparent. As it scrolls down, it goes
from transparent to opaque– well, almost opaque. And this is actually
a really nice design. And the reason why that
is is when you’re up top, you don’t want your action
bar to hide your image. You want full real
estate to dedicate towards your image,
the watch in this case, so you want action
to be transparent. As you scroll down,
you want the action bar to anchor your app experience. That’s good design. And that’s what
native apps do, right? You see that in
native apps today all the time, so, pretty nice. How do you do it– amp-animation. Now to do this animation–
and this actual– this is real code from their website. You can go look at it after
this, the source code– simplified a little
bit, but very similar. You first define the
how in the animation. In this case, you
set up keyframes. So in this case that’s really
only one ending keyframe. And that is when it’s full
opacity, almost fully opaque, 0.95. And since this is animation
is triggered by scrolling, duration really doesn’t matter. You can anything in there. It’s not triggered by time. It’s triggered by
scrolling, right? So you defined a how. Now you define the when. In this case, they insert a
dummy div, 00 by 0 pixel div, that is fixed position. It’s anchored. So as the user scrolls, that
div moves with the scrolling. In it you observe the
movement of this div with amp-position-observer. And as soon as the user scrolls,
the amp-animation-observer cause the amp-animations
seek to method. And so the rest
is just taken care of by internal magic of
the Web Animation API, where it linearly determines
the animation’s opacity based on the scrolling percentage
parameter that you pass in. There you have it. Next up, star ratings,
e-commerce sites have them all everywhere,
for reviews, user feedback. AliExpress is no exception. So there is no amp-star-rating
component today. There just isn’t. And so they needed to
figure a way around this. So it’s really not
all that complicated. It’s, for them, a
pretty simple solution. They imported a web font
for– that renders as a star. So they specify that
to a specific Unicode, in this case, e60f. And so they have, like,
two separate CSS classes, one for when it’s
bottom, when it’s gray, and the other for
top, when it’s red. And then they define
individual CSS selectors for each rating
between 0.0 and 5.0 in 0.1, so 51 total
CSS selectors. It’s obviously not going to
scale to, like, 1,000 or 10,000 interval scales, but
for 51, it’s fine. It’s a good workaround. The rest is easy, just specify
the star with the correct CSS selector and you have it. Now probably the
most critical piece of e-commerce of the user’s
journey is add to cart. And AliExpress
uses a combination of AMP components to do this. And so on the right,
you see, really, for this one particular
product, there are three SKU properties,
one for color, one for size, and one for shipping country. So in this case, it’s
multidimensional with three dimensions. Your basic logic will get fairly
complicated as you scale up, so something [INAUDIBLE] for
them, like 3, it’s complicated. I’ll show you the code. So how do you do this, right? So first they define
a JSON data holder that keeps of the user
choice as they click around their product. So in this case, they
define an amp-state which they call detailSkuState
and a three-dimensional SKU property at the bottom. [INAUDIBLE] for now
is to initialize. That keeps track of
the color, the size, and the shipping country for
this one particular product. Next, amp-buying
comes into play. It coordinates the states as
a user and the rest of the UI. Now, when the user taps on
a specific SKU property, in this case the
example is shoe size, you change the SKU
property variable to take on whatever the correct
shoe size is, 6 in this case. And all visuals have to
change the UX for the radio button and all that, but the
main logic for the binding happens with an nset state. And then the rest of
it is just making sure that the correct UI element, the
heading in this case, header 3, gets bound to the correct SKU
property as you type around. Now, showing responsive
feedback to user interaction is one of the most
common ways that people get improved UI design. So AliExpress handled
error-handling logic and responsive feedback
UI in this form of this, like, floating, black,
transient, message bar that floats up when a error occurs
and then disappears again, so it’s kind of
like a [INAUDIBLE],, but their own take on it. So this is great,
how they do this. Well, it’s really–
the magic happens in just defining and designing
the animation in code. In this case, it’s– they define
a series of keyframes that denotes that a message
box starts off being fully-invisible, and
transparent, and at the bottom, and ends up in the middle
as being fully-visible, and opaque, and
translated in the y-axis, and then fully-invisible
again as it falls, so just a series of
keyframes that they designed. And this all happens over
a span of three seconds. Now, when the add to
cart button is pressed, they do three things. They set the display text. They show the dialog. And they animate the dialogue
through that animation that we just showed. Now, of course, if
everything’s ready to go, the last bit is to add to
cart, the actual adding it to the cart. Now, this is
accomplished by amp-form. And let’s see to do it. They first define a form that
takes the appropriate action to take on the server-side
through a HTTP/S endpoint, has to be HTTP/S. This
actually, on server-side, this actually does the
work of adding it to cart. Next is defining what
happens on a client-side. The client-side, they
already had that beautiful, transient message
bar that we showed, so let’s resuse that for this– to put in text
that tells the user that they have
successfully added to cart. Assuming it’s mission
was a success, they send a text string,
item added to cart. They animate the message bar
just like they did before. And then lastly,
just fill the form with the specific SKU, the
properties, the quantity, et cetera, et cetera. And they send it. And that’s that. Now the last bit of
take-away, really, is that they realized that
the success of AMP is now– their success is now tied
to the success of AMP because they use the framework. And so participation
in AMP community is really paramount,
not just for themselves, but for the broader
community as a whole. So over the past two months
they have encountered a reported multiple issues against many
of our favorite components, amp-list, amp-bind,
amp-image, amp-lightbox. And they were
excited to see, like, many of these issues actively
addressed by the community, and in some cases, fixed. So there are still
things that AMP does not handle well that are
important for use case. An example of this is the
timer countdown component that is good for, like,
deals, promotions. That is not handled as– you actually have to fall
back on the trusty MI frame to work around it, really. So they are actively
planning to contribute code that would help drive to
create such a AMP countdown component. So getting to this
stage really takes combined effort on the community
and on their end, of course. So I would encourage
everyone to continue to file bugs, resolve bugs,
submit fixes, raise issues, raise questions. And it’s good for AMP and
good for your project. And with that I’ll hand it
over to Paul Li from Oath. [APPLAUSE] PAUL LI: Hello, everybody. Let’s just set up. Oops, I need to type
my key word again. Sorry about that,
company policy. OK, I’m so happy to be here. And allow me to introduce
Yahoo Taiwan Auction to you. Yahoo Taiwan Auction
is the most popular and the biggest
e-commerce site in Taiwan. It’s kind of eBay-like,
client-to-client, C2C-type. So seller can post
item for sale and buyer can find something
interesting to buy. There are more than 30
million items on [INAUDIBLE].. And it also won the most people
of [INAUDIBLE] in the world for years. Yahoo Taiwan Auction
has been served over than 15 years in Taiwan. However, there’s some page still
not mobile-friendly, in fact. So that’s why we decide to
adopt them as our mobile page and give it a try. So we pick up the top
web traffic page to as our first AMP page. And this is our
item page in real. So you can see here. And we will make a
new design to fulfill to make it suitable
for all mobile device, so we can have a clear
and pretty item vision here in carousel. Of course, people can find
some useful information here such as item title, price,
pay type, and also ship type here. Multi-image, multi-media,
like video, image, are all supported. So you guys can see here we
also have some micro-interaction here, so make every
action smooth flow. Once people doesn’t
like this item, we also prepare view also view
and the recommendation module to our user to let them
have more choice to find out exactly item they like. So this is our item
page for AMP version. Of course, we add some
instrumentation data off Google Organic to
compare the result about it before and after, so let’s
just take what we saw– take a look about the
result. Before we start, I will tell you, we
use the blue line as after and we use the
purple line as before, so let’s just check it out. We increased 30% in users
and 133% in our new user. Ooh, it’s a huge improvement. How about the [INAUDIBLE] rate? We successfully decreased
33% than before. So you guys can see
here the blue line is much lower than
the purple line. How about the [? transaction? ?]
We also increased 26% about the [? transaction ?]
and 34% in our revenue. Each metrics looks awesome. And try to imagine, this
is just one AMP page. We never expect the wonderful
result we will get with AMP. All we want to do is just bring
a very good user experience and excellent visit
flow for our user. We can do better. Based on our
instrumentation data, we know our user like
to do our search. And also they like
to do our like. Do you guys see the heart here? This is our like button. So we love to do some
enhancement for them. Also if it is very– it is disappointed to
use JavaScript in AMP. But we still believe in once
we realized AMP component do. We can combine them
and transform them into more interesting
feature we like. So I will show you how Yahoo
Auction do in the next slide. The first, we
build a suggestion. Suggestion is very common
in web, but not in AMP. With suggestion, user could
exactly find exactly key word to search. This is very useful
for our user, so here comes some
AMP components we use, amp-list,
mustache, of course, amp-bind, and amp-event. I would like to do,
like, a quick demo here, so when a user just
visit our item page version and they just press
the magnifier, so we will show the input field. And all user just like you
do is just type the key word. I would like to use AMP
here, so when I type a– I’m sorry about
latency, back to Taiwan. All right, you can guys can
see, the suggestion just pop up. And then we will
have a list here. So when I type A-M-P– see? This is how our suggestion work. So let’s see, let’s take a
look about the structure. Actually, we use input for user
to let users type something. And the next input
is the amp-list. This amp-list is
also our suggestion. Then we use the
amp-state as the bridge between input and
amp-list to let them communicate each other. Once input value
change, amp-list will go to fetch new data here. So when data back, we
generate element by mustache. So you guys can see we
use the mustache here. Each suggestion is
built with a tag. This mean it is very easy to
add instrumentation on them to collect the user behavior. But either way, it is
kind of annoying for us to decide when should we
turn the suggestion on and when should we turn
the suggestion off? We don’t like to leave
too complex logic here, so we leave this part in CSS. With CSS in charge,
things become easier, and more maintainable,
and more powerful. All we need to do is just
write the correct CSS. So let’s see what CSS we use. We use a pseudoelement, a
placeholder-shown, and a tilde to connect input and amp-list. What does this CSS mean? This CSS mean the
suggestion won’t show until input value is not empty. All right, so let’s
take a look about this. When I just clear
the input value, the suggestion should
be disappeared. See? There it is, it’s work. Effective CSS can
lose everything. So this is our
suggestion module. In this case, we can understand. Once we understand, we
recognize each amp component do. We can use the minimize element
to build any feature we like. So use AMP as mobile
page is not a dream. It became reality. Next, I would like to
share is our like function. In our service, people
like to use like function. Why? Because once they press the Like
button, we will record them. So they can find the liked
item in list anywhere, anytime. Once the item is on sale, we
will also send a notification to user, so they can
catch up the hottest information about the item
price and decide buy it or not. That is why our users like
to use this feature so much. So here also comes
the amp component we use, amp-form, amp-list,
mustache, amp-bind, especially amp-access to
binding or log in system. So I would like to show
the structure here first. So we use the amp-list
to fish the like status. And then generate by
mustache, and you guys can see when the
data back there will be like here, so the like
may be a great means you now like it or it mean you
never pressed like. Maybe the heart will
become a red one. This mean you like it. So when user just
press the Like button, we will send a request
through amp-form. And we will catch up
the server-side response by amp-event, such as submit
error or submit success. Once submit error, we will
use amp-state to transform server-side response
in the title and then tell our
user what to do next. If the response success,
of course, we also use the amp-state
to change the style. I like the amp-state
to change class name, just because I can do
some animation here. With animation, things will
become more interesting, more vivid, so I would like to do– to go through the
whole process with you. Once people like here,
and he like this item, he just need to press the heart. So we will have a dialogue here. It is built in Chinese. I can translate. OK, this will tell our
users list function is login member only, so you
can choose to log in or not. So in this case,
I choose log in. And this will bundle
Yahoo login system. When this is finished,
we just press the like. You can see we have
an animation here. And this is our like function. All right, so after
this, we start thinking, how to deliver these
features in different page with effective way? So we componentlize
this feature. Once page [INAUDIBLE],, all
they need to do is just require and everything is done. This is our sale page,
so you guys can see, it is also display some item
which this seller to sell here. Of course, the suggestion
has already built in. And you guys can see each item
cart have like function, just like I display here. And so does our category page. This is also AMP version
and our search AMP version. More component we have,
more develop speed we gain. So develop AMP page
is just like playing Lego, piece-by-piece,
state-by-state to complete the whole page. Things become easier with
list reusable components. So can you guys imagine,
oh, these three page were complete in just one day? This is exciting, this
is so exciting for us. And we are happy–
we really do this. OK, thanks for AMP project team. You really do us a big favor. And thank you all to
listening my sharing. I hope this is useful for you. Thank you. [APPLAUSE] Now back to Lisa. LISA WANG: Thank you to Paul. Thank you to Michael. I think it’s really
awesome– thanks –to see the implementations
that are alive today, and all of the cool things
that different sites are using with AMP. So, continuing on our journey
of building great experiences for e-commerce, once
you have actually built out these
experiences, the next step is getting these pages
live and testing them out. So usually the first challenge
that we see sites face is actually just getting
these pages indexed and live. And sometimes it may
seem like the indexing and the crawling process
is a bit of a black box. We have some search folks
here who you can talk to you, but really, the first and the
best step that you can take is to become close, personal
friends with the Search Console. And they recently
actually launched a new version of this with a
revamped AMP dashboard, where you can see a lot of information
about how your AMP pages are doing. And here, you should
see two things. You should see zero AMP errors. And you should see
an AMP page count that equals what you believe
to be the number of pages you’ve published. If you don’t see
zero AMP errors, then you should fix your errors. And you should start with
the ones that are the most severe and the highest impact. And the Search Console
will tell you this. It will tell you what errors
are causing the most issues on the most number of pages. And then you can
easily prioritize what you need to fix. Once you have
fixed an issue, you can issue a request
for revalidation. So Google will go and
check and make sure that, in fact, this fix is live. And it’s working. And now your pages are valid. If you see that your
AMP page count is less than the number of pages
you know that you’ve published, then first, make sure
that you’ve linked your AMP and your
non-AMP pages correctly, or if you’re doing canonical
AMP, your AMP to your AMP document itself correctly. This makes sure that Google
can discover your pages and then show them correctly. If you’ve ensured
that that’s done and you’ve also ensured that
you haven’t blocked indexing in any way, which
we have seen happen, then you can issue a
request for a recrawl. And Google will go
back and make sure that it’s recrawling your site. Once your pages are
indexed, and they’re live, the next step is to really
start comparing your AMP and your non-AMP performance
to get an idea of what AMP is doing for your site. And we’ve seen two methods here
work out really well for sites. The first is to compare
historical and non-AMP performance with present
day AMP performance. And the key here is to
make sure that you’re comparing as apples-to-apples
as possible, right? You don’t want to
compare holiday season non-AMP with, like, a
random Tuesday in March AMP, because you’re not going to get
an effective comparison there. We really want to make sure that
the time periods are similarly performing, so you can get a
good idea of what AMP is doing. The other method is to
compare a non-AMPed page A with an AMPed page B,
where page A and page B are very similar and also
are similarly performing. So in this example, J Crew
actually compared their shirts and tops non-AMP page with
their sweaters AMP page. And then they were
able to see, you know what, these pages are
pretty similar generally, and so we can see how AMP is
doing for the sweaters page. If you are not seeing
the results that you– if you are not seeing the
results that you expect, if you’re seeing that
conversions or any of the metrics that
you really care about are not looking the way that
you would want them to look, there are a few troubleshooting
steps that you can take. So first and foremost,
make sure that you have the client ID API fix
that Google Analytics released implemented. This is going to make sure that
we actually track conversions correctly, because when you’re
moving from the AMP cache to your origin site,
there is a chance that– I mean, there’s a chance that
that user will be interpreted as two separate users. And in fact, a conversion could
be interpreted as a bounce, and so we want to make
sure that this fix is in so we can accurately
track users as they move through your conversion funnel. The next step is
to really make sure that your AMP and your
non-AMP pages are at parity. So I talked about
this a little bit before, about making
sure that you’re highly-interactive components
are included on your AMP page. But this is– and this is
a really nuanced, right? I’ll give you a quick example. We were working with a
site a few months back that had built lead generation
pages, so there’s a form to collect information
about their users. And, like, microscope
to these pages, they were identical, the
non-AMP and the AMP versions. Pixel-for-pixel,
they were the same, but as we were interacting
more with them, we found that the date field on
the non-AMP page, it was fancy. It had the date picker. It was easy for the user to
actually tap there and select a date. But on the AMP version, it was
just a freeform text field. And that was enough to
really deter the user, because they didn’t know what
format the date should be in. They didn’t know of
month should go first, if date should go first,
if the site wanted years, all that information,
because dates can take a lot of different forms. And so this is really
to say that, you know, you’ve put so much effort
into building your AMP pages. Make sure you’re
not just one easy win away from seeing that
uplifting conversions that you’ve been hoping for. It’s a really easy fix that
they were able to make. And then they were able to
transform that experience for their users. The last thing
that you can do is, there are a few GA,
Google Analytics, tricks and tips for really making
sure that you’re getting the right data with AMP. So for example, if you’re
seeing that the data source AMP attribute, which
most people use to compare AMP and non-AMP, is not
being applied correctly, so maybe an AMP page is really
being tagged is non-AMP, you can actually create a
custom dimension for AMP to make sure that you
are explicitly saying, you know, this is my AMP page. These are my no-AMP pages. Let me see what the
difference in conversions is. And all of this
documentation is online. And you can also work
with your account team to make sure that everything
is set up correctly. So once you’ve
launched your pages, they will automatically
show up in organic search, as long as you’ve
linked them correctly. But we’ve also, as
mentioned in the keynote, we’re launching experiences in
paid search for AMP as well. So this past year,
the Adwords team launched their AMP
integration, where now, you can direct traffic to your
AMP pages from ads as well, giving your users that
same instant experience that they’re used to. At this time, this won’t
automatically happen. You will need to
go on to Adwords and actually explicitly say,
I want to direct traffic to my AMP pages,
but the Adwords team has extensive
documentation on this. And you can also, again,
work with your account team to make sure that
it’s set up correctly. And again, if you’re familiar
with the shopping carousel, the Google team is working
on piloting serving traffic from these to AMP pages as well. And so as they’ve been seeing
these really encouraging results, if you’re interested
in participating in the pilot, let your account team know,
and they can help set that up. So that is, end-to-end, how you
can build exciting and awesome AMP experiences for e-commerce,
from picking which pages to start from, to deciding
which experiences to build, building dynamic and
exciting experiences, and then finally testing
and launching them. So now it’s on to you. You can easily get started
with our documentation on ampproject.org. Sebastian and Chiara
have also built some really awesome e-commerce
examples on AMP by Example. And again, please, as we’ve
continued to emphasize, interact with us on GitHub. Let us know about issues,
bugs, feature requests. I think you’ve heard from
all of our guest speakers that the AMP team is so
excited about e-commerce. And we’re so excited to
get feedback from you guys, and really continue to grow
and develop the product as you guys are adopting it. So that’s the talk for
today for e-commerce. Feel free to find any
of us afterwards and ask any questions that you have. Thank you. [APPLAUSE] [MUSIC PLAYING]