Flag for count on render vs count on decision?

[boke...@gmail.com]

Hi there,

I'm curious if the OpenRTB spec has a way to specify whether an impression will be counted by the seller on render vs on decision. The industry is clearly moving to the former, finally, and it would be very useful for discrepancy management to know which scenario we're in. The flag is useful (vs having it be known at the platform level) because different formats may have different notify mechanisms (for instance, AppNexus still has legacy ad tags on publishers that are count on decision, while our newer tags are all count on render).

Extending this to "count on viewable" or other events might be really slick; we're going to share a proposal for viewable buying in a couple of weeks, but that could be a completely separate mechanism too.

b

[Jim Butler]

The billing notification URL introduced in v2.5 is intended to eliminate these discrepancies by firing at whatever event any given exchange deems billable under their business policy.  The intent is to eliminate (or at least reduce to noise) the delta between what a DSP is billed at the end of the month and the sum of real-time spend notifications over that period irrespective of policies that may vary among exchanges.

: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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

James M. Butler, Ph.D.

VP Engineering, Publisher Platforms | AOL Platforms

155 Seaport Blvd, 8th Floor, Boston MA 02210

+1.617.834.2125 | Mobile

jim.b...@teamaol.com

 

This electronic message transmission contains information from AOL Inc., which may be confidential or privileged. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this information is strictly prohibited. If you have received this electronic transmission in error, please notify sender immediately and delete all copies.

[Jim Butler]

The billing notification URL introduced in v2.5 is intended to eliminate these discrepancies by firing at whatever event any given exchange deems billable under their business policy.  The intent is to eliminate (or at least reduce to noise) the delta between what a DSP is billed at the end of the month and the sum of real-time spend notifications over that period.

:JB

On Fri, Mar 10, 2017 at 9:19 AM, <boke...@gmail.com> wrote:

--

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.

[Brian O'Kelley]

Jim,

I think that addresses the discrepancy between the seller's numbers and their total billing, but not the discrepancy that the buyer will see. With DCM finally moving to count on render, this means you might see no discrepancy between seller numbers and the bill they send, but a big discrepancy between those numbers and what the advertiser is willing to pay. We're seeing 10-15% differences there, which is massive, and could wipe out the entire margin for the SSP if the buyer's numbers are used.

I would suggest a) some indication of how the seller is counting and/or b) setting a firm standard that OpenRTB has to be count-on-render.

b

[Ian Trider]

Maybe something that would be helpful to clear up here.. how can an intermediary who is not directly responsible for the rendering of the ad accurately measure count-on-begin-to-render?

I can imagine how one could deliver a client-side pixel placed directly after the arbitrary HTML snippet from upstream; that ought to execute coincidentally (or slightly after) the guts of the arbitrary HTML snippet begins to render, but I don't really know when the ad content itself has begun to render. (I imagine under some circumstances it would be possible to inspect the DOM to see if the ad content is there but this seems like it would require intimate knowledge of third-party ad servers' client-side code to track down the ad content itself)

Am I overthinking the expectations of the new guidelines here? To me, as an intermediary, it doesn't seem like there's much I can do different from what I do today with client-side counting (except move the pixel from before to after the third-party markup).

[jgwi...@vindicotech.com]

B, 

The bURL is meant to be a billable event notification (as opposed to Auction Won notification).  The event that is billable can be anything that is agreed upon by the Supplier & Buyer in a contract (w/ discrepancy clause languange).  So, yes, bURL could be fired on a viewability event.  Of course the "custom" implementation of a "viewability" bURL would be different than a simple "ad markup delivered" bURL.  You'd have to convince the Supplier to do the dev work...

J