Skip to content

Latest commit

 

History

History
44 lines (35 loc) · 3.85 KB

rtb-use-case.md

File metadata and controls

44 lines (35 loc) · 3.85 KB
Raw

Summary

Real Time Bidding or RTB is a standard which establishes an open marketplace for online advertising. A popular version of this standard is OpenRTB. The existence of this marketplace is critical to the advertising industry as it provides publishers a way to obtain fair value for their inventory and advertisers a way to improve the effectiveness of their advertising either by cost or effectiveness optimization.

This use case is heavily dependant upon anonymous user-level tracking but it need not be. At the end of the day, these exchanges do not exist to track users; they exist to enable a value exchange between publishers and advertisers. The user-level tracking which exists today is merely a means to an end. If browsers are willing to act as a trust agent in this context, it is conceivable that an open advertising market could be created which is not dependant upon user-level cross-site tracking.

Why is it important to preserve this use case?

RTB provides an open marketplace for publishers to more effectively monetize their content and for advertisers to optimize their ad budgets. Open marketplaces ensure that participants (in this case publishers and advertisers) provide fair value for what they're purchasing or recieve fair value for what they offer. While in it's current form, RTB is dependant upon user-level tracking, the core value prop of an open advertising marketplace does not necessarily need to be dependant upon user-level tracking.

How is it functionally achieved today?

  1. The use cases of online advertising explainer describes many of the participants in this marketplace but does not discuss the RTB marketplaces which enable those exchanges
  2. High-level flow
    1. User visits publisher property foo.com
    2. Publisher makes a bid request to an ad exchange. Bid request includes details about the ad placement as well as details about the user.
    3. Ad exchange forwards the request to multiple DSPs
    4. DSPs, using information from the publisher and of the user will place a bid to show their ad. The bid can come from any advertiser active on the DSP at the time of the bid.
    5. After some time, the ad exchange will take the bids it has received and select a winner based on exchange and publisher bidding rules
    6. The winning ad is sent to the user's browser and loads from the user's browser
    7. The ad server which served the ad records this using data from the browser
    8. In the ad itself, there are often additional third party trackers which effectively serve to convince the advertiser that they received what they paid for when an ad was purchased.

What are the requirements of this use case?

  1. Publishers
    1. Need a way to list inventory on an exchange
    2. Need a way to prove the value of their inventory without user-level tracking
    3. Need a way to segment premium inventory from non-premium inventory
  2. Advertisers
    1. Need to be convinced that they received ad placements they paid for on the exchange
    2. Need proof of the value of the ad placement they paid for
      1. Needs to minimize and eliminate fraud where possible
      2. Needs to know at what rate an ad they paid for was seen
      3. In the case of streaming content ads (video, audio), the advertiser needs to know if the ads were fully or partially consumed
    3. Needs optimization levers to improve bidding intelligence.
  3. Exchanges
    1. Needs a way to list publisher inventory
    2. Needs a way to enable marketplace rules
  4. Marketplace
    1. Needs to know that transactions are accurate
    2. Needs to know that fraud is low or non-existent (along with a way to eject fraudulent actors)
    3. Needs to know value delivered from ads served