FLEDGE: currency of the bid

Hello

after seeing issue #165 we wanted to ask questions regarding the currency we will bid with.

Publisher will ask participants to bid in a given currency. How does FLEDGE implement this transfer of information, ie how will the bidding function know what kind of currency the publisher is expecting? It seems that there needs to be a way of "standardizing" this in the FLEDGE Api, as the bidding function can't know ahead of time the exact list of publishers it will be called on, and so it can't know the list of currencies each publisher will require
If we assume that the publisher sends the info of the required currency to the bidding function, how is the bidding function supposed to handle this info? Suppose for instance that the bidding logic computes a bid in EUR and the publisher asks us a bidding value in USD. The bidding logic has to perform this EUR -> USD conversion. How in practice would it do it ? Storing fixed exchange rate in the bidding function is not really ideal as it will get stale. Another possibility we see is to store an up-to-date currency info in the key-value server, so that we will retrieve an up-to-date value during bidding. What's your take on this?

thanks!

Adding the responsibility for accurate currency conversion rates to the browser might be tricky and having each buyer/IG ship its own currency conversion rates to the client would be inefficient.

I'd recommend that the buyer returns a currency along with the bid and that the publisher / SSP uses its own conversion rates to normalize in the scoring function. It's possible the publisher would need access to a conversion service, but its also possible that the scoring function could be shipped with good-enough conversion rates on a daily basis.

Thanks for bringing this up on today's call, and pardon my ignorance as I try to fill out my understanding of the problem.

How do things work in RTB and in on-device header bidding today? In particular, does the auction specify the currency (or short list of currencies), and then each bidder has the obligation to submit in the currency permitted, perhaps looking up real-time conversion rates? Or do DSPs submit bids in many currencies, which are somehow normalized by the SSP?

Real-time data is available to the bidding and scoring functions, either through the config object passed into navigator.runAdAuction() (under the control of the seller) or through the real-time request to the trusted server (for both buyers and sellers). So there certainly are channels for making this sort of data available in the current design.

@brodrigu

Thanks for the answer @brodrigu
I agree that the browser handling conversion rate is not really a good idea.

the scoring function could be shipped with good-enough conversion rates on a daily basis

Seems possible, but in that case the scoring function has to store all possible conversion rates for all possible publisher currencies. It seems it's contradictory with what you said in your first sentence where you said that having each buyer/IG ship its own conversion table is inefficient, as this solution would be exactly the same.

I'd recommend that the buyer returns a currency along with the bid and that the publisher / SSP uses its own conversion rates to normalize in the scoring function

That could work, but I'd be very very afraid that some publishers would simply not implement this and ignore this "currency name" value along with the bid, and then just compare bid values that would then be in different currencies (eg one bid in Euro, one bid in USD). Then there would be tons of silent conversion errors. This is why it would seem we need an "official" system so that the client can be sure that he returns a currency that the publisher expects

@michaelkleber

Hi @michaelkleber

How do things work in RTB and in on-device header bidding today? In particular, does the auction specify the currency (or short list of currencies), and then each bidder has the obligation to submit in the currency permitted, perhaps looking up real-time conversion rates? Or do DSPs submit bids in many currencies, which are somehow normalized by the SSP?

For the "vanilla RTB" case that I know of, we know in advance the publisher currency: either it's in the request and we use it, or most probably we have a database somewhere which maps a publisher id to the currency it requires; and our bidder just returns the value in the correct currency by converting it using (almost) real-time data. (to me the real-time aspect is really not important, I think any solution with conversion rates that were refreshed in a given day is fine)

So there certainly are channels for making this sort of data available in the current design.

Indeed. What I'm afraid of is that this just rely on the "convention" that publishers should communicate their currency of choice through a given keyword. Maybe this keyword should at least be standardized in the spec ?
Basically I'm looking for a way for this currency problem to be handled in a robust fashion. From experience I know that currency stuff will otherwise silently bug and then some party ends up unknowingly bidding 30x the intended amount :)

. It seems it's contradictory with what you said in your first sentence where you said that having each buyer/IG ship its own conversion table is inefficient, as this solution would be exactly the same.

I assume here that the number of publishers/SSPs involved in a single Fledge auction would be small (probably 1) and the number of buyers would ideally be many. Hence a single conversion list handled by the publisher would be more efficient than a conversion list handled by N buyers.

It's a fair point that only a single SSP participating in a FLEDGE auction is sub-optimal and we may not want to align around that assumption.

Ah ok, sorry I misunderstood your message and mixed up bidding function and scoring function.
Indeed that's a possibility that each publisher handles internally its own currency conversion logic, and it would probably scale better than storing all conversion rates in either the bidding function or in the "trustes bidding signals" values.

Again, what i'm worried about with this solution is the fact that it requires publishers to change their logic and handle these conversions on their end (currently they don't do it). If a publisher decides to not care and assume all his bids are in Euro for instance, we will get super incoherent bids, and billing will be impacted too (imagine being billed mistakenly 100 Euros instead of 100 Korean Won, and the headache to sort this out...)

As a side note, I just had a look into the chromium fledge code and it seems that this comparaison of "who is the highest bidder" is not even done by the seller JS but directly by the browser

@michaelkleber

Hello @michaelkleber
do you have any update on this issue ? thanks

Publishers can already pass arbitrary data to scoreBid via the "ad" parameter of generateBid(). Could just require this be a currency indicator (could even ignore bid entirely and stuff the entire bid in there, if you really wanted, though bid would still have to be > 0), and then the seller signals (not currently implemented) would need to include conversion rates of all supported currencies.

Alternatively, the bidder could handle the conversions. Which, on one hand, means only the conversions needed for an auction would need to be downloaded from the bidders, but does place the onus on all bidders.

I'm not sure there's anything that can be reasonably done browser side to further facilitate this - could add a dedicated field for it as we think about other special use fields that might be handy, but I don't think that scales, and doesn't seem to be needed.

Alternatively, the bidder could handle the conversions. Which, on one hand, means only the conversions needed for an auction would need to be downloaded from the bidders, but does place the onus on all bidders.

If by bidder you mean not the browser itself but the buyer JS code, I don't see how it's possible technically to "only" download some currency rates based on publisher infos. The only communication channel with the outside is key/value server and you can't choose at bidding time which key to specifically query. It's however possible to download a json containing all conversion rates from the key/value server and applying the correct one based on what the publisher is asking.

Indeed from a purely technical standpoint, this currency issue can already be solved in 2 ways as we described above:

option 1 : get currency info from publisher, bidder has to deal with it and return a bid in given currency
option 2 : bidder bids in own currency and announces the currency, publisher deals with it and does the conversion

I'm not sure there's anything that can be reasonably done browser side to further facilitate this - could add a dedicated field for it as we think about other special use fields that might be handy, but I don't think that scales, and doesn't seem to be needed.

I don't think that anything needs to be done specifically in the browser code to handle this indeed, like having the browser itself download conversion rates and convert bids etc.
However, to me the way currency should be managed should be a part of the Fledge spec doc. As Fledge is describing a general-purpose system for adtech that is "decentralized" and that inherently does an auction between parties that don't know each other, currency should probably be a first-class "concept" included in the spec, and not an after-thought that is bolted on later on, where all the world's publisher and advertisers have now to agree on what convention they will use to transmit currency.

As I mentioned above, relying on each publisher and advertiser having their conventions on how to handle currency conversion is in itself the thing that doesn't scale, even more since bidding in incorrect currency going to produce silently invalid bids. Keep in mind that with Fledge you can easily have an APAC publisher loading interest group from a EU user, etc

Note that this is also causing trouble for the reporting, because the "cost" that is being sent in different reporting is currency-less, so it's impossible to actually know what to bill etc

I assume the seller script that's sending these reports would have to figure out the currency issue itself, so could decide what currency to use.

Note that the bidders and sellers in the FLEDGE spec are expected to know each other, and have agreements on, e.g., how to transfer money between each other. That's one of the reason the auction config lists IG owners that are allowed to participate in an auction.

(Note that wildcard owners are allowed in the FLEDGE spec, but that is currently disabled in Chrome, and likely will be removed)

Indeed it might be possible that for reporting to have the currency handled outside of Fledge, ie by knowing which publisher is billing in which currency etc.
But regarding the bidding itself, the currency has to be sorted out at this point also, otherwise the publisher will receive bids in different currencies and can't score them properly.
I understand that this could also be handled by convention outside of Fledge ("publisher 1 wants us to bid in USD", "publisher 2 allows us to bid in any currency but we have to send as metadata the currency of the bid", "publisher 3 wants us to use the currency sent in some seller signal"), but to me this seems to create massive complications for everybody and won't scale really well, over having a clear standard way to handle this defined in the spec. (having a convention in the spec wouldn't still prevent bidders from bidding in incorrect currency still, but that's another topic)

We should not forget that there is no real point in debating over ML models for bidding etc, as long as we can easily have a bid accidentally being 10x higher due to invalid currency.

In the light of the Origin Trial starting soon, I’d like to re-activate this issue:

Context

In most geos, marketers set campaign budgets in local currency and are getting billed by their DSP in local currency.
In most geos, publishers sell their ad inventory in local currency and bill their SSP in local currency.
In most geos, billing in the country’s currency is a legal requirement.
It’s in the very nature of the web to enable people access to a variety of websites in and outside their own geo. For example, a significant part of traffic for a well-known US blog site may come from outside of the US. So it’s very common for a marketing campaign from one geo to make displays on a publisher’s site of different geo. This is both beneficial for the marketer, reaching its audience on the sites they browse, and publishers, monetizing their inventory. So mismatches between the campaign’s and seller’s currencies, and currency conversions, do occur.

As of today, bidding currencies of an ad auction can be, for instance:

Set by the seller and send through a dedicated field in the bid request. The buyer has to place a bid in the requested currency (see OpenRTB specification for example https://www.iab.com/wp-content/uploads/2016/03/OpenRTB-API-Specification-Version-2-5-FINAL.pdf ).
Agreed upon between the buyer and seller in advance. The bidder has to place a bid in the requested currency (see Authorized Buyers Real-time Bidding Protocol Buffer | Google Developers for example).
Open, the seller will accept bids in multiple currencies and be responsible to do the conversion on the fly (see Module - Currency for Header Bidding for example).

Needs

So FLEDGE must provide the following features:

A way for the seller to agree in advance with or communicate to participating buyers the bidding currency or currencies.
A way for buyers to bid in an accepted currency. Note that any currency conversion must be based on recent conversion rates, as sharp intra-day exchange rates variations do occur.
And/Or a way for the seller to convert bids sent by the participating buyers.
A way for a buyer to know, with low latency, winning bids amounts and currency per campaign and seller.
A way for the seller to know, with low latency, winning bids amounts and currency per buyer.

In both reporting cases, amounts must be in the buyer bid currency, that is not modified by a seller-side conversion if any.

Proposal

In case of conversion done by the buyer (2.), this could be done by:

a. The seller adding the auction bid currency in auctionSignals.
b. The call to the buyer Trusted Server including the bid currency, something of the form
https://www.kv-server.example/getvalues?hostname=publisher.com&currency=EUR&keys=key1,key2
where the currency value is coded using the 3 letter ISO code for currencies.
c. The buyer Trusted Server returning in one of the keys the necessary relevant data so that generateBid() can take into account the bid currency through trustedBiddingSignalsKeys.
d. Adding a currency field in browserSignals alongside the bid value.
e. Passing bid value and bid currency to reportResult() and reportWin() .

a. b. d. would require a modification in FLEDGE, while c. and e. can be managed through the existing specifications.

Caveat

That solution does not support seller-side currency conversions.

What are your thoughts on this?

a. I don't believe this requires a modification in FLEDGE? auctionSignals is free form JSON, so buyers and sellers can agree to include currency as a dictionary entry in this field or somesuch.

d. Also doesn't seem to require changes. auctionSignals is passed to generateBid() and reportWin() explicitly. It's also available in the auctionConfig field of scoreAd() and ReportResult().

b. Would require changes. The current design deliberately minimizes bits of entropy provided by the page running the auction to the network requests related to the interest group. The privacy model involved in these requests isn't really my area, so I'll let others provide their thoughts there.

A few additional thoughts:

For migration, if something doesn't specify a currency, default to '???'. An unspecified value for perBuyerCurrencies gets interpreted as {'*': '???'}; with the idea of removing the default value eventually (which may be its own pain...). Same about sellerCurrency.
Do we need to support promises for perBuyerCurrencies?

@dmdabbs

@dmdabbs I contend there are better choices, especially if we want a theme song.

@morlovich Agreed that the way to migrate is to allow currency-or-'???' as an intermediary step (leaking one additional bit of information temporarily). Note that we ought to be sure we can handle buyers and sellers switching over in either order.

I suspect that we should support promises, since there may be server-side business logic (at contextual-request time) in deciding which currency some buyer wants to bid with in this auction.

@michaelkleber

Theme song and Eric Idle & Python for the win, @michaelkleber!

@michaelkleber

Thanks, @michaelkleber for the proposal in FLEDGE: currency of the bid · Issue #166 · WICG/turtledove , it looks good.

Could you please clarify the use of sellerCurrency?

Also, as mentioned by @timphsieh in a earlier comment FLEDGE: currency of the bid · Issue #166 · WICG/turtledove , during the seller’s reportResult() and buyer’s reportWin(), browserSignals should include currency for both bid and highestScoringOtherBid.
It should, I think, be the winning buyer currency for both, which is the agreed-upon currency between the buyer and seller, defined in perBuyerCurrencies.

So I interpreted (and implemented) sellerCurrency as restricting what scoreAd in a component auction returns when it's producing a modified bid (bidInSellerCurrency will do that too, once I get back to that). It does get a little awkward since the top-level auction also has perBuyerCurrencies, so there are actually 2 checks happening.

FLEDGE: Annotate bids with checkable currencies.

So basic currency checking is in as of canary 114.0.5694.0.

The rules I am thinking of for bidInSellerCurrency are:

If auctionConfig.sellerCurrency is not set, then everything is in bidder currency. highestScoringOtherBidCurrency is always '???'
If auctionConfig.sellerCurrency is set:
1. If madeHighestScoringOtherBid is true, it gets highestScoringOtherBid in its original, currency annotation is '???'
2. IfmadeHighestScoringOtherBid is false, and highestScoringOtherBid is either missing/0 or in seller currency; with the value provided by bidder if its bid was in the seller currency in the first place, or seller if it wasn't. Currency annotation is auctionConfig.sellerCurrency

FLEDGE: make sure PA uses consistent info in seller-currency mode

FLEDGE: Fix missing check vs. sellerCurrency on forwarded bids.

Pull request for explainer:
#571
(Everything here should be in M114, except the reject-reason which is in code review, and targetted for M115)

FLEDGE: Add reject reasons for currency mismatches.

FLEDGE: Adjust currency for reportResult to bidder currency

Note that the last change is change in behavior of reportResult arguments when sellerCurrency is on, so you may want to be extra-careful around that.

I'm closing this issue as currency support is added to the explainer in #571 and to the spec in #594. Feel free to reopen or file another issue if additional concerns exist.

Navigation Menu

Repository navigation

FLEDGE: currency of the bid #166

Context

Needs

Proposal

Caveat

34 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

FLEDGE: currency of the bid #166

Description

Activity

brodrigu commented on Apr 28, 2021

michaelkleber commented on Apr 28, 2021

vincent-grosbois commented on Apr 28, 2021

vincent-grosbois commented on Apr 28, 2021

brodrigu commented on Apr 28, 2021

vincent-grosbois commented on Apr 28, 2021

vincent-grosbois commented on Jun 8, 2021

MattMenke2 commented on Jun 15, 2021

vincent-grosbois commented on Jun 16, 2021

vincent-grosbois commented on Jun 18, 2021

MattMenke2 commented on Jun 18, 2021

MattMenke2 commented on Jun 18, 2021

vincent-grosbois commented on Jun 19, 2021

lbdvt commented on Apr 12, 2022

Context

Needs

Proposal

Caveat

MattMenke2 commented on Apr 12, 2022

34 remaining items

morlovich commented on Mar 20, 2023

michaelkleber commented on Mar 20, 2023

dmdabbs commented on Mar 20, 2023

lbdvt commented on Mar 22, 2023

morlovich commented on Mar 24, 2023

morlovich commented on Apr 5, 2023

morlovich commented on May 8, 2023

morlovich commented on Jun 1, 2023

JensenPaul commented on Jun 23, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions