report_win: render_url & PLTD

[jonasz]

The reporting functions, report_win and report_result, receive render_url as one of the inputs:

browser_signals = {
  'top_window_hostname': 'www.example-publisher.com',
  'interest_group_owner': 'www.example-dsp.com',
  'interest_group_name': 'womens-running-shoes',
  'render_url': 'https://cdn.com/url-of-winning-creative.wbn',
  'ad_render_fingerprint': 'M0rNy1D5RVowjnpa',
  'bid:' bid_value,
  'desirability': desirabilityScoreForWinningAd,
}

The explainer mentions that:

The render_url can always be included since it has already passed a k-anonymity check, for example, but the winning interest_group_name will only be present if it has exceeded the threshold which gates daily updates.

I was wondering, what'd be passed in place of render_url in case of "Ads Composed of Multiple Pieces" (section 3.4)?

If it is not feasible to include the entire list of render_urls, perhaps generate_bid could specify which one to include?

[suprajasekhar]

+1 to @jonasz's question. We are wondering what information will be available within report_result in case of "Ads Composed of Multiple Pieces". This impact's sellers' ability to scan ad components and meaningfully enforce policy and publisher controls.

For instance, sellers could scan products using adComponentRenderUrls provided within report_result. The creative metadata of ad components used within a top-level renderUrl can be aggregated, stored in trustedScoringSignals and used for enforcing policies and publisher controls subsequently. Such aggregation and enforcement at creative-level may be preferable than scanning every single ad components owned by a buyer due to scalability constraints. The entire catalog of ad components that may be used in FLEDGE auctions by a buyer can be large and scaling scanning systems to support the high volume can be challenging.