michaelkleber
commented
10 months ago Hi Isaac: Sorry, I don't think I understand your question. Are you trying to figure out the yes/no story in control_1 for some specific behavior?
The idea is that control_1 is supposed to be "like the 3PC status quo" in terms of bidding and serving, but that it's OK to also perform measurement using ARA in control_1. One key reason to use ARA is so that you can do an apples-to-apples comparison with the treatment branch. That is, if you're going to serve ads using 3PC in control_1 and PA in a treatment branch, you can use ARA to measure both of them, so that you can be confident that any differences you see are because of the different serving approach rather than different ways of measuring what happened.
thegreatfatzby
I sent this over to CMA but thought I'd post this here as people might a) know the answer b) be able to say what their belief is, etc. So, to be clear for the no-doubt busy Chrome team, this isn't another feature request or bug submission :)
To try to summarize: The change is that language relating to "before issuing the request for bids" was dropped, but the rest of the guidance still seems to indicate that control_1 is intended for isolating experimentation on measurement APIs, so I'm guessing this is an error and would ask for an update, and if not an error I'd ask for clarification.
Introduction
I am working on the Microsoft pieces of Privacy Sandbox. I come to MSFT Ads by way of AppNexus, having worked in the industry for getting on 12 years. Enough chit-chat!
Overview
I'm seeing a slight, important, and I think unintentional, inconsistency in the explicit definition of control_1 in the latest Industry Guidance. I believe "unintentional" because it is inconsistent not just with the explicit definition in previous guidance, but also with the recommendations for how to use it in further paragraphs in the same latest guidance document.
The change is that language relating to "before issuing the request for bids" was dropped, but the rest of the guidance still seems to indicate that control_1 is intended for isolating experimentation on measurement APIs, so I'm guessing this is an error and would ask for an update, and if not an error I'd ask for clarification.
See below for more details, thank you.
Detail
In the original November 22' Guidance and June 23' Update, the explicit definition of control_1 is given as targeting controlled experimentation with "new Privacy Sandbox APIs" removed "before bidding", which I generally interpret as meaning during the auction itself, with the intention being to specifically experiment on measurement APIs like Attribution Reporting API. Original Nov 22 17.a (Page 5): control group 1: keeping data related to TPCs and removing data related to new APIs before issuing the request for bids; Jun 23 Update 11.i (Page 4): control group 1: ads served using data related to TPCs and removing data related to new APIs before issuing the request for bids;
In the Nov 23 update the explicit definition changes slightly: Nov 23 Update 4.b (Page 2): Control 1: impressions served with data related to TPCs and removing data related to new Privacy Sandbox APIs) (the ‘status quo’).
The latest (Nov 23) explicit definition now has no mention of bidding. "Ads served" changed to "impressions served", so maybe that was thought to convey some narrowing of scope, but based on the definition of control_2 in 4.c, and previous language, I'm guessing that isn't the case, and if it is I would say that is not clear.
Additionally, the discussion of how to use control_1 in paragraphs 10-15 seems much more consistent with the explicit definition from the original and Jun 23 update.
So my ask is that this be clarified as either a) an error and that the explicit definition should be inline with previous documents or b) please clarify.
Cheers Budd-ays! Isaac Foster