WICG / privacy-preserving-ads

Privacy-Preserving Ads
Other
98 stars 20 forks source link

MaCAW with FLEDGE-style contextual signals C #13

Open michaelkleber opened 3 years ago

michaelkleber commented 3 years ago

Thank you for publishing MaCAW! This additional phase for MPC-based ad selection with higher-fidelity signals sounds extremely promising. In particular it makes it seem more plausible that we increase the privacy parameters for the lower-resolution (C', S') in the first PARAKEET round while using the second round to regain utility.

Now that the MPC is based on unmodified contextual signals C, I'd like to better understand what form those signals take. In PARAKEET you said:

We propose to remove page URL and page title from ad request. Websites can work with SSP or ad network prior to get page category and keywords to pass in an ad request.

So let's dig into "prior" means (emphasis added).

Issues #4 and #5 make it sound like there could be direct interaction between the browser and some ad networks at page rendering time before contacting the PARAKEET service. This interaction doesn't involve any user features S, but its view of page context is unrestricted.

Could that direct interaction involve an ad network providing both purely-contextually-targeted ad candidates and the contextual signals C that feed into PARAKEET+MaCAW?

Of course I understand that I'm asking about making the PARAKEET flow look a little more like FLEDGE's with a purely-contextual request. But maybe this is what you expected was hiding in the word "prior" all along.

KeldaAnders commented 3 years ago

@michaelkleber we wanted to give you a heads up that we've added this issue to the agenda for the Wednesday, April 21st at 5 pm CEST / 11 am EDT / 8 am PDT discussion.

mehulparsana commented 3 years ago

Thank you @michaelkleber for the comment.

There are multiple questions packed in the details. Responding in pieces, hopefully it provides sufficient details.

  1. Unmodified contextual signals C in MPC/MaCAW flow

    • Contextual signals in DSP call (step 4) are defined by a feature-processing.js provided the ad response as contextual-signal-processor. These signals are then encrypted to enable bid computation. This is required to keep signal parity for a DSP across publishers.
    • Contextual signals in SSP call (step 5) can be provided as raw data {url, page title, ..}. Since ad features and bids are encrypted, we believe that SSP is not gaining additional information than what it may already know from publisher.
  2. Anonymized (limited) contextual signal C' PARAKEET flow PARAKEET flow provides coarse contextual signals at category and/or publisher domain name based on privacy cost analysis. The "prior" computation here means that publisher can convert page URL and title to predefined contextual categories and provide reasonable signals to retrieve ads or to enable bid computation. These signals are assumed to be static for a given webpage content (hence it is not consider to retrieve contextual ad in same flow to reduce entropy).

We are considering direct sold ads (Issues #4 and #5) as separate setup compared to contextual ad retrieval from DSPs to simplify serving and reduce/remove need for client side auction (the auction between contextual ads and contextual+user targeted ads)

For PARAKEET and FLEDGE flow alignment, the serving would be more aligned if FLEDGE adds limited contextual signals C' in interestgroup based ad request and reduce/optimize client side auction requirements.