Native mediatype: Track Visible impression

guiann commented 3 years ago

Type of issue

Feature request

Description

Today in a native bid we can give prebid trackings for click and impression native.clickTrackers native.impressionTrackers Is it possible to give some pixel urls to be called on visible impression ?

Expected results

The array of given urls should be called when the ad is 50% visible to the user.

bretg commented 3 years ago

@osazos - do you think this request could be fulfilled with your brand new native.ext change?

1) add mediaTypes.native.ext.viewTrackers to the adunit 2) Add code in your native template to detect the viewable status and fire when appropriate

bretg commented 3 years ago

This was discussed in the Prebid.js meeting today. There was a suggestion that instead of forcing everyone to come up with their own "ext" assets, we should consider a convention.

Honestly I'm out of my league when it comes to native, but did spend a few mins with the Native 1.2 standard and came up with a straw proposal you can all beat up.

Allow the publisher to define eventtrackers[] as in openrtb, along with the type and methods. Several things fuzzy to me -- should pubs be able to define their own labels, or should we just standardize? Should these be under eventtrackers or just at the same level as assets? I've been trying to align PBJS more with OpenRTB which places them under eventtrackers.

pbjs.addAdUnits({
    code: slot.code,
    mediaTypes: {
        native: {
        sendTargetingKeys: false,
            eventtrackers: [{
                impression_img: { // results show up at render time as hb_native_impression_img
                    type: 1,
                    methods: [1]
                },
                impression_js: {  // results show up at render time as hb_native_impression_js
                    type: 1,
                    methods: [2]
                },
                viewable50_img: {  // results show up at render time as hb_native_viewable50_img
                    type: 2,
                    methods: [1]
                },
                viewable100_img: {  // results show up at render time as hb_native_viewable100_img
                    type: 3,
                    methods: [1]
                }
            }],
            image: {...},   // anyone know why weren't these placed under an assets object like in the 1.2 spec?
            ...

But how exactly this translates to PBJS-core and adapter work is not clear to me.

guiann commented 3 years ago

From what I know, publishers cannot define custom trackers. Bidder adapter are requested to fill up those standard event trackers array: native.clickTrackers native.impressionTrackers native.javascriptTrackers

Without any setup from the publisher.

So I was expecting a standard tracker array for visible impression. The same for every bidder adapters. (visible imp 50 and visible imp 100 can both be useful though.)

osazos commented 3 years ago

@bretg, I totally missed your mention.

The ext field has been though to allow native non standard keys to be passed to the native template. The value of these keys is set by the adapter itself regarding the data received in bidResponse. As I understand here, @guiann wants to add tracking url (values) publisher side, in addition of data send in the response.

There are two things here:

First update Prebid Native code to properly handle missing viewability trackers and then update universal creative to add the capability to dispatch viewability events.
Extends the Prebid.js Native behavior to allow publishers to add global trackers which would be merged with the ones get from the native bid response

@bretg, your second comment open the door for improvements for Native, that would be great.

bretg commented 3 years ago

I'm not thrilled with getting the PUC involved in deciding viewability. Why can't that be left to the native template code?

Here's my understanding of how native creatives are rendered:

Prebid.js is just a data path that needs to pass a bunch of native parameters from the bidder the code that renders the ad.
The only job of the PUC is to resolve macros in the template by grabbing the values from PBJS.

So the proposal here is quite simple:

1) add 4 new macros that can be resolved in the template code:

hb_native_impression_img

hb_native_impression_js

hb_native_viewable50_img

hb_native_viewable100_img

2) Define how Bid adapters can set these values. (will leave it to an engineer to decide this)

3) The publisher writes the creative template to determine when to fire these pixels. Here's an example template:

adTemplate: "<div class=\"sponsored-post\"><div class=\"thumbnail\"><\/div><div class=\"content\">
<h1> <a href=\"##hb_native_linkurl##\" target=\"_blank\" class=\"pb-click\">##hb_native_title##<\/a><\/h1>
<p>##hb_native_body##<\/p> <div class=\"attribution\"> ##hb_native_brand## <\/div> <\/div>
<script type="text/javascript" src="##hb_native_impression_js##"></script>
<script type="text/javascript">INSERT VIEWABILITY LOGIC HERE THEN FIRE ##hb_native_viewable50_img## OR ##hb_native_viewable100_img## WHEN APPROPRIATE</script><\/div>"

4) The PUC simply resolves the ##macros##

I lean against coding the PUC to any given viewability algorithm. I'm ok putting straw code on docs.prebid.org with an example of how pubs can do this, but my gut feeling is there must be a dozen different ways of determining "viewable" and Prebid.org should not get involved in that mess -- pubs should code whatever method of viewability they prefer. If there's a cross-browser viewability pseudo-standard that's not bloated, I guess it would be ok to offer as a default.

patmmccann commented 2 years ago

For reference to any readers / commentors, https://www.iab.com/wp-content/uploads/2018/03/OpenRTB-Native-Ads-Specification-Final-1.2.pdf 5.8 and 7.6 are relevant

patmmccann commented 1 year ago

should we take the track we took in #9640 ? We could completely rely on a publisher signal, or on page library signal.

prebid / Prebid.js