Tip:
Highlight text to annotate it
X
NOAM WOLF: So welcome everyone.
Thank you so much for joining my session.
My name--
I see a couple people still walking in, so we'll wait like
a few more seconds.
Guy on the phone.
All right.
So my name's Noam Wolf, I'm a tech lead manager on Google's
Ad Exchange.
I've been at Google for about seven years now exclusively
working on ads.
And I'm really excited to tell you about something my team
and I've been working on for the past year.
But first, I'd like to take you through a quick overview
and the history of display advertising.
Before I do that, I want to get an idea of
who my audience is.
So who here knows what display advertising is?
Just a show of hand.
Oh wow.
Maybe I can skip all of my slides.
All right, I wasn't expecting that.
So I'll do this pretty quickly.
Display advertising is generally considered anything
that is of image format for online advertising.
Now image form could mean rich media, images, video.
We categorize mobile in there, as well.
But we exclude search ads, AKA text ads.
Even though Wikipedia doesn't make that distinction.
But not everything on Wikipedia is true.
So leading up to 2008, display advertising was
a very manual process.
If anybody here had to do display advertising before
2008, you know what I'm talking about.
Advertisers, these are the people that want to sell
something or have their brand out there, would reach out to
these websites, what we call publishers, and say, hey, I'd
like to advertise on your space, on your inventory.
And the publisher would say, cool.
That will cost you x dollars for every 1,000 impressions.
An impression is--
as by show of your hands before, everybody knows--
is when I load a website, I see an ad, we count that as
one impression.
So the prices were fixed.
And the what and the when of my ads, like when were they
going to show, who were they going to show to, were all
predetermined.
So it's all done offline.
2008 was--
well, maybe I'm only that calls this--
the year of the exchanges.
Right Media had an exchange.
DoubleClick had an exchange.
And AdECN had an exchange, and maybe there
were some small ones.
And these were platforms that enabled bidded buying of
online advertising.
Now the bidded part is the interesting part, because this
is where we went from fixed pricing to dynamic pricing.
We ran second price auctions.
This is a little different than Google AdWords
generalized second price auction, because you really
only have one winner because you're going
for one ad at a time.
And advertisers would still have to
preload their campaigns.
They would have to basically tell us what they want to
show, who they want to show it to.
So all their targeting was done through a web UI, still
the same thing.
They'd actually have to upload their ad, what we call
creative, into our system.
And at serving time, we would decide which ad won based on
the bid that they associated with that ad.
So a bid from the advertiser's side would say, here is the
max amount of money that I'd like to pay for showing this
ad on your website.
And the publisher, the website would say, here is the minimum
amount of money I'm willing to receive.
So the exchange orchestrated all that, basically making it
a platform.
Ad networks, which I'm guessing some of you
represent, would aggregate advertisers.
So they would represent multiple advertisers and bid
on their behalf.
Ad exchanges really introduced more transparency, because of
the fixed pricing, in their reporting.
Something that ad networks, at that time, didn't really do.
So fast-forward to 2010, RTB.
RTB was invented, Real-Time Bidding.
Real-time bidding was a way to do
per-impression decision making.
Now I want you to really think about that for a second.
For every impression, you're going to make a decision.
You're going to make a decision of how much you want
to pay, if you want to pay, maybe you don't want this
impression, and you're going to pass the creative, the ad
that you want to show to the customer, to the
user, in real time.
So it's not really a protocol, right?
But every exchange has a very similar set of details, of
attributes, of metadata, that they pass on the server side
to your bidders.
These bidders, these are the pieces of software that are
very, very nontrivial pieces of code, need to be scalable,
need to be available, because of two very, very strict
constraints in RTB.
These constraints are one, exchanges typically require
100 milliseconds for you to respond to this bid request.
So the page will load, the tag, we'll call the ad
exchange, ad exchange will make a server side call to the
partners, to whoever is eligible to receive that call,
these are the bidders.
And the bidders are required to respond within 100
milliseconds.
Now that's very difficult.
So that's one constraint.
Constraint number two, is scale.
Right?
Exchanges tend to be a bit chatty.
And they also throttle without mercy.
So if you don't respond to at least 85% of these requests,
then you're going to be throttled.
And you're going to miss on the impressions that you
really want to get.
So scale is a big deal here.
And it's very big scale.
This is the key node in every other session says Google
scale, well RTB is probably the biggest
QPS in all of Google.
So we're talking about hundreds of thousands of
queries per second.
And you have to make a decision per second for each
one of these impressions.
Did anybody just blink?
Martin did.
Well, that took him 300 milliseconds.
300 milliseconds to blink.
200 milliseconds to recognize facial expressions.
So just to give you an idea of what 100 milliseconds is,
there's some cool facts about Ferraris and stuff up on the
slide, but I'm not going to go into too much detail.
But this gives you an idea of how much you have
to do in that time.
So why do I want to do RTB?
Well, display is a $40 billion market.
If it wasn't a $40 billion market, in the context of
Google I/O, you probably wouldn't be in this room.
And display is growing immensely.
59% of that business is going to be attributed to RTB, which
is growing faster than your static buying, which is
non-RTB, it's non-real-time, if you will.
And RTB, in 2012 alone, accounted
for almost $2 billion.
So we know what display advertising is.
I think we reached that conclusion
very, very early on.
We know what exchanges are.
We know what bidders are now and how
difficult they are to build.
And I think I met a couple of you who said that they want to
build bidders, but they're not sure where to start.
And we know why we want to build them.
It's a very lucrative market.
So what are my options?
How can I participate in RTB?
Well, today you have two options.
Option one, you build it yourself.
Hire an engineering team.
You build out a data center.
You figure out optimization algorithms.
And to scale, you throw money at the problem.
And this gives you a lot of flexibility.
You could do whatever you want.
You could really take advantage of every single
attribute in that protocol I just talked about.
You could do whatever you want with it
because it's your bidder.
But you have to scale very, very quickly.
And scaling in regular data centers is really, really hard
and costly.
So two resources.
Engineering and machines.
That's not something that everybody can just afford.
Option number two, you hire somebody to do it for you.
You go to DSP, a demand site platform,
that has a data center.
They have an engineering team.
They have optimization modules for you to use.
And you still pay them to do it.
You probably pay less than building out a data center.
And they help you scale.
But the downside is you don't get that flexibility.
You kind of get a black box solution.
Oh, you optimize for me?
Great.
Can I change?
No.
But what about-- no.
Right?
So I'm really, really excited to tell you about a third
option today.
And this is the Open Bidder.
Open Bidder is a fully customizable toolkit that
enables bidded buying on the exchange.
It lets you manage your real-time virtual machines.
And if any of you attended Navneet and Martin's talk
yesterday, you got a little bit of a demo of how fast
virtual machines start up in GCE.
So GCE, Google Compute Engine, which have a pretty dominant
set of talks at I/O, and I urge you to see the ones that
are still left to see.
They really talk about how GCE is really good.
The reason that we even
integrate with GCE is because--
and I pull this out of their deck on the next slide--
is that during peak hours, GCE will
provide 20% lower latency.
Now I can probably repeat all the stuff that Navneet said,
but one thing that really, really caught my attention was
the per-minute pricing, as opposed to competitors where
you have to pay per hour.
Now think about 100,000 impressions requests per
second, right?
If you're only responding 10 minutes out of the whole hour,
you still get a lot in, and you don't have to pay for the
whole hour.
So GCE really provides a huge value in this context.
The latency for bidders is a huge deal, as
we mentioned before.
And we really want to lower the bar of entry.
So we want to give you back as much of that 100 milliseconds
as we possibly can.
So instead of spending 40 to, worst case, 80 milliseconds
just in network traffic, we want to minimize that.
Ideally, sub five milliseconds, but I can't
quote numbers just now.
We want you to focus on cool innovation.
We want you to innovate in RTB.
Something that I didn't prepare for in these slides
and I'm really happy to share with you is somebody walked up
to us at the booth today, and he said, why doesn't Google
sue all the ad blockers?
I was like, all right, let's see what this guy wants.
I said, well, ad blockers, it's a business.
People don't want to see ads.
Our responsibility as advertisers is to show the
right ad to the right user at the right time.
However, we're kind of restricted with
the players out there.
We either use a solution that exists, or we build something
from scratch, and we spend a lot of time
and money doing it.
So I really believe that this toolkit, one of you guys, my
fellow colleague developers, could go out and build
something that will be better or fairer than ad blockers.
Because this guy's thing was, well it's not fair.
It's theft.
You're stealing the money from the publisher because they're
not showing ads, so they're not getting paid.
And I said, that's a good point.
So you're a publisher?
He's like, no, I write ad blockers.
[LAUGHTER]
NOAM WOLF: That was really not prepared.
That really happened today.
Anyway, I'd like to walk you through the life of a bid
request real quick, in the context of Open Bidder.
The red outline is Google Compute Engine, where our
virtual machines run Open Bidder's servers.
We'll use the DoubleClick Ad Exchange by Google as an
example of an exchange, sending an exchange-specific
bid request into Open Bidder.
Open Bidder receives this request and translates it into
a normalized protobuffer internal to Open Bidder.
This is pretty nice.
It lets you be flexible to support other exchanges.
We don't want to be only tied to DoubleClick exchange.
This will be an open source tool kit.
And you get to run through the stack of what we call
interceptors, and I'll talk in detail about those
interceptors in a few seconds, where you
run your custom logic.
So remember before, I said, we want you to focus on your
custom logic.
This is the piece that you write.
This is your secret sauce.
So you run through the stack with the Open
Bidder specific proto.
And then you run back up the pipe with a response.
We have a lifecycle.
You could do pre-processing, you can do post-processing,
and I'll talk about that in a second.
And the bid is then sent back to the exchange, all within
100 milliseconds.
So let's go out, let's take a step back
and look at the ecosystem.
So the ecosystem's been plugged for GCE in every
single session.
And we're actually using all these things.
And I thought it would be cool to put everything together to
kind of a real business on GCE.
So cloud storage, you get your persistent disc, you get it
stickied to your sessions, to your virtual machines.
We use that in the core of Open Bidder to store
metadata, et cetera.
I think the sample app that Joe wrote, if you were at the
GCE tech session, they actually passed
the go code as metadata.
Which I thought was pretty cool and smart.
Google BigQuery will let you analyze the data in your logs,
basically whatever you want.
But in this case, what you're interested
in is in logs, right?
What did I bid?
How much did bid?
How much did I end up paying when I won?
It's a second price auction.
So what you bid isn't necessarily what
you're going to pay.
And we have a Prediction API, which I personally think is
really, really cool, especially from a computer
science point of view.
You get to train your models.
You can do this with train requests, and you could do
that asynchronously.
It shouldn't affect your 100 milliseconds.
But you can also request a prediction in real time.
There's one more thing that I left out, which is you.
I think this could be a very nice community for you guys to
add value to this space.
If you think you can do better than Prediction API that
Google provides, then you should go out and do it.
And you should use our APIs to plug-in and
charge for a service.
You're going to be hosted on the same network inside
Google, and everybody's going to benefit from this.
We talked about locating your virtual machines within
Google, this lowers your latency.
And we talked about scale.
You can start instances up very, very
quickly as the demo showed.
And you have all these value-add services.
So one thing I didn't mention is App Engine.
Currently, we use App Engine to
configure our virtual machines.
We have a configuration UI.
You can start and stop your virtual machines, you can see
your resources, what your state is.
We have plans to move that to a more hosted environment.
But we can keep that around, and we want to hear from you
if this is something that's useful to you.
BigQuery, I want to plug it again because there's a talk
right after this that has a demo for BigQuery about
crunching terabytes of data.
And you get really cool visualizations, so if you want
to stick around after this for the next session, they'll talk
about BigQuery.
So we know that all of you kind of raised your hands when
I asked if you know what display advertising was.
Who here is a developer?
All right, sweet.
Who wants to see some code?
All right.
But before that, just a few features of Open Bidder that
are really important as part of the stack.
Obviously, we support bidding because we're a bidder.
And we support click and impression callbacks.
Right?
So you want the impression.
Well, how do you know that you want it?
So a lot of these exchanges have macros that allow you to
set up callbacks and fill those macros in with a winning
bid price, for example.
So then you can use that to log and do your own
optimizations.
Cookie matching, I'm sure everybody knows what that is
for remarketing.
We also support that out of the box.
So here's some code.
I promised our interceptor model, which is heavily based
on the Java Filter API, so if you know or have used the Java
Filter API, none of this should be earth-shattering.
But at the core of Open Bidder, we have two
interfaces.
We have an interceptor chain, which is
responsible for the lifecycle.
You have access to the bid request and the bid response
and you can chain these interceptors.
And then you have interceptor API, not surprising, and it
has an execute method.
So each one of these interceptors when implemented,
you can get executed by the workflow.
And you can, like I said before, do pre-processing and
post-processing steps.
So here's a sample interceptor.
It's my secret sauce interceptor.
And, not surprising, it extends a bid interceptor, and
through the execute method you get access to the chain.
And notice just at the very bottom, I call chain.proceed,
so anything before that is going down the stack.
So I go interceptor by interceptor by interceptor
going down.
Any work that I do after chain.proceed is on
the way back up.
And this is really cool for logging, if you want to have
access to decisions that other interceptors made.
So this interceptor basically grabs the requests, asks for
the pre-targeted ad units-- these are ad units from
DoubleClick's ad exchange that you've set for pre-targeting
through AdWords UI, or the Ad Exchange UI, and you build
these new snippets.
What price you should charge for them?
Well, that's your secret sauce.
Highlighted in bold.
Favorite quote of mine, or one of the favorite quotes that I
have, from one of our beta testers, and we've actually
been beta testing for a while now, is that they really love
the flexibility of what we've provided, and they've seen
some results that they really want to move their spend over
to Open Bidder.
I saw some smiles here.
I don't know if you're the client, but I won't out you.
So I'd like to wrap up with a little bit
of a product vision.
Where are we going?
Where do we see ourselves in a year from now?
And our product vision really circles around three main
categories.
The first category is additional components.
We have a dedicated team.
They're actually sitting up front here, and I'll introduce
them in a second.
And we are fully dedicated to this open source toolkit.
So we keep adding more value, we keep listening to feedback,
and we keep enhancing our offering.
We gather feedback, either through a forum, we're
probably going to be on Stack Exchange when we open this up,
and we look to hear for feedback, as much feedback as
you can possibly give us.
The beta testers will attest to the fact that we're very
responsive.
More GCE.
So you heard about a new load balancing service from GCE.
We're kind of at the forefront of the new GCE stuff.
GCE stuff comes out, we test it for them at our scale.
And so you're immediately going to get that.
And I think that's a really, really cool feature.
And then the last, but absolutely not least.
My personal favorite part of Open Bidder is the community.
So we will open source this after we're out of beta.
We want to see the community give back and grow because I
really believe that Open Bidder is the platform for RTB
innovation.
And we can get rid of stuff like ad blockers with a much
smarter solution, which I'm sure many of you are thinking
about right now or already know the solution for.
And there's no reason why you can't you monetize that and
save the web at the same time.
So I want to leave you with one very last quote from our
friends at TwelveFold that saw this when we pitched it to
them, it was like 14 months ago, and they said, you know,
there's a huge gap in the bidder
landscape for custom logic.
Open Bidder, which was actually a different name back
then, is a brilliant idea.
Where do I sign up?
Well, today you can sign up for our beta process.
Our documentation, as you can see at the bottom, is open
source now.
So you can go there right now.
See what we have in store for you, what we can do, our
capabilities.
And when you sign up, we can white-list you for our code.
I also have the QR code in the corner, that's
actually not the code.
It's actually rating the session.
So you can either scan this, I'd be very happy to hear any
feedback about this specific session.
What you want to see more of, et cetera.
And there's also a QR code in the back.
And I think that's about it.
I'd like to spend the next maybe 10 minutes to answer
some questions, if you have.
And I'd like to call up the team.
So we have William Shields, our tech lead, [? Jiannan ?]
[? *** ?], our UI guru, and [? Risvaldo ?]
[INAUDIBLE].
I can't pronounce his last name.
The back end lead.
So come on up, and let's see if we
can answer some questions.
Or should I ask if you have any questions first?
[APPLAUSE]
NOAM WOLF: Thank you.
Perfect, thank you.
Sure.
I think this is being recorded.
AUDIENCE 1: Hi.
So it is the bidder agnostic to what kind of inventory it's
going to bid for?
So if it's mobile apps, or mobile web, or display web,
does it make a distinction?
Or is it completely agnostic to that?
NOAM WOLF: So the bidder is a platform.
We're worried about infrastructure.
The logic of what to bid for and what you're
eligible for is on you.
You have access to the proto, to the request.
So you can basically see if it's mobile, if it's video and
whatnot, depending on those attributes.
AUDIENCE 2: Hey guys, what cookie space do you support?
Would we have our own pixels that we would map to?
Or could we leverage DoubleClick?
WILLIAM SHIELDS: Well, we support out of the box, the
DoubleClick cookie matching.
So that probably has the most value from what you're looking
at, which is to match DoubleClick cookie space.
AUDIENCE 2: And do you support OpenRTB?
WILLIAM SHIELDS: I can neither confirm nor deny our
particular status with open RTB.
We've thought a lot about the problem of
cross-exchange buying.
This is still actually a work in progress, so we've got
nothing concrete to announce on this particular regard, but
it's certainly something we've been thinking about.
NOAM WOLF: Any other questions?
All right, well thank you very much for coming out, and we
look to see you innovating RTB.
[APPLAUSE]