Convention for Page Position

[bretg]

Type of issue

Convention

Description

Similar to First Party Data and Video Parameters, many bidder accept page position as bidder-specific parameters. Publishers need to pass the same information to each bidder, but often with different values for each bidder.

• Rubicon requires 'position' to be either 'atf' or 'btf'.
• AppNexus requires 'position' to be either 'above', 'below', or 'unknown'
• Conversant requires 'position' to be values from 0-7 corresponding to the OpenRTB values

Proposal

Prebid.js should adopt a convention for publishers to place 'position' in AdUnit.mediaType.banner.pos and AdUnit.mediaType.video.pos

The values are aligned with OpenRTB 2.5:

Value	Description
0	Unknown (default)
1	Above the Fold
3	Below the Fold
4	Header
5	Footer
6	Sidebar
7	Full Screen

Requirements

1. As an AdUnit-specific value, 'position' is not subject to First Party Data permissioning
2. PBJS bid adapters should look for this value in the mediaTypes.mediaTypes objects
3. The pbsBidAdapter should pass this value as imp[].banner.pos and imp[].video.pos
4. PBJS should validate the type of pos: if it's not an integer, remove the attribute entirely, fire an AUCTION_DEBUG event, and log a console warning

Timeline

If approved, Prebid.org documentation and the Prebid Server bid adapter will be updated immediately. Bid Adapters will have until Prebid 5.0 (timeline TBD) to be able to read from mediaType.banner.pos and mediaType.video.pos and map values to their endpoint requirements.

[gglas]

@bretg Approved, let's move forward with next steps.

[patmmccann]

@bretg do we need to reopen this for the adapter changes?

[patmmccann]

@bretg should the rubicon adapter copy p_pos to tg_i.pos if it exists? We're being asked to double set.

[patmmccann]

Here is an attempt at a list of adapters that need modification:
Conversant

Prebid.js/modules/conversantBidAdapter.js

Line 104 in d4ad23f

copyOptProperty(bid.params.position, banner, 'pos');

Gamoshi md file and

Prebid.js/modules/gamoshiBidAdapter.js

Line 70 in d4ad23f

(!bid.params['adpos'] || utils.isNumber(bid.params['adpos'])) &&

Kobler

Prebid.js/modules/koblerBidAdapter.js

Line 192 in 180ddaf

return parseInt(validBidRequest.params.position) || 0;

Prebid.js/modules/koblerBidAdapter.js

Line 134 in 180ddaf

pos: getPosition(validBidRequest)

Waardex

Prebid.js/modules/waardexBidAdapter.js

Line 99 in 412277f

position: parseInt(validBidRequest.params.position) || 1,

pixfuture

Prebid.js/modules/pixfutureBidAdapter.js

Line 203 in e39cb75

tag.position = {'above': 1, 'below': 2}[bid.params.position] || 0;

Smilewanted

Prebid.js/modules/smilewantedBidAdapter.js

Line 40 in caa329a

positionType: bid.params.positionType || '',

adRelevantis

Prebid.js/modules/adrelevantisBidAdapter.js

Line 431 in d4ad23f

if (bid.params.position) {

SpotX

Prebid.js/modules/spotxBidAdapter.js

Line 183 in d4ad23f

spotxReq.video.ext.pos = utils.getBidIdParameter('position', bid.params);

Appnexus

Prebid.js/modules/appnexusBidAdapter.js

Line 730 in 412277f

tag.position = { 'above': 1, 'below': 2 }[bid.params.position] || 0;

The oneVideo module is an example of how to do this according to the new spec.

[patmmccann]

@acsbendi https://github.com/prebid/prebid.github.io/blob/master/dev-docs/bidders/kobler.md indicates position is not the same as the ortb2 param. Would you consider renaming it? Some might find that confusing. Also, removing you from the list of adapters to fix.

[acsbendi]

@patmmccann I've already opened a PR to remove that parameter completely :D prebid/prebid.github.io#3794

We originally used to differentiate between repeated placements (e.g. when the article is long and the same placement is used multiple times between paragraphs) but we stopped using it as it takes too much effort to maintain this information.

[patmmccann]

how fortuitous, ty

[patmmccann]

Conversant appears fixed here ; fyi @pycnvr

Prebid.js/modules/conversantBidAdapter.js

Line 80 in 2870089

mergeDeep(imp, bid.ortb2Imp);

[patmmccann]

Positiontype parameter is not documented in smilewanted adapter, we can't be sure what it means

[pycnvr]

@patmmccann Thanks for tagging. It seems that adapters should be picking up values from mediaTypes.video.pos and mediaTypes.banner.pos. The line above in Conversant adapter only work for first party data. If that sounds right, I'll add it to our sprint. Thanks.