OpenRTB 2.5 Proposal: PMP/Deal ID "Programmatic Guaranteed"

875 views
Skip to first unread message

jgwi...@vindicotech.com

unread,
Nov 16, 2016, 8:31:57 PM11/16/16
to openrtb-dev

OpenRTB 2.5 Proposal: PMP/Deal ID "Programmatic Guaranteed"

Author(s):

Jonathan Gwiazda

jgwi...@viantinc.com


Problem Statement:

Currently there is no way for a DSP to know that a Deal ID is Programmatic Guaranteed (PG), meaning that the inventory is pre-bought and the "bid request" should be responded to with an ad and pre-agreed bid amount everytime... no "no bidding" allowed.  Without this signal in the bid request, DSP systems will apply all the normal bidder features to cherry-pick impressions, which results in low delivery rates when Business has brokered a guaranteed buy.

Proposed Solution:

Since a PG buy is a brokered buy, PMP/Deal ID would be the most appropriate OpenRTB Object to enrich with this new PG signal.  The simplest way of doing this would be to expand the private_auction ids (0=all bids accepted, 1=restricted to deals only) to include "2=Programmatic Guaranteed" (where there is one buyer who pre-purchased the impression at a fixed price).

An example of a PG PMP.Deal bid request... based upon these deal points: (1M impressions @ $5CPM)

  • "PMP":
    • "Private_auction": 2
    • "Deals"
      • "id":"programmatic_guaranteed_deal"
      • "at": 3
      • "bidfloor":5.00
      • "wseat":"agency1"
    • "Ext"
Discussion:
How would impression budgets be handled?  For example, would the seller, buyer, or exchange be responsible for turning off this Deal ID once (from the example above) 1M impressions have been fulfilled?

Sam Tingleff

unread,
Nov 17, 2016, 1:22:04 AM11/17/16
to openr...@googlegroups.com
Great discussion topic Jonathan.

The function of private_auction is to restrict demand. But it seems to me that what we want to do is to encourage bidding on a guaranteed deal but to fall back on alternative demand if necessary. Because there are any number of reasons for which a DSP might not bid even on a 100% fill style deal:
- network timeouts on the end bidder for Bidswitch-style aggregators
- already hit a buy-side emergency cap but the seller continues to send requests

Let's take advantage of RTB and allow for fallback demand in failure scenarios. And these 100% fill deals with only sell-side targeting ("site buys") hardly seem like the most interesting thing we can accomplish on a guaranteed agreement with impression-level buy side optionality.

A "guaranteed" deal probably means a couple of things
1) pricing terms: first price, second price, fixed price
2) expectations of what is guaranteed to whom and who has responsibility for pacing, capping, and targeting
3) contracts about what happens if either side does not meet a commitment

1. seems to be handled with the existing imp.deals.at

2. There are any number of interesting variations in which targeting, capping, and pacing are handled either by the publisher, the exchange, or the DSP (possibly separately). We've been thinking about a new child of the deal object to describe the flavor of commitment which would reflect expectations of the DSP.

3. Probably best handled outside of real time protocol.

I'll suggest a new field "dealclass", representing commitment expectations and with something like the following possible values
- "standard": no spend or fill expectations (default, represents the majority of deals today)
- "commit": buyer has agreed to some level of spend and fill over some time period
- "sponsorship": seller is expecting 100% bid rate

Here's an example. The seller is expecting 100% bid rate on QXA8dTWBtQL8 and is thus taking responsibility for targeting and caps. Any bids for this deal should be expected to win over competing demand regardless of price.

However if for any reason the DSP does not want to bid on QXA8dTWBtQL8, the standard deal EbX8aDYcE5PV is also eligible. Open market demand is welcome as well (private_auction = 0).

{
 ...
 "imp": {
   "pmp": {
     "private_auction": 0,
     "deals": [
            "deals": [{
                "id": "QXA8dTWBtQL8",
                "at": 3,
                "bidfloor": 15.0,
                "bidfloorcur": "USD",
                "wseat": ["932"],
                "dealclass": "sponsorship"
            },
            {
                "id": "EbX8aDYcE5PV",
                "at": 2,
                "bidfloor": 5.5,
                "bidfloorcur": "USD",
                "dealclass": "commit"
            }]
     ]
   }
 }
}

--
You received this message because you are subscribed to the Google Groups "openrtb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Antoine Bonavita

unread,
Nov 17, 2016, 3:37:54 AM11/17/16
to openr...@googlegroups.com
Hello,

This is definitely a big topic that everybody is talking about.

However, I feel there is a contradiction in your proposal between
running an auction (therefore sending bid requests) and forbidding the
bidder not to bid. Isn't there ?

I don't think it is realistic to say that bidder will always bid. And if
enforcing is not realistic, I think the price thing is already handled
by the auction type 3 (fixed price) that is available at the deal level.

My 2 cents.

A.

On 11/17/2016 02:31 AM, jgwi...@vindicotech.com wrote:
> OpenRTB 2.5 Proposal: PMP/Deal ID "Programmatic Guaranteed"
>
> Author(s):
>
> Jonathan Gwiazda
>
> jgwi...@viantinc.com <mailto:jgwi...@viantinc.com>
>
>
> Problem Statement:
>
> Currently there is no way for a DSP to know that a Deal ID is
> /Programmatic Guaranteed (PG)/, meaning that the inventory is
> /pre-bought/ and the "bid request" should be responded to with an ad and
> pre-agreed bid amount /everytime/... no "no bidding" allowed. Without
> this signal in the bid request, DSP systems will apply all the normal
> bidder features to /cherry-pick/ impressions, which results in low
> delivery rates when Business has brokered a /guaranteed buy/.
>
> *Proposed Solution:*
>
> Since a PG buy is a /brokered /buy, PMP/Deal ID would be the most
> appropriate OpenRTB Object to enrich with this new PG signal. The
> simplest way of doing this would be to expand the private_auction ids
> (0=all bids accepted, 1=restricted to deals only) to include
> "2=Programmatic Guaranteed" (where there is */one /*buyer who
> pre-purchased the impression at a fixed price).
>
> An example of a *PG *PMP.Deal bid request... based upon these deal
> points: (1M impressions @ $5CPM)
>
> * "PMP":
> o "Private_auction": 2
> o "Deals"
> + "id":"programmatic_guaranteed_deal"
> + "at": 3
> + "bidfloor":5.00
> + "wseat":"agency1"
> o "Ext"
>
> *Discussion:*
> How would impression budgets be handled? For example, would the seller,
> buyer, or exchange be responsible for turning off this Deal ID once
> (from the example above) 1M impressions have been fulfilled?
>
> --
> You received this message because you are subscribed to the Google
> Groups "openrtb-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openrtb-dev...@googlegroups.com
> <mailto:openrtb-dev...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

--
Antoine Bonavita (ant...@stickyads.tv) - CTO StickyADS.tv
Tel: +33 6 34 33 47 36/+33 9 50 68 21 32
NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN | MADRID

Tait Clarridge

unread,
Nov 17, 2016, 8:04:20 AM11/17/16
to openr...@googlegroups.com
IMO the onus of figuring out the type of deal is up to the DSP by storing metadata about any deals they have struck in their platform and using the deal ID to figure it out.

The SSP is responsible for all the pacing of a PG deal, and ensuring that if the deal was struck at 1000 impressions, the SSP should only send 1000 requests for that deal to the DSP, anything else is a bonus for the DSP and they should not be billed for an SSP's mistake (eg. sending too much). If the DSP doesn't bid on a PG deal, it is their loss.

Pricing (fixed), as suggested by others in this thread, is already taken care of by imp.deals.at.

I'm against adding unnecessary additional fields, the more bloat we add to the protocol, the slower it will be.



For more options, visit https://groups.google.com/d/optout.

--
Antoine Bonavita (ant...@stickyads.tv) - CTO StickyADS.tv
Tel: +33 6 34 33 47 36/+33 9 50 68 21 32
NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN | MADRID
--
You received this message because you are subscribed to the Google Groups "openrtb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

—



Tait Clarridge | Manager. Bidder Engineering, Buyer Cloud

M: 416-579-5048


488 WELLINGTON STREET WEST, 2ND FLOOR, TORONTO, ON M5V 1E3

RUBICONPROJECT.COM | @RUBICONPROJECT

We’re Hiring: http://www.rubiconproject.com/join-us

james....@blis.com

unread,
Nov 17, 2016, 10:41:24 AM11/17/16
to openrtb-dev
Agreed, storing metadata is exactly the way we do it.
I don't think the spec will be able to cope with the various nuances each SSP has when it comes to PMP.

James

For more options, visit https://groups.google.com/d/optout.

--
Antoine Bonavita (ant...@stickyads.tv) - CTO StickyADS.tv
Tel: +33 6 34 33 47 36/+33 9 50 68 21 32
NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN | MADRID


--
You received this message because you are subscribed to the Google Groups "openrtb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

jgwi...@vindicotech.com

unread,
Nov 17, 2016, 1:50:45 PM11/17/16
to openrtb-dev
Hi Antoine,

Yes "fixed price" is handled by at=3.  I'm not proposing any change there.

The only proposal is to have a private_auction=2, which would flag the bid request as a PG deal.

You are absolutely correct, that the DSP can not be forced to bid.  The PG flag is simply meant as an explicit flag in the bid request to let the DSP know that the bid requests represent a pre-bought impression and so no-bids are throwing away paid for inventory.

We have agencies asking to buy PG via their DSP of choice, so we in the industry have a choice of building a completely separate channel for PG deals (which will be a lot of work), or including PG inventory via RTB pipes and flagging it so DSPs can know explicitly what the deal ID means.

I understand other comments in this thread would prefer to allow DSPs to use their existing methods of identifying PG deals (storing metadata), the truth is they can still do that.  They can ignore private_auction=2.  But I believe the point of a protocol is to have a standardized and transparent method of communicating throughout the industry that supports calling out all types of inventory. 

As for "adding another field" and protocol bloat... this proposal has no additional field.  The proposal simply adds a new value to an existing field.  private_auction currently includes 0 = open, 1 = private... the proposal is to extend these definitions to include 2 = PG. Personally, I completely agree with Tait (below).  I don't want bloat either, which is why no new field.

2 more cents...

J

jgwi...@vindicotech.com

unread,
Nov 17, 2016, 1:59:52 PM11/17/16
to openrtb-dev
Hi Tait,

I agree, the onus is on the DSP for figuring out how to handle a PG deal within their own system.  And it still will be if this proposal is accepted.

But the onus is on us as a community to build the most transparent and robust protocol we can.  The level of work I'm suggesting here is minor for the potential upside(s) of being explicit,transparent, and standardized in the protocol.

I also agree with your assessment of the responsibilities of SSP to stop after 1000, and the DSP if they don't bid.  Hopefully, including private_auction=2 will help systems (DSP & SSP) by providing an explicit hook to tie logic on ... rather than custom metadata at the DSP level...

Does this make sense?

J

For more options, visit https://groups.google.com/d/optout.

--
Antoine Bonavita (ant...@stickyads.tv) - CTO StickyADS.tv
Tel: +33 6 34 33 47 36/+33 9 50 68 21 32
NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN | MADRID


--
You received this message because you are subscribed to the Google Groups "openrtb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

jgwi...@vindicotech.com

unread,
Nov 17, 2016, 3:04:30 PM11/17/16
to openrtb-dev
Hi Sam,

Thanks for the deep dive here.

As for "restricting demand" I agree.  A PG deal however, doesn't need alternative demand from a Publisher perspective, because it's already been sold.  The DSP (or Agency) has already agreed to pay for all the imps sent.
If a DSP does decide to nobid (e.g. it's a bot impression), this condition should be handled in the Deal/contract and can be sorted post campaign in reporting/billing.
As for over delivery (SSP sends too much), I agree w/ Tait below, to say that this is on the SSP and DSP has no agreement to pay past the PG ordered impression volume.  I could see a DSP being polite and nobidding, and in this case I could see a reason for an alternative demand source filling.  Perhaps more discussion here in the case of SSP "over delivery" conditions is warranted.

"Guaranteed" deal for me means: Impressions are pre-bought, just like in the old days... "I'll buy 1M imps of your homepage, @ $0.50CPM" ... so whenever an imp hits the buyers system, it counts toward the 1M...  This means
1) Pricing terms = fixed price
2) Impression selection is handled by the Supply Side ad server.  (NOTE: verification can be done on DSP side in a "trust but verify" business model).  If a DSP is doing pacing, capping, targeting, then by definition the order type is not guaranteed, and this buy should be an auction where nobids are acceptable.
3) I agree w/ your point 3 below.

"Deal Class"
I like this for transparency.  It means that at Deal Creation time in the SSP, both sides (SSP & DSP) have the same relevant metadata about the deal in order to act upon respectively.
My only concern here would be protocol bloat as pointed out by Tait below.  It is only one field... (famous last words)...  
My only suggestion on this one would be to leave "standard" out and if the field is either NULL or not present, then assume standard.

I'm ok w/ my proposal or yours, as they both achieve my original goal of passing relevant Deal ID meta data in an explicit, transparent, and standardized manner.

Cheers,

J

To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev...@googlegroups.com.

Antoine Bonavita

unread,
Nov 17, 2016, 6:07:59 PM11/17/16
to openr...@googlegroups.com
Hello,

When you say "The PG flag is simply meant as an explicit flag in the bid
request to let the DSP know that the bid requests represent a pre-bought
impression and so no-bids are throwing away paid for inventory." Are you
suggesting that a DSP receiving private_auction=2 should still be
invoiced for an impression, even if it decides NOT to bid ?

A.

On 11/17/2016 07:50 PM, jgwi...@vindicotech.com wrote:
> Hi Antoine,
>
> Yes "fixed price" is handled by at=3. I'm not proposing any change there.
>
> The only proposal is to have a private_auction=2, which would flag the
> bid request as a PG deal.
>
> You are absolutely correct, that the DSP can not be forced to bid. The
> PG flag is simply meant as an explicit flag in the bid request to let
> the DSP know that the bid requests represent a pre-bought impression and
> so no-bids are throwing away paid for inventory.
>
> We have agencies asking to buy PG via their DSP of choice, so we in the
> industry have a choice of building a completely separate channel for PG
> deals (which will be a lot of work), or including PG inventory via RTB
> pipes and flagging it so DSPs can know explicitly what the deal ID means.
>
> I understand other comments in this thread would prefer to allow DSPs to
> use their existing methods of identifying PG deals (storing metadata),
> the truth is /they can still do that./ They can ignore
> private_auction=2. But I believe the point of a protocol is to have a
> /standardized and transparent/ method of communicating throughout the
> industry that supports calling out all types of inventory.
>
> As for "adding another field" and protocol bloat... this proposal has
> /no additional field. /The proposal simply adds a new value to an
> existing field. private_auction currently includes 0 = open, 1 =
> private... the proposal is to extend these definitions to include 2 =
> PG. Personally, I completely agree with Tait (below). I don't want
> bloat either, which is why no new field.
>
> 2 more cents...
>
> J
>
>
> On Thursday, November 17, 2016 at 12:37:54 AM UTC-8, Antoine Bonavita wrote:
>
> Hello,
>
> This is definitely a big topic that everybody is talking about.
>
> However, I feel there is a contradiction in your proposal between
> running an auction (therefore sending bid requests) and forbidding the
> bidder not to bid. Isn't there ?
>
> I don't think it is realistic to say that bidder will always bid.
> And if
> enforcing is not realistic, I think the price thing is already handled
> by the auction type 3 (fixed price) that is available at the deal
> level.
>
> My 2 cents.
>
> A.
>
> On 11/17/2016 02:31 AM, jgwi...@vindicotech.com <javascript:> wrote:
> > OpenRTB 2.5 Proposal: PMP/Deal ID "Programmatic Guaranteed"
> >
> > Author(s):
> >
> > Jonathan Gwiazda
> >
> > jgwi...@viantinc.com <javascript:> <mailto:jgwi...@viantinc.com
> <javascript:>>
> > an email to openrtb-dev...@googlegroups.com <javascript:>
> > <mailto:openrtb-dev...@googlegroups.com <javascript:>>.
> > For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
> --
> Antoine Bonavita (ant...@stickyads.tv <javascript:>) - CTO StickyADS.tv
> Tel: +33 6 34 33 47 36/+33 9 50 68 21 32
> NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN | MADRID
>
> --
> You received this message because you are subscribed to the Google
> Groups "openrtb-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openrtb-dev...@googlegroups.com
> <mailto:openrtb-dev...@googlegroups.com>.

jgwi...@vindicotech.com

unread,
Nov 17, 2016, 6:14:54 PM11/17/16
to openrtb-dev
Not necessarily.  If the deal has provisions (e.g. DSP will not pay for bot impressions), then a nobid would not be billable, and in this case it could be that the SSP has to provide more "make good" impressions to fulfill a pre-agreed volume (e.g. 1M imps).

But if the deal is PG and the Buyer guaranteed they would pay for 1M imps @ $5CPM, and there are no exceptions stipulated in the deal (e.g. bot fraud), then yes, contractually speaking, a "no bid" is not the fault of the SSP/Seller, and the DSP/Buyer agreed to buy it.

This parallels/mirrors the other comments in this thread that express if the SSP "over delivers" past the 1M imps, then the DSP is not at fault and should not have to pay.

Cheers,

J

>     > <mailto:openrtb-dev+unsub...@googlegroups.com <javascript:>>.
>     > For more options, visit https://groups.google.com/d/optout
>     <https://groups.google.com/d/optout>.
>
>     --
>     Antoine Bonavita (ant...@stickyads.tv <javascript:>) - CTO StickyADS.tv
>     Tel: +33 6 34 33 47 36/+33 9 50 68 21 32
>     NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN | MADRID
>
> --
> You received this message because you are subscribed to the Google
> Groups "openrtb-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openrtb-dev...@googlegroups.com

Antoine Bonavita

unread,
Nov 17, 2016, 6:27:47 PM11/17/16
to openr...@googlegroups.com
I don't know what other people in the list think, but I (as a video SSP
and speaking from experience) would be very surprised to see DSP accept
to pay if they don't bid.

So, if it does not have any effect neither on the behavior of the bidder
nor on the contractual relationship, I think we don't need this.

A.
> > > <mailto:openrtb-dev...@googlegroups.com
> <javascript:> <javascript:>>.
> > > For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>
> > <https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>>.
> >
> > --
> > Antoine Bonavita (ant...@stickyads.tv <javascript:>) - CTO
> StickyADS.tv
> > Tel: +33 6 34 33 47 36/+33 9 50 68 21 32
> > NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN |
> MADRID
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "openrtb-dev" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send
> > an email to openrtb-dev...@googlegroups.com <javascript:>
> > <mailto:openrtb-dev...@googlegroups.com <javascript:>>.
> > For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
> --
> Antoine Bonavita (ant...@stickyads.tv <javascript:>) - CTO StickyADS.tv
> Tel: +33 6 34 33 47 36/+33 9 50 68 21 32
> NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN | MADRID
>
> --
> You received this message because you are subscribed to the Google
> Groups "openrtb-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openrtb-dev...@googlegroups.com
> <mailto:openrtb-dev...@googlegroups.com>.

Sam Tingleff

unread,
Nov 17, 2016, 7:38:37 PM11/17/16
to openr...@googlegroups.com
Guaranteed deals is probably in the category of things which should bake for a while before we look for standardization. I'm happy to share our plans at Rubicon as we move forward.

There's an interesting discussion to be had around what the requirements should be for something to be seriously considered ready to merge in to the spec. I'm of the opinion that _somebody, somewhere_ should be transacting against an extension similar in spirit to a proposal. It's got to survive live contact with customers.

    <javascript:> <javascript:>>.

    >     > For more options, visit https://groups.google.com/d/optout
    <https://groups.google.com/d/optout>
    >     <https://groups.google.com/d/optout
    <https://groups.google.com/d/optout>>.
    >
    >     --
    >     Antoine Bonavita (ant...@stickyads.tv <javascript:>) - CTO
    StickyADS.tv
    >     Tel: +33 6 34 33 47 36/+33 9 50 68 21 32
    >     NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN |
    MADRID
    >
    > --
    > You received this message because you are subscribed to the Google
    > Groups "openrtb-dev" group.
    > To unsubscribe from this group and stop receiving emails from it,
    send
    > an email to openrtb-dev...@googlegroups.com <javascript:>
    > <mailto:openrtb-dev+unsubscribe...@googlegroups.com <javascript:>>.

    > For more options, visit https://groups.google.com/d/optout
    <https://groups.google.com/d/optout>.

    --
    Antoine Bonavita (ant...@stickyads.tv <javascript:>) - CTO StickyADS.tv
    Tel: +33 6 34 33 47 36/+33 9 50 68 21 32
    NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN | MADRID

--
You received this message because you are subscribed to the Google
Groups "openrtb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send

For more options, visit https://groups.google.com/d/optout.

--
Antoine Bonavita (ant...@stickyads.tv) - CTO StickyADS.tv

Tel: +33 6 34 33 47 36/+33 9 50 68 21 32
NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN | MADRID

--
You received this message because you are subscribed to the Google Groups "openrtb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.

Antoine Bonavita

unread,
Nov 18, 2016, 6:43:14 AM11/18/16
to openr...@googlegroups.com
Sam,

That makes sense to me. In particular, this higher-level concept could
handle yearly annual agreements (which are very common in the TV
industry) and allow both parties to synchronize on this.

A.

On 11/18/2016 01:37 AM, 'Sam Tingleff' via openrtb-dev wrote:
> Guaranteed deals is probably in the category of things which should bake
> for a while before we look for standardization. I'm happy to share our
> plans at Rubicon as we move forward.
>
> There's an interesting discussion to be had around what the requirements
> should be for something to be seriously considered ready to merge in to
> the spec. I'm of the opinion that _somebody, somewhere_ should be
> transacting against an extension similar in spirit to a proposal. It's
> got to survive live contact with customers.
>
> On Thu, Nov 17, 2016 at 3:27 PM, Antoine Bonavita <ant...@stickyads.tv
> <mailto:ant...@stickyads.tv>> wrote:
>
> I don't know what other people in the list think, but I (as a video
> SSP and speaking from experience) would be very surprised to see DSP
> accept to pay if they don't bid.
>
> So, if it does not have any effect neither on the behavior of the
> bidder nor on the contractual relationship, I think we don't need this.
>
> A.
>
>
> On 11/18/2016 12:14 AM, jgwi...@vindicotech.com
> <mailto:jgwi...@vindicotech.com> <javascript:>
> wrote:
> > > OpenRTB 2.5 Proposal: PMP/Deal ID "Programmatic
> Guaranteed"
> > >
> > > Author(s):
> > >
> > > Jonathan Gwiazda
> > >
> > > jgwi...@viantinc.com <mailto:jgwi...@viantinc.com>
> <javascript:> <mailto:jgwi...@viantinc.com
> <mailto:openrtb-dev...@googlegroups.com> <javascript:>
> > > <mailto:openrtb-dev...@googlegroups.com
> <mailto:openrtb-dev%2Bunsu...@googlegroups.com>
> <javascript:> <javascript:>>.
>
> > > For more options, visit
> https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>
> <https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>>
> > <https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>
> <https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>>>.
> >
> > --
> > Antoine Bonavita (ant...@stickyads.tv
> <mailto:ant...@stickyads.tv> <javascript:>) - CTO
> StickyADS.tv
> > Tel: +33 6 34 33 47 36
> <tel:%2B33%206%2034%2033%2047%2036>/+33 9 50 68 21 32
> <tel:%2B33%209%2050%2068%2021%2032>
> > NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER |
> MILAN |
> MADRID
> >
> > --
> > You received this message because you are subscribed to
> the Google
> > Groups "openrtb-dev" group.
> > To unsubscribe from this group and stop receiving emails
> from it,
> send
> > an email to openrtb-dev...@googlegroups.com
> <mailto:openrtb-dev...@googlegroups.com> <javascript:>
> > <mailto:openrtb-dev...@googlegroups.com
> <mailto:openrtb-dev%2Bunsu...@googlegroups.com> <javascript:>>.
> > For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>
> <https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>>.
>
> --
> Antoine Bonavita (ant...@stickyads.tv
> <mailto:ant...@stickyads.tv> <javascript:>) - CTO StickyADS.tv
> Tel: +33 6 34 33 47 36
> <tel:%2B33%206%2034%2033%2047%2036>/+33 9 50 68 21 32
> <tel:%2B33%209%2050%2068%2021%2032>
> NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN |
> MADRID
>
> --
> You received this message because you are subscribed to the Google
> Groups "openrtb-dev" group.
> To unsubscribe from this group and stop receiving emails from
> it, send
> an email to openrtb-dev...@googlegroups.com
> <mailto:openrtb-dev%2Bunsu...@googlegroups.com>
> <mailto:openrtb-dev...@googlegroups.com
> <mailto:openrtb-dev%2Bunsu...@googlegroups.com>>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
> --
> Antoine Bonavita (ant...@stickyads.tv
> <mailto:ant...@stickyads.tv>) - CTO StickyADS.tv
>
> Tel: +33 6 34 33 47 36 <tel:%2B33%206%2034%2033%2047%2036>/+33 9 50
> 68 21 32 <tel:%2B33%209%2050%2068%2021%2032>
> NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN | MADRID
>
> --
> You received this message because you are subscribed to the Google
> Groups "openrtb-dev" group.
> To unsubscribe from this group and stop receiving emails from it,
> send an email to openrtb-dev...@googlegroups.com
> <mailto:openrtb-dev%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout
> <https://groups.google.com/d/optout>.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "openrtb-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to openrtb-dev...@googlegroups.com
> <mailto:openrtb-dev...@googlegroups.com>.

Tait Clarridge

unread,
Nov 18, 2016, 3:56:32 PM11/18/16
to openr...@googlegroups.com
I don't think this concept has any part in OpenRTB as a standard, at some point businesses are going to have to figure the billing/delivery part out for themselves - consider it a kind of secret sauce that might pull publishers one way or another.

As for the protocol, it still seems pretty straightforward where we don't need to make changes - in the terms of any deal, whether digital or in-person, the buyer and the seller (or broker) strike an accord in price and quantity of said item, it is up to the seller (or broker on behalf of a seller) to reliably (to the best of their ability) deliver those items to the buyer, and it is up to the buyer to pay for those items in full to the seller/broker and keep track of what the seller has sent them.

We shouldn't try to mess with this dynamic that has worked for quite a while. The buyer has asked the seller for 10000 impressions at $5 CPM, if they don't return a positive bid response for every single one of the requests the seller has sent them, that is their loss. As for hinting, the buyer should be tracking the terms of the deal and make decisions accordingly - we shouldn't add bloat/waste to the protocol when it is simple to track what you've agreed upon and with who.

Think of this in terms a shipment you might receive from an online retailer:

You have purchased 10 individual pairs of socks and have entered into an agreement (deal) with the seller to purchase 10 of their pairs of socks at $10 per pair. You are given 2 options for shipping, insured and uninsured. Assuming taxes no longer exist (let's live in that world) and the cost for each shipping method is free, you pay the seller $100 and then you will receive a confirmation of the terms of your agreement for your records indicating the number of items, cost per item, and the shipping method you chose, as well as the final cost that you have paid the seller. When the package arrives, and if it were all smashed to bits, you wouldn't look on the shipping label to tell you that you bought shipping insurance - you as the buyer are aware of the terms of your deal and should react accordingly to the package arriving smashed at your door.

Tait


On Fri, Nov 18, 2016 at 6:43 AM, Antoine Bonavita <ant...@stickyads.tv> wrote:
Sam,

That makes sense to me. In particular, this higher-level concept could handle yearly annual agreements (which are very common in the TV industry) and allow both parties to synchronize on this.

A.

On 11/18/2016 01:37 AM, 'Sam Tingleff' via openrtb-dev wrote:
Guaranteed deals is probably in the category of things which should bake
for a while before we look for standardization. I'm happy to share our
plans at Rubicon as we move forward.

There's an interesting discussion to be had around what the requirements
should be for something to be seriously considered ready to merge in to
the spec. I'm of the opinion that _somebody, somewhere_ should be
transacting against an extension similar in spirit to a proposal. It's
got to survive live contact with customers.

On Thu, Nov 17, 2016 at 3:27 PM, Antoine Bonavita <ant...@stickyads.tv
 <mailto:ant...@stickyads.tv>> wrote:

    I don't know what other people in the list think, but I (as a video
    SSP and speaking from experience) would be very surprised to see DSP
    accept to pay if they don't bid.

    So, if it does not have any effect neither on the behavior of the
    bidder nor on the contractual relationship, I think we don't need this.

    A.


    On 11/18/2016 12:14 AM, jgwi...@vindicotech.com
            >     > <mailto:openrtb-dev+unsubscribe...@googlegroups.com
        <mailto:openrtb-dev%2Bunsubscri...@googlegroups.com>
            > <mailto:openrtb-dev+unsubscribe...@googlegroups.com
        <mailto:openrtb-dev%2Bunsubscri...@googlegroups.com> <javascript:>>.

            > For more options, visit https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>
            <https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>>.

            --
            Antoine Bonavita (ant...@stickyads.tv
         <mailto:ant...@stickyads.tv> <javascript:>) - CTO StickyADS.tv
            Tel: +33 6 34 33 47 36
         <tel:%2B33%206%2034%2033%2047%2036>/+33 9 50 68 21 32
        <tel:%2B33%209%2050%2068%2021%2032>

            NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN |
        MADRID

        --
        You received this message because you are subscribed to the Google
        Groups "openrtb-dev" group.
        To unsubscribe from this group and stop receiving emails from
        it, send
        an email to openrtb-dev+unsubscribe@googlegroups.com
         <mailto:openrtb-dev%2Bunsubscri...@googlegroups.com>
        <mailto:openrtb-dev+unsubscribe...@googlegroups.com
        <mailto:openrtb-dev%2Bunsubscri...@googlegroups.com>>.

        For more options, visit https://groups.google.com/d/optout
        <https://groups.google.com/d/optout>.


    --
     Antoine Bonavita (ant...@stickyads.tv
    <mailto:ant...@stickyads.tv>) - CTO StickyADS.tv

    Tel: +33 6 34 33 47 36 <tel:%2B33%206%2034%2033%2047%2036>/+33 9 50
    68 21 32 <tel:%2B33%209%2050%2068%2021%2032>

    NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN | MADRID

    --
    You received this message because you are subscribed to the Google
    Groups "openrtb-dev" group.
    To unsubscribe from this group and stop receiving emails from it,
    send an email to openrtb-dev+unsubscribe@googlegroups.com
     <mailto:openrtb-dev%2Bunsubscri...@googlegroups.com>.

    For more options, visit https://groups.google.com/d/optout
    <https://groups.google.com/d/optout>.


--
You received this message because you are subscribed to the Google
Groups "openrtb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to openrtb-dev+unsubscribe@googlegroups.com
<mailto:openrtb-dev+unsubscribe...@googlegroups.com>.

For more options, visit https://groups.google.com/d/optout.

--
Antoine Bonavita (ant...@stickyads.tv) - CTO StickyADS.tv
Tel: +33 6 34 33 47 36/+33 9 50 68 21 32
NEW YORK | LONDON | HAMBURG | PARIS | MONTPELLIER | MILAN | MADRID

--
You received this message because you are subscribed to the Google Groups "openrtb-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openrtb-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.



--

Tevi Abrams-Slep

unread,
Nov 22, 2016, 3:32:40 PM11/22/16
to openr...@googlegroups.com

Chiming in here a few days late --

a) Re: Tait's idea that this is the buyer's responsibility to know how their deal is set up:

As the DSP, I think it's fundamentally important for the SSP to confirm that a deal is PG. Right now, the only way I know a deal is PG is if my advertiser tells me. Which means I have to raise its priority. This is the correct behavior for now, but a part of me is concerned that a few advertisers will wise up to this and claim that any fixed-price deal is actually PG so that I'm required to bid with it. 

(This only applies when the SSP is sending multiple deals in the bid request. They might do this with PG if they want backup options for when the DSP refuses to buy on the PG deal. See c) below.)

b) Re concerns about redundant data: As the DSP, I might actually *want* to store this info. In the counterpart scenario to a), an SSP could accidentally claim that a deal is PG. If I don't double-check with the advertiser, I could accidentally spend their entire month's budget in a single day. Verifying that both parties *agree* the deal deserves PG behavior seems like the only sustainable solution.

c) Re the specific notation: If this does wind up being included, I have a concern with this being in the overall PMP object and have a strong preference for it being on the individual Deal object.

Echoing others, DSPs do have valid reasons to no-bid on PG requests, and in those cases it is appropriate to bid with something else (& try to match a different deal or go to open auction). Those reasons include: 1) buyer simply hasn't targeted the deal yet, even though they should have 2) buyer has a global/emergency budget cap, per Sam.

-Tevi

Alex Merwin

unread,
Nov 24, 2016, 7:29:50 AM11/24/16
to openr...@googlegroups.com
+1 for adding a pmp.deals.dealclass field for consideration in 2.6. Probably a little late to get it included for 2.5 which is already available for public comment. 

SSP signaling will aid DSP decisioning when DSPs refuse multi-bid. 

Also, I think that the initial deal structures we're seeing in PG could broaden over time. By breaking this out as its own field (versus adding an additional value to pmp.deals.at) the spec will have more flexibility down the road to accommodate these, e.g. share of voice type deals. 







Alex Merwin | VP, International

M: +44 (0) 7490 132 754 | LinkedIn  



Reply all
Reply to author
Forward
0 new messages