search

prebid / prebid-universal-creative

Apache License 2.0
43 stars 69 forks source link

Align the PUC for mobile and AMP #208

Open bretg opened 1 year ago

bretg commented 1 year ago

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

  1. Publishers should be able to utilize the PUC across web, app, and AMP
  2. 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
  3. Non-safeframe support is required for web and app. (AMP always requires safeframes)
  4. 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.
  5. 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:

Web Safeframe Banners

For Web Safeframe Banners, the PUC must:

  1. Call PostMessage to get the winning ad from Prebid.js
  2. Create an iframe of the appropriate size and displays the winning ad within it

AMP and Mobile

For AMP and Mobile, the PUC must:

  1. Update the size of the iframe to the size of the winning ad.
  2. Retrieve the body of the creative from Prebid Cache based on the UUID
  3. If the ‘burl’ parameter is present, create a tracking pixel. Includes special support for triggering the viewable billing url for mobile MRAID creatives.
  4. If the ‘nurl’ parameter is present, create the appropriate HTML to fire the notice URL.
  5. If the ‘wurl’ parameter is present, create a tracking pixel. This is needed for Programmatic Guaranteed support.
  6. Resolve any ${AUCTION_PRICE} macro in the creative body.

Native

For Native, the PUC must:

  1. Retrieve the native attributes from the winning ad.
  2. Coordinate the rendering of the native ad using the template method specified by the publisher.
musikele commented 1 year ago

@bretg

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?