9 responses

  1. Jeffrey Goldstein
    March 26, 2013

    This sounds very familiar. I think I pitched this all to you guys a year ago?

    • Shael Fryer
      March 26, 2013

      @Jeff - Either that or great minds just think alike!”

  2. Fabien Magalon
    March 26, 2013

    I really like the idea.
    One concern only: how many bids requests per impression is acceptable ? I guess there needs to have a stop at some point.
    Benefit of using Deal ID today is to add unlimited additional dimensions and matching price-floors to every single impression. Not sure we could mirror this with multiple bid requests. I still like the idea a lot though.

    • Andrew Casale
      March 26, 2013

      There would definitely need to be an upper limit or if left unchecked this could create more problems than it would solve.

      My thought isn't for this to replace dealID. The later is incredibly valuable because of its simplistic design - that it can be applied to anything. Rather, the goal here would be to reduce the most common usages of dealID today which create the biggest burden so that we reserve dealID for only more complex executions.

  3. Doug Render
    March 26, 2013

    Interesting concept, Andrew. Do you not think the DSPs would quickly learn to group the three requests (transparent, semi transparent, opaque) as a single opportunity, using the transparent data to inform their decision but responding only to the opaque opportunity, as it could be had at the lowest price point?


    • Andrew Casale
      March 26, 2013

      That's definitely a valid concern. But if this is a direction we want to take to reduce friction which all parties would benefit from, it's one I think all parties have a vested interest in resolving. The exchange can safe guard through obfuscation, or contractually the DSP can be obligated not to do this. Technically the same concern can be thought of with the usage of dealID, if a DSP knows the rules that govern a dealID they could make use of its designated purpose in unauthorized scenarios.

  4. Matthew Meyer
    March 26, 2013

    I imagine this concept has two customers with two different requirements:
    On the buy-side, DSP's will offer their clients the ability to purchase inventory at different price points across different targeting criteria.
    On the sell-side, SSP's will need different pricing rules for their publishers inventory to match the bids and the levels of transparency.

  5. Jeremy Randol
    March 27, 2013

    Yup, this was the tiered auction concept we've been thinking about for a while. As you know, we love the idea. Doug raises a point that some DSP and SSP partners have shared. Would love to better understand a path forward.

  6. Neal Richter, Chief Scientist
    March 27, 2013

    Multiple bid requests has some distinct disadvantages. It triggers the danger of swelling supply in the various counting systems, as well as increased operational QPS loads. In my opinion it's the wrong solution.

    I do agree with Andrew that we need to look at a protocol upgrade. Currently there is a draft within the OpenRTB dev group for a protocol extension for PMP. The draft describes a pmp child object that will contain an array of DealIDs, a type field, a pacing %, a price floor and possibly a list of data tokens for targeting. The proposal is still under consideration. This in combination with multi-bidding in responses will allow bidders to send back full bid responses for any of the DealIDs as well as open market bids.

    Rubicon has already extended our pre OpenRTB API with this object. We're also going out to PMP capable DSPs with best practices on how this might be used. The most important point in this is an ideal bidding logic outline describing handling of DealID, SeatIDs and how the private flag should be interpreted in concert with multi-bidding.

    If we can get behind the outlines of this solution the RTB protocol will have evolved to support both second/reserve price auction as well as rich direct order automation between a buyer and a seller.

Leave a Reply




Back to top
mobile desktop