In relationships between buyers (DSPs) and sellers (SSPs), impressions for the same creative may transact in different currencies and on separate invoices due to business, taxation and other reasons. In today’s RTB integrations, buyers can use the bid response fields to specify how their spend should be attributed; for example, OpenRTB BidResponse.seatbid.seat field allows to attribute an impression to a specific seat on the exchange and BidResponse.cur allows to specify the bid currency.

The same creative can also be transacted via different DSP campaigns or line items, each with its own budget. DSPs need a way to track spend and enforce budgets separately for each such campaign or line item, even when one creative is shared across multiple campaigns.

In the current FLEDGE specification, a seller and a buyer can only access basic information about a rendered ad in their reporting functions, such as the render_url and ad_render_fingerprint, which may not be sufficient for attributing transacted impressions to different entities used for breaking down spend (DSP seats and customers, line items, invoices, currencies). While one could theoretically encode these dimensions (currency, line item, seat ID…) into render_url, that seems cumbersome and conflates the two orthogonal concerns of creative hosting and billing, budgeting and reporting.

Is it possible to add a way for buyers to specify custom reporting fields into FLEDGE that are made available to the buyer and seller reporting functions, including the temporary, event-level reporting mechanism? Perhaps buyers could specify those fields as part of the interest group object or an individual ad at the time an interest group is joined/updated, or, alternatively, return from the generate_bid.

Similar to the FLEDGE-proposed k-anonymity constraints on the render_url, a browser can require that the custom reporting field(s) need to pass a certain minimum audience size before either allowing an ad to win, or, if there is tolerance for those fields to be sometimes missing, before the reporting field(s) can be made available to the buyer’s and seller’s reporting functions.