When a buyer (DSP) participates in the auction, the bid is often on a CPM basis: how much would the buyer pay per 1000 impressions? The buyer, however, often charges advertisers per click (CPC), per conversion (CPA) or on the basis of another event that may or may not occur after the impression is viewed.

Thus, the bid returned by generateBid() to participate in the auction is often not the same value as the advertiser click or conversion cost used by DSP for CPC or CPA billing. Converting the bid into advertiser click or conversion cost often requires values computed within generateBid(). The problem is that FLEDGE does not provide a mechanism for reporting values computed inside generateBid(), except for the bid itself.

This requires a DSP to compute advertiser click or conversion cost on the server from the reported data, often recomputing the same values that were computed within generateBid(). There are cases when recomputation could produce different results. For example if the advertiser click or conversion cost computation logic in generateBid() and on the server become out of sync, or if the versions of the models used in computing the bid and advertiser click or conversion cost on the client, become out of sync from those used on the server. There are solutions to these problems, such as using data version headers. Nevertheless, even when data version headers are used, CPC or CPA billing with FLEDGE remains complicated and error prone. Furthermore, server-side recomputation becomes impossible if user specific browser signals such as joinCount, bidCount or prevWins are used in the bid computation.

This in turn is a gap in FLEDGE in that while FLEDGE provides joinCount, bidCount or prevWins signals to the bidding functions, it does not provide the mechanism for reporting advertiser click or conversion cost without which using the signals for FLEDGE bidding is impossible.

Let’s consider what happens if the advertiser click or conversion cost computed on the client uses signals available on the client only, such as joinCount or bidCount (passed to generateBid() via browserSignals). Because neither joinCount nor bidCount are available on the server, recomputing advertiser click or conversion cost changes from being merely complicated to being very difficult or impossible. This, in turn, makes accurate advertiser CPC or CPA billing very difficult or impossible.

To solve this problem, we propose that generateBid() returns an additional value, which is adCost:

generateBid(interestGroup, auctionSignals, perBuyerSignals, trustedBiddingSignals, browserSignals) {
  ...
  return {'ad': adObject,
          'bid': bidValue,
          'adCost': adCost,
          'render': renderUrl,
          'adComponents': [adComponent1, adComponent2, ...],
          'allowComponentAuction': false};
}

adCost will be passed by the browser to reportWin() as part of the browserSignals. This will allow the buyer to report advertiser click or conversion cost accurately, and bill advertisers CPC or CPA accurately, even in the case when advertiser click or conversion cost computation uses signals available on the client only.

adCost signal thus passed to reportWin() is a privacy risk. To decrease the risk, the number of bits available as adCost could be limited.