GAM throttling PAAPI even when Chrome has PAAPI enabled

[rdgordon-index]

As per https://support.google.com/admanager/answer/13627134:

When the Protected Audience API (formerly known as FLEDGE) becomes generally available in Chrome, Ad Manager will begin gradually increasing the amount of traffic included in its testing. We'll monitor the impact to publisher revenue as we slowly increase the percentage of traffic, and will not ramp up further if there is a noticeable negative impact to publisher revenue. We expect that by the end of 2023, up to 10% of Chrome traffic will be enabled for Protected Audience API testing.

As noted #77 (comment), #65 (comment) and privacysandbox/privacy-sandbox-dev-support#110, with the GA release of PAAPI, it has become evident that there is a gap in how on-page Protected Audience auctionConfig, GPT setConfig and GAM's handling are interacting, making it extremely difficult to for buyers, sellers and publishers to begin integrating with PAAPI.

In short, there is no indication on-device available in JavaScript that an auctionConfig registered for a component auction will not be honoured by GAM -- neither before the display call for the ad slot is executed, nor after the slot has rendered -- runAdAuction simply isn't executed, and it's invisible as to why this is the case from the browser. In other words, it acts as though there are no IGs available for the user, but that simply isn't the case. At the moment, it appears quite random as to whether or or GAM will throttle PAAPI or not.

https://services.google.com/fb/forms/uastringformultisellertestsignup/ is the proposed workaround for local testing -- but if ad tech vendors are going to begin to start PA testing, we're going to need additional clarity and signalling regarding if and when a given slot is PAAPI-eligible in GAM during the ramp-up period.

Can GAM provide this much-needed clarity?

[rdgordon-index]

From https://privacysandbox.com/intl/en_us/news/privacy-sandbox-for-the-web-reaches-general-availability:

General availability means the Privacy Sandbox technologies are in a stable state, and ready for scaled use by advertising solutions to support key business use cases

General availability of the Privacy Sandbox APIs means advertising providers and developers can now scale usage of these new technologies within their products and services, as these are now available for the majority of Chrome users

Given the overwhelming usage of GAM as the publisher ad server -- making this one of the 'key business use cases' -- I'm not sure I fully understand GAM's throttling controls; how can buyers and sellers prepare for 'scaled use' if 90% of the traffic isn't going to included by GAM?

Furthermore, beyond the overall testing population percentage, on a per publisher / network ID basis, this also makes integration extremely challenging, not to mention the difficultly in being able to correlate this invisible GAM behaviour with the https://developer.chrome.com/en/docs/privacy-sandbox/chrome-testing/ Mode A and B labelling.

[rahulkooverjee-google]

Thanks for the question!

We agree that coordinated testing is important, which is why we intend to use Chrome mode A and mode B labels to coordinate when Protected Audience auctions are run. We're still waiting on the details of the mode A labels from Chrome, but will certainly share more information once we have more to share.

[dmdabbs]

... coordinate when Protected Audience auctions are run

Not grokking the connection, The Publisher wants their partners to be able to testdrive all this nifty new advertising technology irrespective of any specially labeled browsers.

[dmdabbs]

We're still waiting on the details of the mode A labels from Chrome

FYI, @rahulkooverjee-google. DevRel published those details ten days ago. Just Mode A labels? Mode B (the ones without cookies) are also to be labeled when Chrome initiates that phase in 1Q24.

[rahulkooverjee-google]

Thanks for flagging that David!

To share an update:

• We will be enabling Protected Audience auctions where possible* on one of the mode A labels. We're still finalizing exactly what label will be used. We're going to be starting with one label initially, and will evaluate whether it makes sense to include additional labels over time.
• To your question around mode B, we will be sharing additional details soon about our planned testing. For now, I can share that we do intent to use mode B for coordinated testing as well. For clarify - that means that we will enable Protected Audience auctions where possible* on the three mode B labels where Privacy Sandbox APIs are available.

* i.e. Ad Manager won't impose a % traffic restriction like we do for global traffic today, but there may be other reasons an auction is not run such as insufficient user consent.

[dmdabbs]

Thanks @rahulkooverjee-google.

We will be enabling Protected Audience auctions where possible* on one of the mode A labels. We're still finalizing exactly what label will be used. We're going to be starting with one label initially, and will evaluate whether it makes sense to include additional labels over time.

So on labeled traffic: GAM will permit PAAPI auctions on
a) a single Chrome A label traffic, to be announced, and
b) all Mode B instance traffic
modulo the * fine print.

And not at all on unlabeled traffic, or will GAM "impose a % traffic restriction like we do for global traffic today?"

we will be sharing additional details soon about our planned testing

Should we expect that content on this repo or elsewhere, such as a product update?

[dmdabbs]

Checking in @rahulkooverjee-google.

[rahulkooverjee-google]

By default, a traffic (labeled or otherwise) will continue as today, where we run PA auctions on a percentage of traffic.

The specific changes outside of that default will be:

• No Privacy Sandbox APIs will be used for the control labels in mode A
• Privacy Sandbox APIs will be used wherever possible in mode B
• We will also specifically use one mode A label to run PA auctions where possible

Please note that this subject to change given feedback from partners on how to best use mode A labels.

[dmdabbs]

By default, a traffic (labeled or otherwise) will continue as today, where we run PA auctions on a percentage of traffic.

Thanks @rahulkooverjee-google.

The percentage of inventory on which GAM will permit Protected Audience auctions to run is that advertised here?

[rahulkooverjee-google]

Correct - we expect to enable up to 10% of traffic for PA auctions this year

[dmdabbs]

TY @rahulkooverjee-google. So those Finch (?) experiment percentages support GAM and Chrome modes.

[rdgordon-index]

Can you further elaborate how that 10% of traffic will be selected? Will it be 10% of network codes, 10% of slots of a page, 10% of browsers, etc.?

For the selections that are label-based, it should be simple enough for a seller to ensure that we do (for the soon-to-be-selected mode A label ) or don't (for control label mode A) return an auctionConfig.

However, for the ones that aren't labelled, I'm looking for further clarification as to how that can be be made available to PA participants -- otherwise, it will be impossible to distinguish between 'no IGs on device', 'no IG bids were placed' and 'runAdAuction was never called.

[dmdabbs]

Here is a table overlaying Chrome's testing doc and above comments. Does this accurately capture it, GAM's intent, @rahulkooverjee-google?

Mode	Label	% of Stable traffic	Chrome PA API Enabled?	GAM Run PA Auctions?	Notes per Chrome-facilitated testing or GAM
A	control_1.1	0.25	Y	N	GAM: No Privacy Sandbox APIs will be used for the control labels in mode A
A	control_1.2	0.25	Y	N	As the labels do not affect functionality, participants should not pass observed topics or run Protected Audience auctions when they detect the control_1.* group labels.
A	control_1.3	0.25	Y	N
A	control_1.4	0.25	Y	N
A	label_only_1	1.5	Y	Limited
A	label_only_2	1.5	Y	Limited	Limited Availability (auctions will run on limited % of traffic - same as non-labeled traffic) see post below
A	label_only_3	1.5	Y	Limited
A	label_only_4	1.5	Y	Limited
A	label_only_5	1.5	Y	Y	GAM (per below): will run on eligible inventory (not subject to traffic sampling).
B	treatment_1.1	0.25	Y	Y	GAM: Privacy Sandbox APIs will be used wherever possible in mode B
B	treatment_1.2	0.25	Y	Y	We're proposing to divide the population into three treatment_1.* groups where third-party cookies are disabled, but PS R&M APIs are available,
B	treatment_1.3	0.25	Y	Y
B	control_2	0.25	N	N	...and one control_2 group where both third-party cookies and the PS R&M APIs are disabled. Per Chrome-facilitated testing
		9.5	9.25	2.25

My original Sheet here.

[rahulkooverjee-google]

That seems right, except for the label_only_* labels. We haven't yet decided which mode A label will be used for PA API testing (i.e. it may not necessarily be label_only_1), and for the other labels it's not that no auction would run but that auctions would run similarly to un-labeled traffic

[dmdabbs]

That seems right, except that we haven't yet decided which mode A label will be used for PA API testing (i.e. it may not necessarily be label_only_1)

Yes, @rahulkooverjee-google, that was for placement only to account for the single Mode A label in your comment.

Just one label seems counter to the CMA's intent to have:

all participating ad techs would be able to see the same [] label and coordinate accordingly, i.e. use the PS R&M APIs, but refrain from using third-party cookies. For example, this allows multiple participants to run Protected Audience auctions without third-party cookies across a consistent group of browsers.