- From: Erik Taubeneck via GitHub <sysbot+gh@w3.org>
- Date: Mon, 09 May 2022 16:00:41 +0000
- To: public-patcg@w3.org
> I think I might be missing something. Is this use-case possible to achieve with IPA: > > > imagine there's a single advertiser selling a single product, and is running 3 different campaigns for it. They want to use IPA to measure the relative performance of their 3 campaigns. > > i.e. I want a break-out that says: Campaign1: led to 10 conversions Campaign2: led to 15 conversions Campaign3: led to 150 conversions > > My thought from the doc was this is accomplished via carefully sending relevant source events, but it seems like there is some other way this should be done. Here is the relevant piece from the doc: > > > Note that source.example can use its own context and the context provided by trigger sites to group these queries into relevant sets. For example, if the source reports were a set of ad impressions, source.example could choose to run a query for a specific campaign, and only include trigger reports for items relevant to that campaign. > > Now that is specific to a source query, but I assumed you'd do the same for trigger queries like the one I described. Our wording in the doc may not have been super clear - there are two different cases to consider here. The first case is the one you mention, you would want to issue a single query, with all the events. It would be something like the following SQL query: ```sql select source_event.campaign_id , count(trigger_event.event_id) , sum(trigger_event.value) from source_events join trigger_events on <matchkeys and attribution logic> group by source_event.campaign_id ``` The second case is where there are multiple distinct products involved, such as: ``` { (campaign_1a, campaign_1b, ...) : product_1, (campaign_2a, campaign_2b, ...): product_2, ... } ``` In this case, since these queries can be constructed entirely independently, the advertiser running the query should be able to bifurcate them appropriately and run the same query as above, without having an effect on the results. In that case, having less data should be more efficient, and also not exhaust unnecessary privacy budget. It would also prevent the need for more complicated attribution logic in the MPC (since you'd only want attribution within that appropriate mapping.) -- GitHub Notification of comment by eriktaubeneck Please view or discuss this issue at https://github.com/patcg/private-measurement/issues/9#issuecomment-1121286617 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 9 May 2022 16:00:42 UTC