You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There's confusion and misalignment over how publishers are supposed to use the PUC across different channels. e.g. mobile app developers are supposed to use mobile.js or creative.js instead of the newest HB_FORMAT.js innovation.
Also it's unclear if native rendering works for AMP or app. Probably doesn't.
Here's a cut at the requirements.
High Level Requirements
Publishers should be able to utilize the PUC across web, app, and AMP
Publishers should be able to utilize the PUC within safeframes for all of the following mediatypes: banner, outstream video, native, interstitial banner and interstitial outstream
Non-safeframe support is required for web and app. (AMP always requires safeframes)
Publishers should be able to set up one set of line items that works across all channels and all mediatypes listed above. Note that instream video is expected to be a separate set of line items.
For scenarios where the publisher wants to mix safeframes and non-safeframes, it should be possible to employ creative-level targeting for ad servers that support it. i.e. there should be a key-value-pair (e.g. hb_channel) that allows them to know what channel this bid is coming from: web/amp/app.
#5 is a newly proposed requirement that might go a way towards solving some of the edge cases straining us. By utilizing creative-level targeting against hb_channel, publishers could create one set of line items with different sets of creatives:
if hb_channel=amp, make sure the creative is safeframes
if hb_channel=app, make sure the creative refers to moble.js
etc
Web Safeframe Banners
For Web Safeframe Banners, the PUC must:
Call PostMessage to get the winning ad from Prebid.js
Create an iframe of the appropriate size and displays the winning ad within it
AMP and Mobile
For AMP and Mobile, the PUC must:
Update the size of the iframe to the size of the winning ad.
Retrieve the body of the creative from Prebid Cache based on the UUID
If the ‘burl’ parameter is present, create a tracking pixel. Includes special support for triggering the viewable billing url for mobile MRAID creatives.
If the ‘nurl’ parameter is present, create the appropriate HTML to fire the notice URL.
If the ‘wurl’ parameter is present, create a tracking pixel. This is needed for Programmatic Guaranteed support.
Resolve any ${AUCTION_PRICE} macro in the creative body.
Native
For Native, the PUC must:
Retrieve the native attributes from the winning ad.
Coordinate the rendering of the native ad using the template method specified by the publisher.
The text was updated successfully, but these errors were encountered:
going to write what I know about the puc currently.
Files mobile.js and amp.jsare now identical. In the previous version of the PUC too, those two were following the same paths in the code. The only difference is that, when mobile environment is detected, mraid is called and a markup is built. Currently, the same files (either mobile.js and amp.js) are able to run both. I can explain better why previous and current versions are equivalent, if needed.
Regarding the section "Web Safeframe Banners", the point:
Create an iframe of the appropriate size and displays the winning ad within it
I don't think this applies here. the PUC cannot build iframes. It is already in an iframe, created by the adserver. the PUC is loaded inside the given iframe. Maybe there's something I didn't understand correctly here?
There's confusion and misalignment over how publishers are supposed to use the PUC across different channels. e.g. mobile app developers are supposed to use
mobile.js
orcreative.js
instead of the newest HB_FORMAT.js innovation.Also it's unclear if native rendering works for AMP or app. Probably doesn't.
Here's a cut at the requirements.
High Level Requirements
#5 is a newly proposed requirement that might go a way towards solving some of the edge cases straining us. By utilizing creative-level targeting against hb_channel, publishers could create one set of line items with different sets of creatives:
Web Safeframe Banners
For Web Safeframe Banners, the PUC must:
AMP and Mobile
For AMP and Mobile, the PUC must:
Native
For Native, the PUC must:
The text was updated successfully, but these errors were encountered: