Proposal: Viewability Signaling via Open RTB (3.0)

[sergio...@inmobi.com]

Hi everybody,

In-app viewability measurement differs from “desktop” in that measurement is performed by a vendor SDK, which must be integrated into an app in advance in order to issue MRC accreditation. Many buyers are interested in bidding only on inventory which is enabled for their own preferred viewability vendor (via SDK). As a result the set of integrated viewability vendors is an interesting and valuable data point to exchange pre-bid.

InMobi has worked with Rubicon Project on a proposal to solve this issue via Open RTB extension.

Given the big interest this approach received among partners, we thought it would make a lot of sense to propose this to the forum and add it to the official 3.0 specs.

Proposal: https://docs.google.com/document/d/17R0_nlK0gSH8bVphuC1AAcJN0dJghJwTo2YVucSElWc/edit?usp=sharing

Looking forward to your feedbacks!

Thanks,

Sergio

[james....@blis.com]

What is the intention behind the prioritisation of the vendors?
If we serve a creative that has multiple vendors that are listed as being supported in the original bid request, we'd expect them all to work.
The lazy-loading of vendors libraries is interesting; if that vendor's library isn't loaded why would it be listed in the bid request?
What happens if this library fails to load?

James

[Sergio Serra]

Thanks for the feedback, James.

Absolutely, there should not be any concept of prioritization and all the vendors are expected to equally work. This was legacy from the first draft of the proposal. I removed that line.

As you know, third party viewability trackers do not work only from JS side, but also from SDK. They create a bridge between their JS and native component to measure the viewability in true independent sense. Thus, in order to make third party viewability work, JS and SDK need to communicate. This is why SDK needs to be initialized and this can happen only when the supplier gets the viewability vendor information from bid response.

An other option would be parsing the whole adm, but as you would appreciate, this is very challenging and stochastic (especially when it comes to display). This is why we came up with a cleaner approach on response path as well.

With that said, third party JS could be loaded lazily (again, it would depend on third party implementation).

Please, let me know if you need further details.

Sergio

Sergio Serra

Product Management, Brand & Programmatic

M +44 (0) 7990 752541 | Skype sergio.serra.it

www.inmobi.com

This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Blis Ltd, a company registered in England and Wales with registered number 06455773. Its registered office is 7th Floor, 10 Bloomsbury Way, WC1A 2SL, United Kingdom.

If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

--
You received this message because you are subscribed to a topic in the Google Groups "openrtb-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openrtb-dev/b2XzouCjhzw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openrtb-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

_____________________________________________________________

The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution or taking any action in reliance on the contents of this information is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by responding to this email and then delete it from your system. The firm is neither liable for the proper and complete transmission of the information contained in this communication nor for any delay in its receipt.

[Curt Larson]

The existing plan in 3.0 is to adopt the Events object from native 1.2 into the broader spec, so we can make tweaks based on that of course.

[sergio...@inmobi.com]

This is potentially a good compromise (the assumption is to use it for both request and response path). 

However, here are some thoughts:

- On the request side, for each supported event we should have an array of methods that reports the id of each vendor that supports that event. Now, the question is should the exchange really maintain this mapping? Or should this rather be an expectation from the buyer to the viewability vendor? In an ideal scenario, an exchange should just declare that a specific SDK is available and (hence) the given vendor can be used for tracking. Anything more granular (eg. viewable-mrc50, viewable-mrc100, viewable-video50) should not even be of a concern for the exchange. 

- On the response side, again, would the exchange need to know what event the bidder is after? Keep in mind, I am only referring to viewability context here; for other events this might make sense. If this boils down to billing purposes, then it gets even more complicated and 'event' by itself would not be able to solve for this.

Also, the description of url/js here is quite blurred: "URL provided will be inserted as a 1x1 pixel {as a js tag} at the time of the event." What is this for? Is the exchange supposed to fire a pixel once the event (eg. viewable-video50) happen? If so, are all the vendors going to expose a callback for the exchanges? Why should even the exchange be in charge of this?

On the other hand, if its scope is more around handing over a JS resource to the exchange in order to let the vendor track, then - do we even need this? For display, the javascript tracker can just be sent via adm; for VAST video, it can easily live within adverification node.

In a nutshell, my biggest concern is that we are overcomplicating viewability signaling from an exchange perspective. I would rather have an easy field that simply signals what vendor SDK has been bundled by the supplier (which is what 'viewabilityvendors' does). Any further granularity should be pitched and negotiated by each viewability vendor. 

Does the forum believe the exchange should rather maintain such mapping for each vendor and signal everything in request? 

Also, today I am seeing just 3 proposed viewability events, what if tomorrow we get 10 of them? Request size would be something else to keep in mind, not to mention the fact that each exchange might come up with its own id in order to support the new event type. Open RTB 3.0 should standardize the way of representing viewability, given the extreme granularity of events obj, there is a concrete risk each exchange will come up with its own interpretation.

Viewability is now becoming a commodity - should not it deserve a dedicated/distinct field in request?

[Curt Larson]

Thanks for the thorough thinking Sergio.  The basic thing that we are working on here is moving towards a world where the buyer cannot just send any javascript they want over with the ad.  The new display standard for 3.0 will support native, amp, and possibly dynamic as the preferred formats, with the traditional display ADM tech as legacy fallback case.  In all these new modern formats, random javascript is not supported.

Thus, in terms of events, we are looking to move more towards a world where the supply side handles event tracking, and fires events back at the demand side as they happen.  This is quite analogous to video where the quartile events are fired as they happen based on the player the supply side is running.f

Curt

[james....@blis.com]

Interesting, who is 'we' in this case?

[Curt Larson]

In this case the 'we' would be the RTB 3.0 working group and commit group.

Curt

This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Blis Ltd, a company registered in England and Wales with registered number 06455773. Its registered office is 7th Floor, 10 Bloomsbury Way, WC1A 2SL, United Kingdom.

If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

--
You received this message because you are subscribed to a topic in the Google Groups "openrtb-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/openrtb-dev/b2XzouCjhzw/unsubscribe.
To unsubscribe from this group and all its topics, send an email to openrtb-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Curt Larson - sharethrough - 415-781-9883 mobile -  cla...@sharethrough.com