OpenRTB 2.5 Proposal - "Ad Markup Delivered" Pixels

[jgwi...@vindicotech.com]

Your thoughts please...

OpenRTB 2.5 Proposal: Ad Markup Delivered Pixels

Author(s):

Jonathan Gwiazda

jgwi...@viantinc.com

Problem Statement:

An “Impression” as defined by the IAB is counted “at a point as late as possible in the process of delivery of the creative material to the user’s browser …”  

Unfortunately, this is not what most (if not all) exchanges are counting as impressions.  Exchanges are counting impressions on “auction wins,” which are internal to their system’s servers and are counted very early in the process of delivery.

Realistically, an Exchange’s service to Bidders is the delivery of the winner’s ad markup to the browser, because the delivery of the ad markup to the page is completely in the Exchange’s control.  However, what happens after the ad markup (provided by the Bidder) is read by the browser is beyond the Exchange’s control (e.g. 3rd party blocking).  

The problem? → Charging on “auction wins” leads to significant discrepancies between Exchange “impression” counts and Bidders counts.  Honestly, as a Bidder, I want to purchase the delivery of my Ad Markup to the browser, so I can have the opportunity to show an ad to a Consumer and thus monetize the media I bought.

To remove discrepancies, Exchanges and Bidders need to agree upon and be counting the same billable event.

Outline of the solution:

1. Exchange injects two “ad markup delivered” pixels to ad markup delivered to browser.  One pixel is fired to the Exchange, the other is fired to the Bidder

2. Include “auction win price” macro in the pixels

Proposed Solution:

Exchange injects two “ad_markup_delivered” pixels with the ad markup.  One pixel should fire back to the Exchange, the other (perhaps provided by the Buyer) should fire back the Bidder’s system.

The ad_markup_delivered pixels should include the “auction_win_price” macro, so both parties know how much the Exchange will charge the Bidder.

Discussion

1. Should we deprecate the use of win macros in “nurl” & embedded in display ad markup?

1. In my opinion, win price macros in the pixels proposed is a much simpler, cleaner, and consistent approach. To remove discrepancies, Exchanges and Bidders need to agree upon and be counting the same billable event.

[Jim Butler]

The overall issue is certainly a valid one and is the subject of ongoing discussion that will likely need to wait until OpenRTB 3.0 to resolve due to backward compatibility constraints within 2.x.  A couple other comments however:

Unfortunately (for someone like me who operates an exchange), the idea that exchanges have complete control of getting the markup on the page is just not true anymore.  There are often upstream mediators from the exchange and now header bidding where a final decision is rendered.  This supply chain complexity that has emerged since the OpenRTB v2.0 spec is one of the key factors that will drive v3.0 in my opinion since all of these intermediaries need to know how to communicate and be notified of relevant events; not just the simple exchange-bidder model of years past.

The OpenRTB win notice was intended to be just that "hey, you won the auction"; it does not necessarily imply billing.  Whether or not an exchange charges on that win or on delivery is a business policy and not an OpenRTB standards issue.  That said, I do happen to agree with the policy of billing on delivery and this is the policy of our exchange.  To accomplish this, we do indeed inject a pixel into the markup that passes through us so that we know when this happens.

All that aside, I'm still not sure what you're proposing that's different.  The whole point of OpenRTB macros being resolved within markup is for your use case of injecting things like clearing price into pixels for buyers.  Similarly, I don't believe anything is accomplished by removing macros from win notices.  They are there for the benefit of buyers; if some buyers don't find them useful, they need not be included.

I thing the problem you're really trying to solve is clarity around "auction win" versus "your markup was in fact delivered to the user" and as an adjacent issue, understanding which of those constitutes the billing event.  Circling back, this area has been recognized as a real need, but I think we need to evolve our model of the supply chain (and the demand chain for that matter) to reflect the real industry direction and develop a solution for that.

:JB

--
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.

--

James M. Butler, Ph.D.

VP Mobile Exchange Technology | AOL Platforms

155 Seaport Blvd, 8th Floor, Boston MA 02210

+1.617.834.2125 | Mobile

jim.b...@teamaol.com

 

[jgwi...@vindicotech.com]

Hi Jim,

Thanks for the thoughtful input.  Great points here.  You are correct in saying that what an exchange decides is a billable event is a matter of policy, and not a matter for OpenRTB standards.  Perhaps I should narrow the proposal to simply be for an "ad markup delivered" field, so ... As a Bidder, I want to know my ad markup was delivered to the page, so I can have that essential piece of information to begin troubleshooting discrepancies between Exchange counts and my counts...

As for macros, I'm not suggesting doing away with them.  You're right, as a Bidder, I need them!  I just think doing them in a pixel on ad markup delivery is simpler than nurl or embed in creative...  Perhaps this approach could simply be another method of win notification Bidders can choose from along with nurl and embed in creative...

When you have some time to think, perhaps you could suggest some directional ideas for resolving our "supply (and demand) chain complexity" around this issue?  I'd rather not wait until 3.0 to get this conversation going.

Cheers,

J

[jgwi...@vindicotech.com]

PLEASE NOTE: this proposal is more directed to Display exchanges, rather than Video (most of whom charge of an impression pixel or "ad start" event in the creative media file)

Cheers,

J

[Andraž Tori]

Some info from native space that has younger codebases and has perhaps taken some learnings from issues in display.

Quite some exchanges only place their pixel to be rendered, then when receiving that ping from the client they do server to server billing(win) notification to the DSP. Therefore there is near-zero discrepancy (we see discrepancies down to cents). Then discrepancy can happen only if bidder's endpoint is unreachable by the exchange, but that means you have bigger issues to worry about. 

As for billing I believe that is preferable over two independent pixels placed - you can imagine user having some ad blocking solution blocking one, but not the other, again resulting in discrepancy.

This does not preclude additional pixels used by DSP for impression tracking. Also this does not resolve the business question of what is billable, but server2server billing/win notifications remove unexpected surprises at the end of the month when exchange believes you owe them more than you think you do.

bye

andraz

[Nir Peer]

Hi,

We are definitely in favor of introducing an explicit impression tracker to Display bids, just as done in Video and Native.

However, there is an equal need for a separate and explicit auction win notification. Auction wins fired close to the completion of the auction are very useful to bidders for optimization and for various technical reasons.

Thanks!

Nir Peer

Founding Engineer—Backend | http://www.appreciate.mobi/

       SPAIN - ISRAEL - UK

[jgwi...@vindicotech.com]

Have updated the proposal...  please review here:

https://docs.google.com/a/vindicogroup.com/document/d/1Ex5w0w0uXyAZTXutJ6xJ2YG1SGmpnITEUa10lv2u99g/edit?usp=sharing

Cheers,

J

On Wednesday, June 15, 2016 at 3:31:45 PM UTC-7, jgwi...@vindicotech.com wrote:

[jgwi...@vindicotech.com]

new version:

OpenRTB 2.5 Proposal: Billable Events

Author(s):

Jonathan Gwiazda

jgwi...@viantinc.com

Problem Statement:

An “Impression” as defined by the IAB is counted “at a point as late as possible in the process of delivery of the creative material to the user’s browser …”  

Unfortunately, this is not what many exchanges are counting as impressions.  Exchanges are counting impressions on “auction wins,” which are internal to their system’s servers and are counted very early in the process of delivery.

Realistically, an Exchange’s service to Bidders is the delivery of the winner’s ad markup to the browser, because the delivery of the ad markup to the page is completely in the Exchange’s control.  However, what happens after the ad markup (provided by the Bidder) is read by the browser is beyond the Exchange’s control (e.g. 3rd party blocking).  

The problem? → Charging on “auction wins” leads to significant discrepancies between Exchange “impression” counts and Bidders counts.  Honestly, as a Bidder, I want to purchase the delivery of my Ad Markup to the browser, so I can have the opportunity to show an ad to a Consumer and thus monetize the media I bought.

To remove discrepancies, Exchanges and Bidders need to agree upon and be counting the same billable event.

Proposed Solution:

1. Exchange utilizes a “Billing URL” (bURL) to signify a billable event

1. “Notification URL” (nURL) is retained in the spec, but utilized to signify an auction win event

2. bURL would include price macros the same way nURL does

3. bURL would be subject to expiry time constraint, if the billable event is cached (not immediate)

1. Exchanges can still use the “imp.exp attribute (Section 3.2.2) in the bid request allows an exchange to provide guidance to bidders of the number of seconds that may elapse between the auction and the billing event.”

2. Bidders can still use the “bid.exp attribute (Section 4.2.3) in the bid response allows the bidder to express the maximum number of seconds they are willing to tolerate between auction and billing notice.”

Discussion:

Multiple Impressions in the same Bid Request … should not be affected by the use of a bURL.  Each impression would execute the bURL in the exact same manner a nURL would have been executed.

On Wednesday, June 15, 2016 at 3:31:45 PM UTC-7, jgwi...@vindicotech.com wrote:

[Jim Butler]

+1

--
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.

[Ian Trider]

Love it.  Ship it!

[James Cooper]

Why don't you just put your own impression tracking pixel in the adm?

[Andraž Tori]

At least in native, the fact that we're getting most of the nurls called from server side and not client is a blessing. So please, do not deperecate nurl. If anything, make it mandatory to be called from server side :).

Discrepancies there are close to zero in such cases, both sides have exactly the same number to be used for billing.

When the flow is 

client -> SSP/exchange server -> DSP server, this means SSP and DSP are in sync.

when it's a notice from client independently to SSP and DSP, one or another might be blocked for whatever reason and then discrepancies start mounting.

bye

andraz

[Ian Trider]

In many circumstance, loading of the ad markup does not constitute a billable event -- for example, mobile interstitial, where the markup will be loaded (cached) in advance of being displayed, and sometimes will never end up being displayed (if user abandons app before interstitial opportunity arrives).

In this case, a clear unambiguous "billing URL" to be called when the billing event is happening is beneficial. This could be delivered from the client or S2S, but the point would be for it to umambiguously correspond to the event that the exchange considers billable.

[Ian Trider]

Andraz,

I think for the purpose you are describing, the proposed burl is more appropriate.  You're talking about counting an event that is considered billable, right?  Winning an auction does not necessarily mean a billable event is happening (such as in header bidding, when there will be additional decisioning logic in the ad server that may cause an auction's winner to never serve).

Nurl is used by some exchanges in a manor equivalent to the proposed burl but this attaches a meaning to nurl that it doesn't have in the spec -- its supposed to merely mean you won the auction, not that you are going to be billed for an impression. Burl would allow both types of notifications to occur without confusion over the meaning/usage of the field.

[John Cheng]

Hi,

Billing discrepancies is a growing problem and having explicit tracking elements in the spec is a clear and logical technical solution. +1 on the bringing up the issue.

I'm a bit late to the game here, but one thing I'd like to propose is to replace "burl" with an array of URLs rather a single URL. This would make it consistent with the use of response.imptrackers array in the Native protocol and more closely model the approach used by MoPub, which is already transacting in the wild (https://dev.twitter.com/mopub-demand/impression-tracking). If this change makes sense, I'd propose we rename the field to "imptrackers" for consistency. Your thoughts?

[Jim Butler]

I feel like this problem of billable vs. win events has been waiting for a solution for a long time.  I'd really love to get this working ASAP and putting my Exchange hat on and think about how I'm going to implement this covering all my use cases (e.g., web, app/SDK including those currently in the field, video, etc.), a single pixel is a lot easier than an array.

Also because this has been one of the biggest holes in OpenRTB, I would really like to know we've nailed it before further complicating it.  And it's consistent with OpenRTB's own win notice (i.e., single event).

Since it signifies a financial event (i.e., "hey bidder, you can now decrement spend since we the exchange are now booking this amount"), it doesn't feel right to make several calls some of which could get dropped as happens from time to time leading to another source of discrepancies among the recipients. 

I personally like the idea that "nurl" and "burl" will be each single, authoritative, and reliable notifications from the Exchange conveying what will finally be very clear messages to the Bidder about the bid they just made, and hopefully major problem solved. 

:JB

__________________________

[Nitin Bhartiya]

>> the idea that "nurl" and "burl" will be each single, authoritative, and reliable notifications from the Exchange conveying what will finally be very clear messages to the Bidder about the bid they just made, and hopefully major problem solved. 

I think there are certain assumptions built into this idea of "single" and "authoritative" notification from the exchange, notably that  

1. Bidders or buyers or other 3rd parties would not necessarily want a client side event notification
2. Exchanges are centralized marketplaces with direct relationship with bidders and publishers / app developers, while in reality there are multiple entities in the value chain, and all or most of them conduct their own auctions and/or mediation, and have the intention, (probably driven from lack of trust or transparency), to receive their event trackers from the client, rather than from the other downstream entity
   

IMO, #1 and #2 does not represent the reality and probably multiple trackers from each entity help address these assumptions, similar to what has been done for native.

Somewhat tangential, but to take it even further, I think the construct of the native object is brilliant, as it addresses lots of issues such as the one we are discussing with banners. In fact, banner (as well as video) object should be sub part of native object (just "asset" types, video is already there), representing reduced degree of customization for the creative for the publisher. i.e. With native object present, there is no need of a separate banner object in OpenRTB

Regards,

Nitin

Product@Rubicon

[Ian Trider]

Nitin,

As a DSP though, I need a clear indication that the exchange is going to bill me. Sure, entities in the value chain who want to count impressions can and should do it themselves client-side, but they're not responsible for the direct cost of the media transaction between the DSP and the Exchange. Whether not an impression actually happens feels almost tangental to me as a DSP -- what I want to know is I'm going to be billed something. Of course I should be able to validate that the impression happened accordingly (through my own tracking mechanism in my markup), but I see it as a matter separate from a billing notification.

For what its worth though, I don't think the field implies server-side notification -- I would actually prefer that exchanges generally implement this by loading the pixel URL client-side. One might argue then, "well how is this any different than the DSP including an impression tracking pixel in its markup?" To that, I point to scenarios like mobile interstitials (where the impression generally isn't billable til displayed, though the markup will be pre-cached), and regardless, making the exchange responsible for triggering the delivery or firing of the billing event pixel means that it can be as synchronous as possible with the exchange's own counting mechanism.

[Bill Simmons]

+1 on this proposal.  a definitive billable event signal will be a big step forward in reducing discrepancies.

-bill

--

Willard Simmons
Co-Founder / CTO

DataXu
+1 617 752 1123
dataxu.com | @dataxu
DataXu Rated #1 Total Advertising Solution

[Jim Butler]

+1

Bear in mind that this isn't just a delivery tracker.  It reflects the specific policy of the exchange as to when the impression becomes billable to the bidder whether their policy is on the viewability end of the spectrum or all the way back to the auction win (which I don't endorse, but there are such exchanges and we don't write their policy) or anywhere in between.  Wherever it lies, the bidder who agreed to that policy needs to know when to decrement spend.

Also, the very valid point of the supply and demand chains being much more complex than the simple 2-party exchange/bidder scenario will likely be taken up more holistically as part of 3.0.  In fact it may well be the catalyst for advancing the major release counter to 3.x.

:JB

[Andraž Tori]

+1

If possible, can we define burl has to be sent to DSP by the server, not client? (since client notifications are unpredictable if they are sent to two different endpoints at the same time - exchange's and dsp's)

[Jim Butler]

I don't think we can really mandate server-to-server calls, but we can certainly point out the special (i.e., direct financial) nature of the call and recommend.

Purely by way of example speaking as someone on the exchange, the actual event that leads to us saying "it's time to book revenue for this impression" originates in multiple ways; a tracking pixel is only one of them.  But there is just one or two spots in our server code where this information is normalized into what I would call a general billing event and where we then proceed to book the revenue.  I would probably call the "burl" as close to that point as possible.

:JB

[Nitin Bhartiya]

Thanks Jim and Ian. Make sense. I was pointing to the supply and demand chain complexity and whether the single burl solves that but it all make sense, if the billable tracker is separate from impression tracker(s), which can still be controlled by multiple parties and on client side.

[John Cheng]

Thanks everyone for the insights. Now I understand how using a single burl eliminates ambiguity and it makes a lot of sense. The point about this not being "just a delivery tracker" is especially well put!

It seems to me that the purpose of the imptracker array is for solving a different problem: informing downstream systems that "this impression has been shown to a user". This event does not necessarily equate to billing conditions. To that extent, I think there's still a use for adding an imptracker array to OpenRTB 2.5, for the purpose of explicitly denoting tracking impressions rather than today's practice of embedding them into creatives.  Since they are related, I'd like to describe burl and imptrackers in relation to each other

burl - A clear indication that the exchange is going to bill a DSP. In contrast to imptrackers, this is expected to be fired when one party knows it has decided to bill another party.

imptrackers - Signals to downstream systems that the impression has been seen by users. In contrast to burl, this is not necessarily a billable event, and the urls are supported on a best-effort basis by the upstream system.

This means imptrackers should be in a separate propsoal, I'd be happy to write that up if ya'll think this make sense.

[Tait Clarridge]

Definite +1 on the burl initiative - this would help a lot with native ads where depending on the SDK you can get multiple "impression tracking" events per billable event whenever the slot rolls into view.

This could also add a nice feedback loop to billable impressions where, instead of waiting on generated reports or having to reach out to SSPs to generate them adhoc, it would be much more efficient to track down NHT/Fraud in real-time and block them without spending a day buying that inventory before traditional feedback loops are available.

—

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

[Ian Trider]

To Nitin and John,

You have a good point -- there's got to be a better way to count impressions.  Particularly, the scenario I noted (mobile interstitials) is guaranteed to cause "discrepancies" with a third party ad server.

Unfortunately, I have no idea on how that would be solved without substantial changes to the current norms of how these third-party servers count impressions.