Join us for the RTBkit 2.0 Roadmap preview and Q&A.
In this presentation you will:
- learn about the new features of the RTBkit 2.0
- understand best practices for development and backward - compatibility
- find out how you can contribute to RTBkit 2.0
If you are an RTBkit developer or are interested in learning more about the next major revision to the RTBkit framework, this presentation a must to get the inside scoop on what is coming out in RTBkit 2.0.
38. RTBkit & Rubicon Project Deliver Scalable Ad
Tech Infrastructure & Extensible Bidding Stack
• Rubicon Project is a leading technology company automating the buying and selling of
advertising.
• Rubicon Project & RTBkit have combined forces to deliver a scalable ad tech infrastructure, and
makes it easy for media buyers to deploy their own proprietary bidding stack with the open and
extensible architecture of RTBkit.
• The OpenDSP team is a contributor to the RTBkit open source project and active member of the
RTBkit community.
Join the Alpha Program
There are limited seats available in the alpha program. Contact the OpenDSP team at
opendsp@rubiconproject.com to get started.
Hello everyone and welcome to this Introduction to RTBkit. Here is a brief overview of what we're going to cover. [COVER THE BULLET POINTS]
But before we begin, because this is a talk on a toolkit for building RTB systems I'm assuming most of you have some background in the domain and understand the basics of real-time bidding, or RTB. [JOKE] In case you wandered into the wrong room, let's take a very brief whirlwind tour of RTB.
- There are publishers
- They have ad slots they need to fill with ads
- They broadcast descriptions of those ad units in a JSON form called a bid request to ad exchanges
- The ad exchanges then forward the bid requests to interested bidders
- Bidders respond within a specified time period with a bid response a specified format. The response includes a bid price and a URL for an ad server to serve an ad
- The exchange awards the ad slot to the highest bidder, and calls that winning bidder's ad server to cause the ad to be served
This is of course greatly simplified, but at least it provides a framework for what is happening for anyone in the audience new to this domain. RTBkit is an open-source software framework that provides a working core of one of these bidder systems.
RTBkit was created by Datacratic, whom I work for, a company based in Montreal that provides machine-learning based products and services, with a focus right now on RTB and lookalike modeling for digital marketing. Datacratic sells optimization for real-time bidding, and starting about three years ago, began building a bidder to serve its customers. The company made the decision to open source RTBkit early last year and the project has been a public open source project since February 2013.
Finally, we get to the core problem, value. After all, you are bidding, this is an auction, so the fundamental question you need to answer after you have decided that yes, indeed, you want to try and win the auction for the right to show this ad to this person, is how much is it worth to you to show this ad to this person.
Again, this computation is the output of the calculation by your Bidding Agent.
Notice in this diagram that System is orthogonal to Selection and Value. Again, this is an excellent frame for understanding the philosophy of RTBkit. Commoditize the system problem and provide you tools to address Selection and Value.
Notice also that Selection and Value overlap. That's because the value of a particular ad is not independent of the context. Each bidder cares about all the campaigns they have running, the goals of those campaigns, how much budget they have left, how much time they have left to run. Each bidder has different data about the user being shown the ad. And each bidder might also have different business logic interacting with all the metadata of the ad, such as where the ad is running, the size of the ad slot etc. All of this plays into answering both the "What Ad?" and both Value questions. Each ad is worth something different to each bidder, which is why RTBkit provides Selection tools and a Bidding Agent framework but allows system builders to customize their Agent logic. As we will see later, this is also why Augmenters are a key part of the RTBkit design.
Now let's start drilling into the design and architecture of RTBkit to show how it implements a solution to these problems.
We're going to start at a high level and take a tour of each service and component in the system. You'll understand the responsibilities of each piece of the system, the data flows through the system and learn the rationale for some technology choices made.
[COVER BULLETS ON CORE]
[COVER BULLETS ON PLUGINS]
[DISCUSS RATIONALE FOR CORE VS. PLUGINS]
Now let's start drilling into the design and architecture of RTBkit to show how it implements a solution to these problems.
We're going to start at a high level and take a tour of each service and component in the system. You'll understand the responsibilities of each piece of the system, the data flows through the system and learn the rationale for some technology choices made.
[COVER BULLETS ON CORE]
[COVER BULLETS ON PLUGINS]
[DISCUSS RATIONALE FOR CORE VS. PLUGINS]
[COVER BULLETS]
- Mention Rubicon Project has been in the project since the start
- Mention that Open RTB has been in the project since the start
- Mention BidSwitch is a great choice because you get 30+ possible integrations with one business contact, filtering traffic, etc.
Now let's envision this data flow as a linear sequence of events for the life cycle of a bid request, for the sake of clarity. We are also leaving out the banking bookkeeping in this view, because we will return to that in greater detail later in the talk.
This view shows us RTBkit from the perspective of processing bid requests. We see two asynchronous "logical" data flows. In red, we see the pipeline processing of the bid request.
The Exchange Connector parses the bid request, converts it into an internal bid request format, and passes the bid request to the router.
Next, the router coordinates passing and receiving back the bid request through a series of filters. Static filters, Augmenter filters and dynamic filters are all matched against the bid request by the filtering subsystem. Any matches may result in the reducing the number of campaigns eligible to bid on the bid request, or actually eliminate all eligible campaigns, resulting in dropping the request. We will do a deeper dive on the filtering system a bit later in the talk.
The Augmenter can apply filters, but it can also transform the bid request by adding fields to it. We'll discuss Augmenters in more detail later. They are the key to RTBkit users creating custom business logic for things like custom filtering based on bid attributes, use of custom segments, and use of your user data.
Finally, if the bid request passes all filtering and there are still eligible campaigns, Bidding Agents representing each of these campaigns receive the bid request. Each sends a bid response back to the router. The router selects the highest bidder and returns this bid response to the Exchange Connector. The Connector builds a bid response in the correct format and response to the Exchange.
At some point later, as we see in the blue data flow, Win messages come back from either the exchange -- if you are receiving server-to-server, verified win messages from the exchange -- or from the ad server, if you are implementing wins as a tag callback in your ad unit. Likewise, Click messages come from the ad server and your conversion messages might come from multiple different sources such as tag calls or bulk updates, depending on how you are gathering conversions.
All of these are considered "ad server events" in RTBkit parlance. All are implemented as HTTP JSON POST calls to the AdServer Connector component, which collects these messages, logs them and pass them to the Post Auction Service for matching.
The PAS matches wins to bid requests, and clicks and conversions to wins. It also notifies Bidding Agents of matched events, so they can potentially modify their bidding logic in response to the information that a certain bid won or resulted in a click or conversion and another did not. So this data flow supports multiple purposes:
- logging events for later reporting
- matching wins so campaign budgets in the banker can be adjusted properly
- updating Bidding Agents with signal information about how successfully they are bidding
Here we see that three other data flows are happening asynchronously.
The flow of Win events from the Ad Server Connector, which isn't shown, into the Post Auction Service, allow the PAS to match wins to previous bids. This service also updates the Agents, so they know which campaigns have recorded Wins, Clicks and Conversions. Agents can use this data to influence their bidding decisions.
In turn, this lets the Slave Banker update the Master to debit outstanding bids when matching wins are received in the Post Auction Service, or to redeem budget when Losses are inferred.
Finally, a separate Agent Configuration Service periodically updates the filtering configurations available to the three layers of Filtering in RTBkit, Static, Augmenter and Dynamic Filters. We'll take a deeper dive on filtering in just a bit.