Can FLEDGE provide a mechanism for sellers to learn the association between the top-level renderUrls and adComponentRenderUrls server-side? This can be crucial for sellers to retain an acceptable level of enforcement fidelity without needing to drastically scale their ads scanning systems immediately.

The number of ad components or products a buyer might want to use in FLEDGE auctions can be very large. It is not uncommon for a buyer’s product catalog to be multiple orders of magnitude larger than the number of ad templates or creatives they traffic. Scanning all the ad components – product catalog items a buyer might use – in a FLEDGE auction requires significant scaling of the seller's scanning infrastructure and could be challenging to accomplish before the start of FLEDGE origin trials.

Buyers and sellers can agree on the granularity of the ad template renderUrls. For instance a renderUrl can represent an advertiser, advertiser’s campaign, line item or some similar ad hierarchy concept. Knowing the association between the top-level renderUrls and adComponentRenderUrls can enable sellers to scan a representative set of ad components, aggregate their metadata and enforce policies and publisher controls at the level of an overall top-level creative (renderUrl), thus avoiding the need to immediately scale ad scanning infrastructure to support very large buyer product catalogs. Let’s assume N adComponentRenderUrls were used with a given campaign or line item identified by a renderUrl across many losing and winning FLEDGE in-browser auction bids and this information was made available to the seller. The seller could then scan a representative sample of M out of the N adComponentRenderUrls and associate ad scanning results with the top-level renderUrl (representing advertiser’s campaign, line item or some similar ad hierarchy concept). Sellers can pick M depending on their tradeoff between ad scanning costs and desired scan coverage. Subsequently, during the in-browser auctions, the seller could enforce policies and publisher controls based on the aggregated ad scanning results associated with the top-level renderUrl.

Another potential use case for sellers to know the association between renderUrls and adComponentRenderUrls server-side could be to consider the interaction between the top-level renderUrl and one or more of its components. A seller might want to know whether the combination of a renderUrl and its constituent adComponents causes the overall shown ad to become undesirable or more sensitive.

There are potentially 3 moments at which the association between renderUrls and adComponentRenderUrls can be made known to sellers:

• In trustedScoringSignals request to seller trusted server
• reportLoss
• reportResult
  As described in Losing bids aggregated reporting for sellers #218 , reporting on lost bids renders itself as a good source for scanning ads that were ineligible to participate in auctions due to reasons such as ad metadata from sellers scanning system being unavailable. In addition to the top-level renderUrl, making the adComponentRenderUrls available in the lost bids reporting will enable scanning and enforcement of policies and publisher controls when buyers use ads composed of multiple pieces.