InSkin Bidder Adapter

[jgrimes]

Type of change

• New bidder adapter

Description of change

Adds a new bidder adapter for InSkin Media.

• test parameters for validating bids

{
  bidder: 'inskin',
  params: {
    networkId: '9874',
    siteId: '983808'
  }
}

[mike-chowla]

I have two concerns about this adapter and whether how it operates conforms to Prebid.org rules:

1. The rendered ad is a page take over. The adapter accomplishes this by placing a message handler at the window context and then when the ad is rendered, it posts a message to that handler so it can run at the window context. This completely ignores the ad unit size as well as deliberately escaping the frame of the ad unit. Even in the context of their only being one ad unit on the page, this feels problematic to me.

Here' the hello_world test page with the test ad unit:

Notice the "Prebid.js Test" and "Div-1" text on the page has been completely obscured.

2. If there are multiple ad units on the page, the InSkin ad renders those other units un-viewable which interferes with the other bidders ability to deliver ads for other ad units. With multiple units, it seems roadblock / takeover functionality would be needed in Prebid.js so the the takeover unit needs to outbid all the slots on the page. Issue Takeovers.. #84 is the only reference I could find to takeover support but not it doesn't look like anything of that ilk was ever implemented.

@mkendall07 Can you comment as to whether page takeovers are permissible?

[richardStrang]

Just to give some context (I head up the integrations team at Inskin)

The Inskin takeover format is only run on partner publisher sites that have been integrated with the format. This integration ensures that no page-content or other advertising ad units are obscured by the skin, this is bespoke to each publisher. Also, the same format can be served out of multiple sized ad units depending on the publisher.

If you have any questions about this please let me know.

[gramorris]

Apologies if my input is unwelcome but as an InSkin client I've been keeping an eye on this adapter, so...

There are already adapters in PreBid that deliver this behaviour specifically and others that escape the ad unit frame. There are also agencies delivering this behaviour through aliasing adapters such as AppNexus.

At some point, and especially within the context of Better Ads, publishers have to be responsible for the delivery of ads on their site. The concerns raised can all be resolved by the publisher and if they don't then they can be worried about the fire and fury coming their way via Chrome.

[mike-chowla]

Aside from policy question as to takeovers and escaping the ad frame, the code looks fine.

[mkendall07]

thanks for pointing this out Mike. I don't think we've ever had a policy on this. It's something to think about but for now I think it's ok.

[richardStrang]

Docs - prebid/prebid.github.io#548

[gramorris]

In the absence of anywhere else to put it @mkendall07....

The issue @mike-chowla raised about the size of the unit/frame is pertinent and possibly could be something that falls within the remit of Prebid to solve. The current situation as we experienced is that as Mike points out the vendor supplies the size of the creative, Prebid respects this and passes it in to DFP which then resizes the slot resulting in a large empty ad slot with an out of slot unit somewhere else.

IMO the behaviour as it is, is correct and valid. I'd rather the vendor continuing to supply the correct dimensions of the creative rather than sending through a false 0x0 or 1x1. Our current solution, knowing which vendors are sending these creatives, is to trigger a further callback on the Prebid bidWon callback and hiding the original ad slot. It's possible this could be done within Prebid if vendors also sent back an outOfSlot flag (true|false) with the bids.

The issue with the obscuring of other ads I do believe falls within the remit of the publisher. We do have in place frequency capping within DFP for higher impact creatives but I think determining that cap and also what is a higher impact creative would be difficult to implement centrally, especially with the creative changes going on around BetterAds, but also wouldn't be welcome from a publishers perspective.

[benjaminclot]

Shouldn't these types of formats (skins, footers, interstitials...), like outstream, be new ad types and use specific renderers?