Proposal: simplification of rendering logic

[dgirardi]

PUC, in its attempt to be universal and perpetually backwards-compatible, has accumulated a considerable amount of complexity. Despite that, it cannot claim to be universal in any useful sense; creatives for different use cases need to be set up differently, with the only point they share in common being a script URL (and efforts to separate those as well).

Some publishers report a significant revenue drop with the use of PUC, and prefer to use alternatives - but that's not straightforward for native, for which we provide an implementation only through PUC.

Proposal

• Move native rendering logic into Prebid.js and make it available through renderAd. This means dropping the option to define the native template in GAM; instead, it should be provided as adUnit.native.adTemplate. The logic to find the appropriate native assets and interpolating them would be managed by Prebid in a similar way to how it now deals with banner ad macros.
• Make rendered native ads available through the same cross-frame channel as banner ads. With the above, the creative could be truly agnostic to whether it's dealing with one or the other - it would ideally just ask Prebid for some markup and drop it on the page.
• Make the PUC-less example available as a standalone script, as the "new PUC", and have it be the preferred way to render cross-domain ads. It should stay small enough, and require few enough updates, that publishers can still choose to embed it in their creatives to improve revenue.

Open questions

• Native custom rendering: the current API for custom renderers is not compatible with them being run on the Prebid.js window (because it asks to define a window.renderAd function). It's also not clear if custom renderers as standalone scripts still make sense in a world where rendering is managed and configured directly by Prebid.

See also

prebid/Prebid.js#8358
#187