AMP Ads: Better Advertising on a Faster Web (Google I/O ’17)

AMP Ads: Better Advertising on a Faster Web (Google I/O ’17)


[MUSIC PLAYING] VAMSEE JASTI: Good
morning, everyone. I hope you’re having a fantastic
time at Google I/O. We’re super excited to talk to you
today because only the most dedicated developer audience
would show up for a talk at 8:30 AM on ads. But in all seriousness, we
have some exciting stuff to share with you today. So, thank you for being here. I want to start by
telling you a story. I grew up in south
of India where access to the internet
and technology was considered a luxury. I was a pretty bad
student growing up, but once I reached
college, I was pretty good, generally ranking in the
top five students in class. So what changed? For the first time in my life,
I had access to the internet. And having access
to the internet allowed me to consider
multiple different sources and draw my own
conclusions instead of having to rely on
a prescribed textbook. And I think this access to
free information and exchange of free ideas is really what
helped bootstrap the internet. Advertising, as we know it, is
the lifeline of the internet, and I think it makes the
internet truly for everybody instead of just a select
few, and for businesses to put their content online
and make money off of them. Today, we’re going
to talk to you about how we’re using AMP
to make advertising better on the web. So I realized that
not all of you are probably working
in the ad space. So I want to just start
by talking about two definitions, very simple terms. So when we refer those
terms, they actually make sense to you. First, is a publisher. A publisher is anybody
that puts content online. And when I say publish, you can
think of somebody like New York Times. And obviously, publishers range
from large ones to small ones. And the second one
is an advertiser, who generally has a product
or service offering, and wants to
advertise it online. And think of somebody
like Coke wanting to advertise with New York
Times by showing display ads. OK, with that out of the
way, for those of you who haven’t used AMP before,
or looked at it before, AMP is an open-source framework
to build really fast pages with very little
engineering effort. As you can see in
the demo, the AMP– this was one of the
first implementations on Google Search. And you can see how
quick the experience is. You tap on a link, and the
page appears in an instant. And AMP was born out
of a collaboration of a small set of
publishers when they felt that the experience
that the mobile web was offering was not great. And they thought
they could do better. And today, AMP has evolved into
a diverse set of publishers with an open and sort of
collaborative approach with a bunch of publishers,
advertisers, [INAUDIBLE] companies, with
one goal, to make the mobile web much better. And since launch, just
18 months ago, we’ve seen some tremendous adoption. We’re seeing in the search index
about 2 billion AMP documents spanning over 900,000
different domains. An average web page– from a recent study showed
that an average web page loads in about 6.9 seconds. For the search corpus, we
saw that an average page loads in under one
second, median time for all of those AMP pages. And all of these numbers
are just from one platform. A number of other platforms
are coming online, including Twitter, Baidu, LinkedIn, Bing. And a number of them though
were introduced yesterday in the AMP keynote. And in AMP’s year
two, we want to focus going beyond just static
content use cases. So we’d like to make sure AMP
works for more advanced use cases like e-commerce,
retail, and travel, but there’s one problem. The problem is that all of
these advanced use cases generally require a ton of
interactivity on the page. And we’re super
happy to announce that, including
yesterday’s AMP keynote, we’ve been working on a number
of features that promote interactivity with an AMP. I’d like to talk about just
one, and that’s AMP-bind. Think of AMP-bind as
a programming layer on top of AMP. It allows developers
to define sort of a state of an AMP document
based on user interactions. This gives developers
the flexibility to mix and match
different AMP components, and while ensuring
that developers are able to provide great
interactive experiences, not worrying about performance,
because the AMPer, in time, takes care of all of it. So at the end of
the day, AMP is just a bunch of web practices
put together on the web. And you know which
other area requires a bunch of best practices? That’s ads. And I’d like Michael to tell
you about all the problems that are present today
with ads on the web, and how we’re using
AMP to fix them. Michael? MICHAEL KLEBER:
Thank you very much. Hi, I’m Michael Kleber. Ooh, thank you. [LAUGHS] [APPLAUSE] I’m a software
engineer at Google in the Cambridge,
Massachusetts office, and my job for the
last nine years has been to try to make the
ads ecosystem faster and more efficient. There have been a
bunch of improvements in the technology of the web. The web platform has
really grown recently, and we try to make
use of all the most recent best
practices in the ads. We’re all just like people
who write web pages try to. Well, today, AMP is
a new incredible tool that I think can really
change the landscape of what display advertising
on the web looks like. So when we started this idea of
using AMP to make ads better, we looked at a few core
issues that show up in today’s ads ecosystem. And let me talk
through three issues. I think one of the keynotes
yesterday mentioned these as well, so this might
sound a little familiar. So the first one’s
disruptive user experiences. And we’ve all been there. You’re in the middle
of reading an article, and then you slam into a
disruptive roadblock, which says you have to wait
five seconds before you can keep going. Or maybe you’ve seen that thing
where you start reading a page, and then while
you’re looking at it, suddenly something
shows up elsewhere on the page that makes the text
you’re in the middle of reading move around from under
your eyes, which is just a horrible user experience. If you’re trying
to convince people that a web is like a
book and you can read it, and then it suddenly moves while
you’re trying to look at it, it just breaks the entire thing. So those are terrible
user experiences, which we’ve come to
think of as standard, but we would really like the
web to do better than that. The second thing that’s
a problem with ads is that ads often load slowly. Frequently, that is caused
by heavyweight scripts, lots of heavyweight
JavaScript that is involved. And sort of a poster
child for why this happens is the question of
viewability, right? Viewability is not something
that most people outside of ads think about, but
advertisers, unsurprisingly, want to know whether
their ads actually got seen by the intended
audience, right? It influences how much
they’re willing to pay to buy some space on that web
page in the future, right? So it’s common for
advertisers to work with a viewability vendor
that runs JavaScript inside of the page to measure
whether the ad is on-screen, or how much of it is
on-screen for how long. But, of course, a
publisher also wants to know that about
their own site, so they probably also
have a viewability vendor, and maybe the ad network
that put things there has a viewability vendor as
well that does the same job, and the result is
that there might be a bunch of different
scripts on the page coming from different
places that are all trying to do the
same basic operation, but depending on how
it’s implemented, it might be a relatively
heavyweight CPU-intensive thing to do. There’s no coherence between
these different scripts that are performing what’s
more or less the same task. There’s an enormous
amount of duplication. All of this makes
the ads slower. But remember, there’s only one
JavaScript thread in a browser, so if all this stuff is
making the ads slower, it’s actually making the whole
rest of the page slower also. So the ads are slowing
down the experience of the rest of the page. The third common issue
that we hear about a lot is that ads are not safe. And now, it’s not news that
ads create security concerns. You might have heard a horror
story from a couple of years ago where a publisher asked
people to turn off their ad blocker for that
particular site, and then when they turned
the ad blocker off, they got malware installed
on their computers. This is a horrible
story, but the sad truth is that right now, it is
very hard for the publisher to do anything about that,
because when a publisher lets ads onto their page, they
very often don’t know where the ads are going to come from. They leave that up
to their ad network. And that ad network might end
up talking to other ad networks, and the ad itself
can end up coming from a wide variety of places. And in the end, we’re left with
trying to solve the problem of, is it OK for content from an
untrusted source to run here? Is it going to do something bad? Can we trust this content that
comes from an untrusted source? That is a very hard problem. I mean, we try to
do it, certainly, but there’s an arms
race between people who are trying to solve the
problem of protecting everybody from untrusted
sources, and people who are trying to get malicious
code to run on your machine. OK, so given this set of
core issues, let’s talk about how we address things
in AMP when AMP first launched 18 months ago. Publishers who wanted to
use an AMP for their pages had to rebuild their pages. They had to rewrite their
pages in this new way. And it would have been
an impossible task if we had asked them to
rewrite all of their ads at the same time,
because remember, the ads aren’t coming
from the publishers. They’re coming from
some advertiser out there in the
world somewhere. So in order to get
AMP off the ground, we had to make sure that the
existing ways that publishers use to get ads right now still
worked even on AMP web pages. So we did a few
things that we thought struck a good balance between
end-user experience, ad safety, and the
ability of publishers to monetize their pages. The first thing
we did was require that all ads have a size
before making the ad request. You might think that
that should always be the case for the
entire web, but it’s not. But it is on AMP pages. That means that the
AMP runtime does not need to wait for a
response from the ad server before it can lay
out the page the way it’s supposed to
look for the user. If an ad server turns out to be
slow, you might not see the ad. You might see a blank rectangle
where the ad is supposed to be, but at least it won’t cause
things to jump around later when the ad is supposed to– when the ad finally comes back. Another huge positive here is
that the fact that everything needs to be laid out in
its proper place when the page starts and
can’t move around later, means that you can’t add
interstitials that pop up and cover up the content
when you’re partway through. Second thing we did was to
separate ads from content by putting them in a
sandboxed cross-domain iframe. The point here is to exclude– is to ensure that the
contents of the ad is somewhat isolated
from the parent page that it’s inside of. Browsers offer the
sandboxed iframing, which allows us to block plugins
and prevent a variety of types of behaviors that might happen
inside of the ad that adversely affect the rest of the page. This is something where the web
platform is growing right now. The set of things you can detect
and prevent using sandboxes keeps improving over time as
browsers add more capabilities. In some cases,
it’s even possible to learn that an iframe is
doing bad things, like consuming too much CPU, or slowing
down the frame rate when you’re trying to
scroll on the page. And in those cases,
the AMP runtime could actually
destroy the iframe, get rid of the ad inside it,
and reclaim that performance that the ad is dragging down. AMP’s ad frame also
provides some modern APIs that not all browsers
have implemented yet, things like
Intersection Observer, so that the JavaScript
inside the ads doesn’t need to do these kind of
heavyweight, high computational intensity things for
determining viewability. The AMP runtime knows where
everything is on the screen, and it can just tell
the ad where it is, as opposed to a lot of
JavaScript involved in answering that question. The third thing we did was
gave ads lower priority compared to the rest of
the contents of the page. Even with all the
safeguards we put in place, ads could still drag
down performance once they start running. So delaying them gives
the rest of the page a chance to render
properly first. We made this decision so
that content is always prioritized over anything
else on the page, and the user ends up
always experiencing that page like the author of
the original web page intended. So that was all to
give users a better experience with the ads on
the page, but of course, there’s the question
of what did it mean for the publishers whose
pages we were messing around with? Vamsee. VAMSEE JASTI: Cool. Thanks, Michael. So we took a number of user
experience best practices, and applied that to ads on AMP. But do they actually
monetize well? Because think about it,
if a publisher that’s an ad-funded website
doesn’t actually make any money,
or less money, why would they choose
to publish AMP pages and make the mobile web better? Maybe they want to, but overall,
not everybody would do that. So we asked our
friends at DoubleClick to tell us how AMP
pages were doing compared to non-AMP
pages in terms of publisher monetization. The results were compelling, and
more than 90% of the publishers were experiencing a higher
click-through rates on the ads. Over 70% of the publishers were
seeing a higher viewability, and another 70% were
seeing higher eCPMs, which translate to overall revenue. So how can pages with
some restrictions on ads actually perform
better than pages with no restriction on ads? We think the secret sauce
here is the AMP pages. Though the fact that the AMP
pages load so fast compared to a regular page, the resources
that are meant to usually go to the page instead
end up with the ads, helping them load much
faster, compared to– even though the ads relative
to the AMP page appear to load slower,
in absolute terms, the ads appear much, much
faster than a non-AMP page. Also, publishers typically work
with a number of different ad networks, and it would
have not been great when AMP launched to say that,
oh, you can only use one or two different ad networks. And from day one, given
AMP’s open-source DNA, we wanted to ensure that a
number of different ad networks could seamlessly participate
in the AMP project. So today, we have 100
different ad networks that are supported within AMP. Think about it. 100 different ad networks
had spent developer resources to commit their AMP ad
extensions into the AMP project. And we super, super
happy with that. And we’re constantly
launching a number of different
ads-related features, and we want to ensure
that all of these features are available for all
of the ad networks that would like to implement them. And I’d like to talk about
just two features that would help monetization
even better for publishers. The first one is AMP Auto Ads. So the AdSense team at Google
worked with the AMP ads project to create the AMP
Auto Ads framework. Traditionally, website
developers usually have to put multiple
different tags on a page to talk about different– to say where exactly the ads go. And also need to say what are
the different sizes of the ads. This works, but it’s
obviously not optimal if you need to experiment some
sort of monetization setup, you need to have
developer resources, which you could probably
use to actually help create greater content. Instead, with AMP Auto Ads,
you place a single tag, and AdSense over time will
optimize the right setup, including things like
the placement of the ad and the size of the ad. Think of it as if you were on a
highway, placing one billboard, and having the billboard
sort of automatically move itself to the right
location, and the right size depending on which
viewer’s viewing it. OK, that wasn’t a great
analogy, but it kind of helps convey the point. [LAUGHS] Additionally,
the AdSense team ensured that all of the AMP
ads for the Auto Ads framework was available for any
ad network implement. And the second piece
I want to talk about is the amp-ima-video component. AMP has always supported
playing video ads along with video content, but
there’s a tremendous amount of video content that gets
generated every day online, and AMP pages are no different. So we wanted to make it
super seamless for publishers to monetize all of that content. And there comes in the
amp-ima-video component. All the publisher
has to do is plug in an ad URL from an ad
network and the content URL, and that’s it. Depending on how
the configuration is done within the
ad network, your ads can start to play in
the pre-roll, post-roll, or mid-roll places. And pages get monetized
because the IMA plug-in ships with an
inbuilt video player. Staying consistent with AMP’s
principles of user experience, we ensured that none
of these pre-rolls would actually autoplay. So to learn more about
any of these features, we do publish a public roadmap. So please do sign up for that. So OK, I think we’re on a
good path for monetization of regular ads on
AMP pages, but I think we can do a
step function better with all of AMP’s performance
capabilities and security measures. And to tell you
all about it, I’d like to invite Michael back on. MICHAEL KLEBER:
Great, thank you. [APPLAUSE] OK, so, what if we
could fundamentally rethink how the
ads themselves are built using the AMP framework? What if we could make it
so that the ads themselves load as fast as the rest
of the content on the page, and were as smooth
for user experience? We’re guaranteed to
never hurt what was going on in the rest of the browser. I mentioned a variety
of ad badness problems and what AMP did
to mitigate them, but that was sort
of just a Band-Aid. What we really
want is for ads not to do bad things in
the first place, right? Why is that so hard? I mean, I mentioned
the things that ads do. It’s basically impossible
for us to look at JavaScript and figure out if
it’s going to do something bad for performance. We tried to address
these sorts of issues by requiring ads to
have fixed dimensions and serving them in sandboxed
cross-domain iframes, which helped to ensure that
the user experience is consistent with
AMP’s principles. That offers some
protection to the page that has the ad inside it, but
when the ad is really bad, There’s only so
much that we can do to detect that it’s happening
or to recover from the fact that the ad experience is
harming the rest of the page. It turns out that
AMP offers a path to genuinely solving
these problems. Let’s write the ads
themselves in AMP also. And that’s the idea
behind the AMP ads effort. When an AMP web page– no, no. Yeah, sure. Thanks. AUDIENCE: Woo! [APPLAUSE] MICHAEL KLEBER: That’s
how I feel, too. I’m glad that you do. Thank you for joining me. I appreciate that. When an AMP web page
knows that the ad that is appearing inside
it is also AMP, it doesn’t need to do things
like worrying about sandboxing or worrying about
slow-running scripts or be concerned about
embedded malware. Things written in AMP,
even if they’re ads, cannot have bad performance. That’s kind of the
cornerstone of the AMP is that everything written
an AMP is guaranteed to have good
performance properties, and that extends to ads also. So it’s easy to say, let’s just
write the ads in AMP as well, but it turns out there are a
lot of technically challenging pieces to make this work. For example, ads need to serve
from their own domains, which means that we can’t rely
on a single trusted domain name like cdn.ampproject.org,
which is what the Google Search results page uses as a
way of knowing that an ad is certainly– knowing that
a page that it shows is certainly going
to be valid AMP. Instead, we had to add a new
cryptographic-signature-based way for an AMP page to be sure
that the ads served onto it is valid AMP as well. This is already in place. DoubleClick and AdSense
are experimenting with it right now. Earlier this year, Cloudflare
launched a new ad delivery acceleration service,
Firebolt, that supports the same
validation and signing flow. So that’s how we
serve ads and know that the ads we
serve really are AMP. Rendering on AMP
pages is controlled by a JavaScript
runtime whose job is to harmoniously
handle the needs of all the resources on the page. So we made a way to incorporate
the ad-requesting logic directly into the AMP runtime. On most web pages right now, the
way that ad requests are issued is by loading an external script
or sequence of external scripts that are served
by the ad network. And once you do that, you
have sort of given up control. We’re bundling that behavior
directly into the AMP runtime so if the code issuing
ad requests is, again, guaranteed
to be performant and is checked into
the GitHub repository. Second, once the ad
response comes back, we added a way to stitch
the ad response directly into the rest of the page if
the ad that comes back really is AMP. No cross-domain iframing
or sandboxing is required. And since the ad and the
page are both valid AMP, neither one of them has
malicious JavaScript that is going to mess
up the other one. And the same AMP runtime
that harmoniously loads all the resources together
can appropriately deal with the loading and
rendering of the AMP content along with the rest of
the publisher content without hurting performance. We’ve augmented AMP
with a bunch of features that are necessary for
advertisers that are useful for writing ads in AMP. We’ve done things
like visual effects like CSS-based [INAUDIBLE]
scroll-down animations that you might have
seen demonstrations of in earlier keynotes. We put in advanced user
interactivity features like AMP-bind which Vamsee
mentioned earlier in the talk. We’ve also had less
obvious capabilities like analytics,
viewability monitoring that I mentioned earlier, click
protections, and all the types of invisible ad tech that
you don’t see on your screen, but that are necessary
for an ad ecosystem to successfully function
on the web today. And these
implementations are all written in high-performance
JavaScript, either written or reviewed
by AMP team members. So that means that
they work well. You don’t need to worry
about animation that’s going to drag down the
performance of scrolling on your page, whether it’s
going to keep playing even when the ad is off-screen
and chewing up CPU. And every AMP ad
uses the same code for these sorts of features. So the code will already
be in the browser cache for most users. If it turns out that something
is actually implemented in a way that’s
inefficient, then somebody will report a bug on
the GitHub repository, and somebody will
go in and fix it. We’ll merge the change
into the AMP codebase, and a week or two later,
every AMP ad in the world will become more
efficient all at once. So we’re in the middle of
launching the change that I mentioned to move the ad
requesting from ad tags into the AMP runtime. No more gpt.js for DoubleClick
publishers on AMP pages coming in the near future. That’s a change that we
can do all by ourselves, and you’ll automatically
get the benefit. And it’s speeding
up the median time until an ad is visible
by 850 milliseconds. And at the 90th percentile
for the slowest 10% of ads, it saving around 2.7 seconds. And these numbers are just
for the first ad on the page– the one that’s most likely
to be visible on-screen when the page load, the
one that’s most likely to be above the fold,
and where the latency gains, the time-until-rendering
gains are the most valuable. But as I said, the
real benefit here comes from making the
ads themselves AMP also. Our early tests indicate
that the median time to show an AMP ad is 1.6
seconds faster than the time to show the non-AMP ads. And at the 90th percentile,
that speed-up is five seconds. Now, I have to admit I’m
sort of cheating a little with these numbers here. That’s not quite
a fair comparison because we don’t know
how to render all the ads in the world in AMP yet, right? So the ads that we do
know how to render in AMP were actually
already a little bit faster than the rest of them
before we rewrote them in AMP. But half of these performance
gains that I’m talking about are because of rewriting
the ads in AMP HTML. As one example of this
efficient implementation benefit that I
was talking about, we recently conducted
an experiment to measure the impact of AMP
ads on the phone’s battery life. We took 100 ads that were
built using a standard HTML5 canvas-based animation
library, and we converted them to visually identical
animated ads using keyframes animations
which were written using the now-experimental
AMP animation component, coming to main non-experimental
status in the near future. We let each version of
each ad, load and run for 30 seconds and
then we measured and how much of
the phone’s battery it used during that time. And here is the scatterplot. Every point below the line,
y equals x, in the middle is an ad that used less battery
after converting to AMP. You can see there are a lot
of points below the line and no points above the line. So on average, putting an
animated AMP ad on the page drew 80% less power from the
phone’s battery over those 30 seconds than that same ad would
have if it had been implemented using canvas animations. AUDIENCE: Woo. MICHAEL KLEBER: Yes, woohoo. [APPLAUSE] AUDIENCE: Woo! Woo. MICHAEL KLEBER: So the
benefits of AMP ads are so huge that I
don’t actually just want to put AMP ads on AMP pages. I want AMP to become
the standard way to write ads for the
rest of the web also. That’s why we’re adding
the infrastructure to make it easy to embed ads
written in AMP on regular HTML pages as well. With their efficient– [APPLAUSE] Yes, thank you. AUDIENCE: Woo! MICHAEL KLEBER: Absolutely [APPLAUSE] It’s actually not that
much help that they need. AMP ads will render inside of
cross-domain iframes right now, but not every one
of the features is available if they’re
sitting inside of iframes. They need a little bit of
help from a shim library on the outside to
provide a small amount of extra functionality. Rolling it out now. So with our
efficient JavaScript, and their dramatically
smaller number of bytes, and their ability to
guarantee good behavior, AMP ads offer something
that is really new. It’s a way for a web page owners
to integrate fully functional ads onto their page
while retaining the same sort of predictability
and guaranteed performance in the browser that they would
have with a page that didn’t have any ads on it at all. So now, all we need to
make this vision work is for lots of people
to create ads using AMP. Vamsee. VAMSEE JASTI: Great. Thank you, Michael. [APPLAUSE] MICHAEL KLEBER: Thank you. VAMSEE JASTI: So we’re really
excited to see what the ads ecosystem does with
AMP ads, and I’d like to share one recent
early success story with you. After implementing
their AMP ads, Time Inc. saw some
incredible results with a native ads
provider, TripleLift. So TripleLift, in
this particular case, used Cloudflare’s
Firebolt signing service– as Michael mentioned before– to cryptographically sign
the ads and deliver them. Well, before we look
at the results of how those ads perform from
a metrics standpoint, why don’t we look at it from
a user experience standpoint? So on my next slide, on
your right is a regular ad. On your left is AMP ad. Notice how long it takes for
the ad on the right to load. Ready? MICHAEL KLEBER: Oh, man. VAMSEE JASTI: I’ll let
that GIF loop again. [APPLAUSE] And that’s just incredible. It feels like an eternity
for the regular ad to load. And of course, the chances
are the users probably scroll past the ad, and the
advertiser that’s paying for the impression is
not really getting the value. But worse, the publisher
pages themselves appear pretty broken. There’s black or
white rectangles instead of where the content
or the ad needs to appear. And in the AMP case,
the ad’s just there and ready for the ad to be
interacted with by the user. In terms of metrics,
they’re looking great too. So TripleLift if saw that AMP
ads were three times lighter, six times faster, and
generated 13% greater revenue than non-AMP pages overall. And this shouldn’t come
as a surprise, right? The lighter the ads are, the
faster they appear on-screen. The faster they
appear on-screen, the chances are for the
user to actually interact with them, which generally
tends to increase revenue. So up until this year,
we’re focused on two things. One, let’s make sure
regular ads monetize pretty well on publisher pages. And I think we’re in a
pretty good track on that. The second one is
to ensure that we build some of the infrastructure
that Michael was talking about to serve AMP ads and deliver
them and render them seamlessly on AMP pages and non-AMP pages. But if we want
AMP ads to be sort of the de facto standard
on the mobile web, we need to get
three things right. The first one is the ability
to create beautiful-looking AMP ads. The second one is to
help ad servers actually deliver these AMP
ads with things like cryptographic verification,
signing, and delivery. And the third line
is measurement, because what good is an ad
if publishers and advertisers can’t measure how
well they’re doing? I’d like to share some
early adoption stories and examples of how we’re doing
in each of these three areas. So there’s a
misconception out there that AMP ads don’t look great,
in that the most common AMP ads you see are only
text and image ads. And that’s farther
away from the truth. So we built six great-looking
ad templates in AMP and put them in AMP
by example for you to copy, modify,
share, and distribute. I’d like to take you through
just three of the examples here. The first one, as you
see, is a carousel ad, which basically uses the AMP
Carousel component to allow the advertiser to
showcase beautiful product images using a slideshow
type of interaction. The second one is a
video parallax ad, which uses a bunch of
different components. For example, it uses
scroll-down animations, it uses an AMP video
component, and all of this is combined using AMP-bind. As you see, as you
scroll down, the video starts to move to
the top right corner. You can play it and stream. But also when you hit play,
it starts to play and stream again. And finally, the LightBox format
also similarly uses scroll-down animations, but when
you tap on the link, it actually goes into a LightBox
viewer mode, which allows– the LightBox landing
page itself could be written in AMP, which
helps the landing page to load incredibly fast, because it’s
written in AMP and usually under one second. OK, this is great, but what
if you don’t have developers, and you don’t have developers
to modify these templates and upload them,
and you generally use creative tools
to create your ads? So first, I’d like
to talk about one of the integrations
we work with, which was with Celtra, which is
a creative management platform company who share
our thinking that ads need to be light and fast. Especially, this makes
a ton of difference in developing countries where
ad bandwidth– bandwidth in general is pretty expensive. So Celtra is used by
3,500 different brands, serving, delivering,
and optimizing ads over a million
websites each month. So Celtra now supports AMP ad
creation using their ad builder tool, using sort of
a WYSIWYG interface. I’d like to show
you a quick demo for how easy it is to build
AMP ads using Celtra’s tool. The AdCreator tool is super
easy to use and intuitive, so you don’t have
to be a developer to build these ads anymore. You can easily drag
and drop components, embed timeline-based
animations to the ads, and adjust sequencing of
elements on the screen. You can also use
the Preview tool to view how the ad
would look when it’s exported onto a mobile device. And all of the output from
here is always valid AMP, and therefore, it will
load in an instant. Celtra built a demo to show
you the difference of what it looks like for an ad built
in AMP versus an ad not built in AMP. The regular ad, again,
is on your right. I’ll start counting
how long it takes. 1, 2, 3, 4, 5, 6. OK, that’s pretty incredible. [APPLAUSE] And the ad is just there. It’s ready to be interacted
with when the users arrives at that particular location. OK, so now I have beautiful ads,
but I need ad server support to actually get them
to deliver to a page, so DFP, one of the
world’s largest ad server, later this summer will have
the ability in their custom creatives to input AMP ads. There will be a new
radio button called AMP, and you can basically
input any valid AMP ad. And it also integrates with
AMP validator seamlessly, so if you make any
mistakes, it tells you what’s wrong with the AMP ad. You can fix them and
immediately deliver them. All of these
creators, by the way, will be cryptographically
signed and delivered for free. And later this
summer, DFP also plans to add new creative types,
including image and DFP native. Now, onto the third
area, measurement. Lastly, we work with Moat, which
is an ad analytics company, and widely used by a number
of advertisers and publishers to help with capturing things
like viewability and spam detection– spam
signal detection. So Moat is integrated with AMP
ads using the AMP analytics framework. And the way it works is
Moat basically requests the AMP runtime for
things it cares about. And the AMP analytics,
the way it works is it combines all of the
requests for information and publishes them to anybody
that cares about them. And AMP analytics is designed in
a way that if you end up adding more such vendors
for viewability– as Michael mentioned,
which commonly happens– the performance impact
doesn’t degrade linearly. Instead, because AMP
can coordinate and get the information for all
of those requests one time and distribute them to
any number of endpoints, the performance remains stable
over CPU and battery life. And we’ve also seen a number
of early pioneers implementing AMP ads already. So I’d like to just give
you a quick overview of what the status is right now. So publishers like Mynet– who are also, by the way,
building a great AMP and PWA app– and Vox Media are already
implementing AMP ads and delivering them. So you have two signing
service options. One is from Google, and
another one is Cloudflare. The Google products generally
tend to use the Google one, but any other ad network can use
Cloudflare’s Firebolt signing service to sign the
creatives and deliver them. We talked about Celtra in
terms of using creative tools to develop AMP ads,
but I’m also super excited to announce that
Google Web Designer is going to also support
outputting AMP ads, and so is Adobe Animate. All of these tools have really
big market share to create ads, and we think we’re in a
good path for creating AMP ads easily with
a WYSIWYG interface. In terms of ad server
support, there’s a bunch of options here,
including TripleLift, Adzerk, dianomi, and of course,
DFP for publishers. Our goal is not to stop
just at the display ad. It also matters what happens
after you click on the ad, and which is the landing page. And a common pattern
is starting to appear on the web, which is publishers
and advertisers are working together to have AMP ads
delivered to AMP pages. And when you click
on the AMP ad, the user is sent
to an AMP landing page, which makes sense, right? If The AMP landing page
loads in under one second, instead of, whatever, 19
seconds or 6.9 seconds, depending on which
server you look at, the chances are the
user ends up obviously spending more time on the
landing page for the ones who actually end up there, but
also there’s way less bounce because the user doesn’t go away
because the page doesn’t load. And with AMP, you can
use the same components that you use to build your
pages to also build your ads. So to summarize, as you saw,
this is a pretty complex space. And if we really want AMP
ads to get adopted widely, it’s not going to happen
with the leadership of one. We need a leadership of many. And in this world of
ever-increasing walled gardens, a free and open web is the only
way publishers, advertisers, and ad tech companies can
control their own destinies. So let’s work together to make
the mobile web as fast as it can be, and make it a delightful
experience for our users. It’s 2017, and it’s not
enough just to be fast. We need to be instant both
with our pages and our ads. And finally, for all you
developers in the room, did I mention that we’re
an open source project? I’m obviously
biased, but I think we have an amazing community
with things like Great First Issues to get you
acclimated to the codebase and get you started
really, really easy, fast, and able to commit
code pretty quickly. So please do join us in
making AMP the absolute best as it can be. I’m going to leave some
resources up here on-screen for you to consider, and
please do ask questions if you have any. I think we’re sort of
running out of time, but we want to thank
you for your time and I hope you have a
fantastic day two at I/O. [APPLAUSE] [MUSIC PLAYING]

Leave a Reply

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