Request for Ad Slot size as an additional BTS signal

[Gusieva]

Request:

We propose that Chrome provides the Ad Slot size(s) as an additional BTS signal.

Justification:

BTS will be able to filter ads and IGs based on the given width and height, hence, return fewer ad candidates with a higher quality. This will also decrease the size of exclusion packages that will be returned for the surviving ads.

Background:

Currently bts doesn’t have information about the slot size. Therefore Google Ads has to return creatives of all possible sizes (hundreds for GDA) to match the slot on the page. This causes several challenges:

• Limited capability to reduce the payload size.

• Prediction Models have to score the candidates of all sizes, which impacts the latency and the overall candidate scoring quality.

• Larger bts response size increases the auction latency.

Limitation:

Considering multiple slots on pubpages scenario when the HTTP cache caches trusted DSP response, we have to be accountable for keeping the cache hit rate unimpacted.

Proposal:

Given that the potential impact on cache hit rate requires experimentation, we suggest making the following parameters configurable via auction configuration:

• Bts receives a list of all slot sizes available on the publisher page as a concatenated comma separated string in each bts request. This allows Google Ads to optimize the bts response for certain slot sizes while maintaining cache hit rates.

• Bts receives an additional signal for a certain slot size. This allows Google Ads to optimize the bts response for a specific ad slot size, making the request itself lightweight.

• Bts does not receive slot size information. This option will help other bts to keep the current specification unchanged.

[michaelkleber]

Hello @Gusieva, could you please add your name and affiliation to your GitHub profile?

I'm assuming "BTS" stands for "Buyer Trusted Server", i.e. the Key-Value server run by buyers.

Currently bts doesn’t have information about the slot size. Therefore Google Ads has to return creatives of all possible sizes (hundreds for GDA) to match the slot on the page.

The request to the Key-Value server already includes the publisher page's hostname. Have you considered looking up what sizes of ads this publisher website has? I would be surprised if many publisher domains had ads of hundreds of different sizes.

Of course I might be wrong, but do you have any data on what fraction of requests have ad sizes that can easily be looked up based on the publisher domain?

Putting that aside: It's tricky to provide this information in the request to the KV server because we generally send one request to the server and then use the response for all the auctions on a page. If the response depends on the ad slot size, we might need to send many. And of course if a publisher page has ads of many different sizes on the same page, this would leave you in a much worse position than today.

• Bts receives a list of all slot sizes available on the publisher page as a concatenated comma separated string in each bts request. This allows Google Ads to optimize the bts response for certain slot sizes while maintaining cache hit rates.

The runAdAuction API doesn't know about all the ad slots on a page, just the one slot it's running an auction for. I don't see how the auction for the first ad slot on the page could know about the later ones.

• Bts receives an additional signal for a certain slot size. This allows Google Ads to optimize the bts response for a specific ad slot size, making the request itself lightweight.

I don't understand how this would interact with the single reused response problem.

[michaelkleber]

Ah, here's an idea: We could add a new optional auction configuration parameter that is a Seller-provided list of all the ad sizes on the page.

• We would include the list of all slot sizes as a parameter to the KV server.
• If the seller includes the same list of slot sizes in multiple auctions on the page, then the cache would be able to reuse the response.
• If the seller later learns about a new slot size that was not included in earlier auctions, then they would end up triggering a second KV server request
• The browser could check that the current slot size really is one of the elements of the list, and throw some configuration error (i.e. not run the auction at all) if there is a mismatch.

Maybe this was in fact what you were suggesting, and I misunderstood your request. But in any case, this does seem reasonable to me, if this would be useful to buyers and if listing all the ad sizes is a reasonable thing to ask of the seller.

It would be great to hear from both the buy and sell side about whether they like this idea, since it can only work with buy-in from both.

[rdgordon-index]

It would be great to hear from both the buy and sell side about whether they like this idea

I'm linking #417 (comment), because there are some on-going discussions on that issue about some of the challenges of size already.

[Gusieva]

Thanks Michael for the proposal. That's a good idea that fully covers the buy-side request.

Ah, here's an idea: We could add a new optional auction configuration parameter that is a Seller-provided list of all the ad sizes on the page.

• We would include the list of all slot sizes as a parameter to the KV server.
• If the seller includes the same list of slot sizes in multiple auctions on the page, then the cache would be able to reuse the response.
• If the seller later learns about a new slot size that was not included in earlier auctions, then they would end up triggering a second KV server request
• The browser could check that the current slot size really is one of the elements of the list, and throw some configuration error (i.e. not run the auction at all) if there is a mismatch.

Maybe this was in fact what you were suggesting, and I misunderstood your request. But in any case, this does seem reasonable to me, if this would be useful to buyers and if listing all the ad sizes is a reasonable thing to ask of the seller.

It would be great to hear from both the buy and sell side about whether they like this idea, since it can only work with buy-in from both.

[Gusieva]

Thanks again for the proposal. Please proceed with the implementation. Thanks!

[fhoering]

Putting that aside: It's tricky to provide this information in the request to the KV server because we generally send one request to the server and then use the response for all the auctions on a page. If the response depends on the ad slot size, we might need to send many. And of course if a publisher page has ads of many different sizes on the same page, this would leave you in a much worse position than today.

@michaelkleber I made some tests and the calls are already duplicated when ExperimentGroupId for a component auction with 2 sellers is used. So normally we can expect the calls to be duplicated already for the very same auction. Also in theory if the sellers agree for one auction on the very same ad slot size and same ExperimentGroupId only one call would be sent out. And HTTP caching could allow to reuse calls for different pages for the same ad slot. So I don't feel like this would be an issue.

Ah, here's an idea: We could add a new optional auction configuration parameter that is a Seller-provided list of all the ad sizes on the page.

On Criteo side we would like to get the right size for each adSlot of the relevant auction and not for all possible adSlots on the page. So only a single width & height and not a list. It would allow us easier filtering server side.

[michaelkleber]

OK great, thank you for the feedback Fabian. As I think @JoelPM suggested when we talked about this on the weekly call, we should figure out a way to let buyers opt into getting this signal — because different people want different versions of the information, and which version you want has implications for caching behavior.

(Separately: Yow, the idea of ExperimentGroupId breaking all caching seems really unfortunate. Who is making up these different perBuyerExperimentGroupIds?)

[JensenPaul]

I’d like to propose a concrete API design here to make sure we’re all on the same page. There would be two new input APIs:

1. The top-level auction config can optionally specify an allSoltsRequestedSizes attribute which is a list of ad slot sizes for all the slots on the page. For example:
   ‘allSlotsRequestedSizes’: [{width: 300, height: 100}, {width: 100, height: 200}]
   NOTE: The browser will throw an exception if the auction config specifies a ‘requestedSize’ that is not included in the ‘allSlotsRequestedSizes’ list.

2. Interest groups can optionally specify a trustedBiddingSignalsSlotSizeMode attribute which may contain one of the following supported values:

   • The default value (“none”) will not include any slot size values in the trusted bidding signals fetch at auction time.
   • The “thisSlot” mode will include the ad slot size of the slot that this auction is selecting an ad for in the trusted bidding signals fetch. For example, if the auction config includes 'requestedSize': {width: 100, height: 200} then the trusted bidding signals request URL will include &slotSize=100,200
     NOTE: using the “thisSlot” mode will prevent caching of trusted bidding signals across ad slots on the page which may slow down bidding by requiring individual trusted bidding signals fetches per ad slot on a single page.
   • The “allSlots” mode will include the size of all ad slots on this page in the trusted bidding signals fetch. For example, if the auction config includes the ‘allSlotsRequestedSizes’ specified above then the trusted bidding signals request URL will include &slotSizes=300,100,100,200

NOTE: specifying a mode of “thisSlot” or “allSlots” will cause the browser to include the slot size(s) in the trusted bidding signals request for this interest group, which may in turn be coalesced with requests for other interest groups that may not have specified a trustedBiddingSignalsSlotSizeMode.

[dmdabbs]

The top-level auction config can optionally specify an allSlotsRequestedSizes attribute which is a list of ad slot sizes for all the slots on the page.

This is all the acceptable sizes the pub has configured for all the slots on page or the all the requestedSizes elected for all the slots permitted to run a PAAPI auction?

In allSlots mode, the top-level seller will specify the sizes in a canonical order, versus 'order created'?

[rdgordon-index]

Re (1) -- allSlotsRequestedSizes -- curious to understand how what will be visible to sellers...

[JensenPaul]

This is all the acceptable sizes the pub has configured for all the slots on page or the all the requestedSizes elected for all the slots permitted to run a PAAPI auction?

I imagined allSlotsRequestdSizes being the list of requestedSizes for all ad slots on the page where PAAPI will be used.

In allSlots mode, the top-level seller will specify the sizes in a canonical order, versus 'order created'?

I imagined them being specified in a canonical order (e.g. order of slots on page, order slots were created, or simply sorted), so that the list matches between calls to runAdAuction() and hence the trusted bidding signal requests match between slots to facilitate caching.

Re (1) -- allSlotsRequestedSizes -- curious to understand how what will be visible to sellers...

Is there a seller use case you are imagining that would be facilitated by making allSlotsRequestedSizes visible to sellers?

[dmdabbs]

I imagined them being specified in a canonical order (e.g. order of slots on page, order slots were created, or simply sorted),

Thanks, Just verifying. Sorting will ensure the intended caching behavior across pages.

specifying a mode of “thisSlot” or “allSlots” will cause the browser to include the slot size(s) in the trusted bidding signals request for this interest group

So based on an IG's configured mode attribute, Chrome will automagically find and apply the appropriate size value as:

allSlots: ...&slotSizes = the top-level (or single-level) auction config's optional allSlotsRequestedSizes
thisSlot: ...&slotSize = the optional requestedSize from the auction config in which the IG is participating

(provided as comma-delimited width, height pair[s])

[JensenPaul]

Yes David, this matches my thinking.

Edit: actually I'm not entirely sure if the thisSlot behavior should get the size from the top-level or component auction. Hmm.

[MattMenke2]

If we're concerned about minimizing information leakage, I think it would be better to sort sizes in lexical order (note that sizes are strings, not ints, since they have have units).

[MattMenke2]

I've uploaded PR #928, which fleshes out this proposal (and tries to normalize strings a little). It does not currently specify ordering. It also forbids duplicate sizes in the list, and specifies using values from the top-level auction for both fields. Open to changing anything, just wanted a slightly more formal starting point.

[fhoering]

Can you confirm that this proposal is unrelated to using the adSizes field in IG ?
Because for fully responsive/sizeless ads I don't want to specify the adSize IG field (to not take a hit on k-anonymity) but still I would like to get the ad slot size of the auction in the trusted server.

Edit: actually I'm not entirely sure if the thisSlot behavior should get the size from the top-level or component auction. Hmm.

Normally it should be the selected size of the Component auction. The problem is it somehow requires to figure out multi size requests because today there is no way to indicate the size that has been used by the buyer as part of the component auction to the seller.

[MattMenke2]

Can you confirm that this proposal is unrelated to using the adSizes field in IG ? Because for fully responsive/sizeless ads I don't want to specify the adSize IG field (to not take a hit on k-anonymity) but still I would like to get the ad slot size of the auction in the trusted server.

This uses the same size format as adSizes field in IGs, and reuses the "requestedSize" field in AuctionConfigs, which does have a defined interaction with the adSizes field in IGs. However, this does not require IGs provide adSizes field, and does not interact directly with adSizes fields in IGs if present.

Edit: actually I'm not entirely sure if the thisSlot behavior should get the size from the top-level or component auction. Hmm.

Normally it should be the selected size of the Component auction. The problem is it somehow requires to figure out multi size requests because today there is no way to indicate the size that has been used by the buyer as part of the component auction to the seller.

I've currently specced it out to get sizes from the top-level auction, which I'm not sure any other feature does. I'm happy to change behavior, if folks prefer it to be consistent with everything else. It looks to me like requestedSize currently does in fact use the size from the component auction when passed in to bidders, so perhaps I should switch, though when providing the size to the fenced frame, we are using the size of the top-level auction.

[fhoering]

It looks to me like requestedSize currently does in fact use the size from the component auction when passed in to bidders, so perhaps I should switch, though when providing the size to the fenced frame, we are using the size of the top-level auction.

+1 for a consistent behavior across browserSignals + the trusted server call + fenced frame rendering.

In the trusted server we just want to get the same value as the one from browserSignals. So maybe it is enough to solve this ticket.

Now to align browserSignals.requestSize and fenced frame rendering size, if we say we have 1 top level seller that specifies 1 ad size and 2 component sellers that specify 2 different ad sizes we will get 3 different ad sizes. It seems unclear how one can be chosen for the final rendering stage and it is very related to issue #825.

[fhoering]

One additional question

@Gusieva Can you give some more explanations about the rational for allSlotsRequestedSizes ? If we can get the real requestAdSize for the slot it seems enough to do server side caching.
In the first place the issue comes from not knowing the adslot size at all and having to send all creatives. If we say we have 10 adSlots per page we would have 10 times more cache hits but the payload from the trusted server call would be approximately 10 times smaller as we can filter on the real ad slots size.

So maybe there is some simplification to be done by only allowing thisSlot instead of all slots ?

[MattMenke2]

The reason for this is client-side caching and response reuse, particularly if responses are short-lived. If there are multiple ad slots on the page, then one trusted signals request could be reused for all ad slots on the page, instead of needing a new one for each different sized ad slot.

[fhoering]

There can multiple slots of the same size on one page and slots can be reused when the user continues browsing the publisher website or other publisher websites (as we retrieve user data).

[rdgordon-index]

Is there a seller use case you are imagining that would be facilitated by making allSlotsRequestedSizes visible to sellers?

I missed this question earlier -- I see the same use case as on the buyer side -- we'd currently have to return trustedSellerSignals for all possible sizes for a given renderURL, rather than just the ones that are on the page.

[MattMenke2]

I think it's worth noting that arbitrary information can be added to the trustedSellerSignals URL by the caller, just not in the query parameter (though we could spec out something around that, I guess), and it's not subject to k-anon checks, so you could do "https://seller.com/.../ad-size-100-by-200/" or whatnot, though admittedly, not quite as user-friendly as having integrated support.

[rdgordon-index]

I suppose that's true -- but that implies that we know what size we're working with, which has been the subject of a number of other github issues, and is still in flux.

[rdgordon-index]

#928 has been merged -- but there was still an open question about TSS...