Measuring Viewability without GPT (BID_VIEWABLE event)

[jsut]

Type of issue

feature request / sanity / usefulness inquiry

Description

Prebid has a module that provides an event, BID_VIEWABLE, that will fire when a rendered bid becomes viewable. It only works with GAM/GPT, and relies on their to know when to emit the event.

What I am wondering is if it might be useful or generally desirable to have an alternative to this module that would do some thing on the clientside after pbjs.renderAd was called that could result in an alternative way to generate a signal that an ad was viewable. I have been playing around with intersectionObserver, and it seems like it could be fairly easy to leverage it to get reasonable proxy that people could use as a first party measure for viewability.

I was playing with getting this working outside of prebid (you can see my experiment here: https://test.kabob.ca/), but I wonder if this might be generally useful to people as a module.

[patmmccann]

Hard to say what the bid_viewable event is useful for now; seems to be only used by pubmatic managed publishers so I would ask them, but yes not relying on gam would be a great alternative. To clarify, I can think of several uses for it, but i am not aware of them being in use.

[jsut]

I personally want it so we can collect first party viewability data which will allow us to experiment on different things (timeouts, lazy load logic, who knows what else) and tune for viewability, rather than revenue, or fill, or cpm.

[patmmccann]

Sounds reasonable. I think there have been some concerns with Prebid providing any sort of warranty on a viewable method and this technique ( https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API/Timing_element_visibility ) is subject to a lot of false negatives when scripts bust ads out of frames and render them in an unexpected place. I think this method has value though, as long as sufficient disclaimers are in place.

[jsut]

The disclaimers about the data and it's validity would definitely need to be large and bold. I think having it as a module, as opposed to in prebid.js (the file, not the project) might offer some insulation there, but i'm not sure.

[pm-harshad-mane]

Hello @jsut ,

I had added the bidViewability module in PrebidJS. I liked your approach.

GPT provides a nice lazy-loading API https://developers.google.com/publisher-tag/samples/lazy-loading
But GPT lazy loading does not let us run PrebidAuction before rendering ad-slots.
If we could build something similar to GPT lazy-loading but with the ability to execute custom code then it will be great, then a publisher will be able to run Prebid, TAM, and some custom logic. This can help boost the viewability of ads and hence CPMs.

About click tracking, you are rendering ads in custom safe-frames and I do not see GAM is in the picture here.
Can we add click tracking on safe-frames created by GAM/GPT?

[jsut]

@pm-harshad-mane, the implementation I linked to doesn't use an ad server at all, so it's admittedly pretty weird, but it's based on the implementation we use at work. The click tracking code there in particular was more me wondering if doing that would even work at all, as opposed to something that I think is a good idea.

Adding a lazy loading interface like GPT's seems like something that probably shouldn't be inside prebid itself to me, but i can't claim to really have any idea what I'm talking about. I suppose there might be a way to turn my intersection observer lazyloader thing into something more generic, but that's probably something completely different from the viewable event.

[pm-harshad-mane]

@jsut Yup, lazy loader should not be part of Prebid (a module).
Thank you for sharing your POC.

[jsut]

I spent some time looking into how something like this might work, and it seems like the way to approach this might be to emit a new event after an ad is rendered successfully. Prebid already emits a render failure, but it doesn't emit anything on success. That event would include possibly the document object the ad was rendered into, or perhaps the parent element, which the module could then set up an intersectionObserver on, or otherwise manipulate. Does this seem like a reasonable approach?

[jsut]

@patmmccann @pm-harshad-mane I had some time to fool around with this tonight. creating a PR seems quite premature, but if either or both of you could have a look at jsut@ce73bb7 and tell me if I'm going about this in a sane way or not it would be appreciated.

[pm-harshad-mane]

@jsut since bidViewabilityIO Module is released, can we close the issue ?