Open k-o-ta opened 5 months ago
Hey @k-o-ta , can you explain how you would propose the agg service:
scalingFactor
?scalingFactor
?I am concerned this will be challenging to do privately. One of the properties of the existing system is that you can do rescaling after applying noise (and therefore is just post-processing private aggregates). It seems with your proposal you might need to do scaling before applying noise.
I apologize for the delay in my response. I understand your concerns.
- Scales different contributions with different values of scalingFactor? Yes
- Applies noise when different contributions have different values of scalingFactor? Yes
As you stated, we would lose the characteristic of being able to rescale after applying noise.
I was considering rescaling after applying noise to aggregatable reports with the same scaling factor. For example,
What the user ultimately gets is 600+500+400+Noise1/100+ 300+200+Noise2/200.
If we had initially set the scaling factor to 100, we would have gotten 600+500+400+300+200+Noise/100. To summarize about Noise:
In other words, we would compare Noise1 + 0.5Noise2 and Noise. If the distributions of Noise1, Noise2, and Noise are the same, this proposal might lead to a decrease in the accuracy of the summary report.
When the price of a purchase is dynamic, we may want to dynamically determine the scaling factor as well. However, if the scaling factor is dynamically determined when triggering, it is difficult to scale down using the same factor after aggregation.
This is a proposal to embed the scaling factor in the aggregatable value when registering the Attribution trigger. For example like this.
The scalingFactor is also embedded in the aggregation_service_payloads.payload of the Aggregatable reports. The aggregation service uses the scalingFactor to scale down when generating summary reports.
Since the scalingFactor is encrypted, it will not increase the amount of information for tracking.