+
+ |
+ID
+ |
+ Query
+ |
+ Query Frequency
+ |
+ Type
+ |
+
+
+ | Q1
+ |
+ What is the reach for the last day?
+ |
+ Queried every day
+ |
+ Fixed Window
+ |
+
+
+ | Q2
+ |
+ What is the reach for the last calendar week?
+ |
+ Queried every week
+ |
+ Fixed Window
+ |
+
+
+ | Q3
+ |
+ What is the reach for the last month?
+ |
+ Queried every month
+ |
+ Fixed Window
+ |
+
+
+ | QC
+ |
+ What is the cumulative reach till now?
+ |
+ Queried every day
+ |
+ Cumulative
+ |
+
+
+
+
+
+## Reach Implementations
+
+First, we show that reach can be measured directly using the existing Shared
+Storage and Private Aggregation APIs – we call this approach a direct method.
+Next, we explain how sketch-based methods can be used with the same APIs.
+
+
+### Single Reach Measurement in Shared Storage + Private Aggregation APIs
+
+We start by recalling how to compute a single reach measurement via Shared
+Storage, as described in the
+[developer documentation](https://developers.google.com/privacy-sandbox/relevance/shared-storage/unique-reach).
+The idea is to use Shared Storage to record whether this browser has already
+contributed to the reach measurement for the slice.
+If it has, then we do nothing.
+Otherwise, we contribute to the histogram (with a single bucket) and record that
+a contribution has been made in Shared Storage.
+In doing so, the computed reach is simply equal to the aggregated value.
+For convenience, the following code snippet is adapted from the above linked
+documentation.
+
+
+```javascript
+const L1_BUDGET = 65536;
+
+// contentId here is some id of the interaction that is measured;
+// i.e., it is a campaign id.
+function convertContentIdToBucket(contentId) {
+ return BigInt(contentId);
+}
+
+class ReachMeasurementOperation {
+ async run(data) {
+ const { contentId } = data;
+
+ // Read from Shared Storage
+ const key = 'has-reported-content';
+ const hasReportedContent = (await sharedStorage.get(key)) === 'true';
+
+ // Do not report if a report has been sent already
+ if (hasReportedContent) {
+ // Note that this would happen if less than 30 days
+ // passed since the first visit.
+ return;
+ }
+
+ // Generate the aggregation key and the aggregatable value
+ const bucket = convertContentIdToBucket(contentId);
+ const value = 1 * L1_BUDGET;
+
+ // Send an aggregatable report via the Private Aggregation API
+ privateAggregation.contributeToHistogram({ bucket, value });
+
+ // Set the report submission status flag
+ await sharedStorage.set(key, true);
+ }
+}
+```
+
+
+Note that the reach result can be computed by taking the aggregated histogram
+value of each key and dividing by the contribution budget (`L1_BUDGET)`.
+Note that the developers website uses a scale factor (`SCALE_FACTOR`), but in
+this example the scaling factor is the same as the contribution budget so we
+use `L1_BUDGET`.
+See the
+[“Noise and scaling” section](https://developers.google.com/privacy-sandbox/relevance/private-aggregation/fundamentals#noise_and_scaling)
+of the Private Aggregation fundamentals article to learn more.
+
+
+### Single Reach Measurement with Capping
+
+An implicit assumption in the previous section is that each
+[privacy unit](https://github.com/patcg-individual-drafts/private-aggregation-api#implementation-plan)
+– i.e., <browser x reporting origin ad tech x 10 minutes> –
+contributes to only a single query.
+The reason is that (i) the Shared Storage check does not incorporate the bucket
+so even if a later content tries to contribute to the same report, it will not
+pass the check and (ii) the value contribution is 65,536 which is the same as
+the overall contribution budget (see
+[contribution budget for summary reports](https://developers.google.com/privacy-sandbox/relevance/private-aggregation/fundamentals#contribution_budget)).
+In other words, we “cap” the number of contributions each privacy unit can make
+to just one.
+In many cases, multiple contributions from a single privacy unit may be dropped
+due to a capping limit of 1.
+This can lead to poor utility, as each privacy unit's contributions are not
+fully reflected in the results.
+
+To improve utility, we can increase the contribution cap to an arbitrary number
+we wish (denoted by `CONTRIBUTION_CAP` below).
+Allowing a larger cap can capture more contributions, which is good for utility.
+However, it also results in a larger amount of noise (after scaled down by
+`L1_BUDGET / CONTRIBUTION_CAP`) which is worse for utility.
+As such, the capping parameter has to be tuned carefully.
+
+We give an example code below where the capping parameter is set to five.
+The two changes are (i) making the Shared Storage checks for the specific bucket
+and (ii) dividing each contribution value by the capping parameter.
+These changes are highlighted in light yellow.
+
+
+```javascript
+const CONTRIBUTION_CAP = 5;
+const L1_BUDGET = 65536;
+
+function convertContentIdToBucket(contentId) {
+ return BigInt(contentId);
+}
+
+class ReachMeasurementOperation {
+ async run(data) {
+ const { contentId } = data;
+
+ // Generate the aggregation key and the aggregatable value
+ const bucket = convertContentIdToBucket(contentId);
+ const value = Math.floor(L1_BUDGET / CONTRIBUTION_CAP);
+
+ // Read from Shared Storage
+ const key = `has-reported-content-${bucket}`;
+ const hasReportedContent = (await sharedStorage.get(key)) === 'true';
+
+ // Do not report if a report has been sent already for this bucket
+ if (hasReportedContent) {
+ return;
+ }
+
+ // Send an aggregatable report via the Private Aggregation API
+ privateAggregation.contributeToHistogram({ bucket, value });
+
+ // Set the report submission status flag
+ await sharedStorage.set(key, true);
+ }
+}
+```
+
+
+
+### Multiple Reach Measurements with Capping
+
+While the above method focuses on a scenario where each content can contribute
+to only a single reach measurement (i.e., a single “query”), it can be extended
+to the case where each content can contribute to multiple reach measurements by
+having a key for each query.
+
+Below, we give an example of this for the hierarchical queries described above.
+Note that each reached browser (i.e., first time the advertisement is shown to
+the user) contributes to exactly one slice in each
+[level](#level).
+Thus, the number of histogram keys that each reached content contributes to is
+equal to the number of levels.
+Due to the
+[contributions budget](https://developers.google.com/privacy-sandbox/relevance/private-aggregation/fundamentals#contribution_budget)
+constraint, the scale factor is now divided by the number of levels in addition
+to dividing it by the contribution cap (`CONTRIBUTION_CAP`).
+While we adhere to equal contribution per level, it is possible to further
+optimize the contribution budget across different levels, as explained in the
+[relevant paper](https://arxiv.org/pdf/2308.13510).
+
+The code for this is below.
+
+
+```javascript
+const CONTRIBUTION_CAP = 5;
+const NUM_LEVELS = 4;
+const L1_BUDGET = 65536;
+
+function convertContentIdAndLevelToBucket(contentId, level, ...otherDimensions) {
+ // Implement a function that computes the bucket key for a given level using
+ // level-related fields from otherDimensions.
+ // E.g., in our example, the second level could set the key to be the concatenation
+ // between advertiser and campaign id of this content.
+}
+class ReachMeasurementOperation {
+ async run(data) {
+ const { contentId, ...otherDimensions } = data;
+
+ for (let level = 1; level <= NUM_LEVELS; level++) {
+ // Generate the aggregation key and the aggregatable value
+ const bucket = convertContentIdAndLevelToBucket(contentId, level, ...otherDimensions);
+ const value = Math.floor(L1_BUDGET / (CONTRIBUTION_CAP * NUM_LEVELS));
+
+ // Read from Shared Storage
+ const key = `has-reported-content-${bucket}`;
+ const hasReportedContent = (await sharedStorage.get(key)) === 'true';
+
+ // Do not report if a report has been sent already
+ if (hasReportedContent) {
+ return;
+ }
+
+ // Send an aggregatable report via the Private Aggregation API
+ privateAggregation.contributeToHistogram({ bucket, value });
+
+ // Set the report submission status flag
+ await sharedStorage.set(key, true);
+ }
+ }
+}
+
+// Register the operation
+register('reach-measurement', ReachMeasurementOperation);
+```
+
+
+A sample call would look like:
+
+
+```javascript
+await window.sharedStorage.run('reach-measurement', { data: {
+ contentId: '123',
+ geo: 'san jose',
+ creativeId: '55'
+}});
+```
+
+
+
+### Cumulative Reach Measurements
+
+So far, we have not mentioned the time aspect of the queries.
+In particular, we assume that all queries correspond to the same time periods.
+However, we may want to measure time-related queries.
+A popular family of such queries is cumulative queries, which are queries of
+the form “what is the total reach up until timestep `t`?” where
+`t` varies from `1, …, T`.
+For example, one might want to measure the reach up until today everyday for the
+ entire month. In this case, we would have `T = 30` and “timestep” being a day.
+
+_Note: Both methods described in this section are limited by the
+[retention policy](https://github.com/WICG/shared-storage?#data-retention-policy) of Shared Storage which is 30 days from last write._
+
+
+#### Direct Method
+
+For cumulative reach queries, we can naively apply the direct method above by
+adding the timestamp to the key of the histogram.
+If a user is reached at time step $`i`$, then contributions would be made to all
+of $`i, \dots, T`$ buckets.
+Since there are $`T`$ queries, the noise will scale by a factor of
+$`O(T / \epsilon)`$.
+Note that with the current API, one would need to wait until the last window to
+obtain the results since reprocessing of the reports is not currently supported.
+
+
+#### Point Contribution
+
+We can improve upon the above direct method by a simple modification.
+For simplicity, we only discuss the mechanism (and give the code) for
+the single-query cap-one case.
+It is easy to extend this to the multi-query case by appending the query id to
+the keys.
+Before we describe the mechanism, let us first make the following observation.
+Consider the number $`n^{(\text{new})}_i`$ of users that were reached for the
+first time at timestep $`i`$.
+The answer of cumulative reach up to timestep $`t`$ is exactly equal to the
+cumulative sum $`\sum\limits_{i=1}^t n^{(\text{new})}_i`$.
+Using this fact, we can simply create $`T`$ buckets, where bucket $`i`$ corresponds
+to $`n^{(\text{new})}_i`$.
+When we wish to compute the cumulative reach up to time step $`i`$, we take the
+sum of the first $`i`$ buckets. Since each user contributes to only a single
+bucket, each bucket’s noise standard deviation is only $`O(1 / \epsilon)`$.
+Since we are summing up to $`T`$ such (independent) noises, the total noise
+standard deviation is $`O(\sqrt{T} / \epsilon)`$, which is an improvement of
+$`O(\sqrt{T})`$ over the direct method.
+
+An implementation in Shared Storage is given below.
+
+
+```javascript
+// Time horizon T
+const TIME_HORIZON = 30;
+const L1_BUDGET = 65536;
+
+function convertContentIdToBucket(contentId, currentTime) {
+ // This key corresponds to n_i as described above with i = currentTime.
+ // Note that the remainder of "bucket" when divided by TIME_HORIZON
+ // is currentTime and the quotient is contentId; hence, this formula gives a
+ // unique id to each pair of contentId and currentTime.
+ return TIME_HORIZON * BigInt(contentId) + currentTime;
+}
+
+class ReachMeasurementOperation {
+ async run(data) {
+ const { contentId } = data;
+
+ // Read from Shared Storage
+ const key = 'has-reported-content';
+ const hasReportedContent = (await this.sharedStorage.get(key)) === 'true';
+
+ // Do not report if a report has been sent already
+ if (hasReportedContent) {
+ return;
+ }
+
+ // Should be appropriately set by the ad tech (e.g., based on hour or day)
+ const currentTime;
+
+ // Increment the current bucket
+ const bucket = convertContentIdToBucket(contentId, currentTime);
+ const value = L1_BUDGET;
+
+ // Send an aggregatable report via the Private Aggregation API
+ privateAggregation.contributeToHistogram({ bucket, value });
+
+ // Set the report submission status flag
+ await this.sharedStorage.set(key, true);
+ }
+}
+```
+
+
+The code for computing cumulative reach from the aggregated histogram is given
+below.
+
+
+```python
+# Time horizon T; needs to be fixed beforehand
+TIME_HORIZON = 30;
+L1_BUDGET = 65536.0;
+
+
+def convert_content_id_to_bucket(content_id: int, current_time: int) -> int:
+ # Same as the client-side function above.
+ return TIME_HORIZON * content_id + current_time;
+
+def compute_cumulative_reach(
+ aggregated_histogram: dict[int, int],
+ content_id: int) -> dict[int, int]:
+ """Compute cumulative reach for the given content_id.
+
+ Args:
+ aggregated_histogram: a mapping from key to aggregated value n the summary
+ report output by the Aggregation Service.
+ content_id: the content id for which the cumulative reach is computed.
+
+ Returns:
+ a mapping from time step to the cumulative reach up until that time step.
+ """
+ res = {}
+ for t in range(TIME_HORIZON):
+ res[t] = 0
+ for i in range(1, t + 1):
+ key = convert_content_id_to_bucket(content_id, i)
+ res[t] += aggregated_histogram[key] / L1_BUDGET
+ return res
+```
+
+
+Finally, we remark that, for larger values of T (which may be the case if
+measuring cumulative reach on granularities less than one day), there are more
+advanced mechanisms that can reduce the error further
+[[1](#private-decayed-sums),[2](#private-counting)],
+but this is beyond the scope of this paper.
+
+
+### Sketch-Based Methods
+
+Sketching is a technique for estimating the reach (and other quantities of
+interest) using compressed aggregated data structure admitting merge operation.
+Here we only consider one of the most basic families of sketches, called
+[counting bloom filters (CBFs)](https://en.wikipedia.org/wiki/Counting_Bloom_filter).
+In this case, we have a hash function $`h`$ that maps any user ID to one of $`m`$
+buckets.
+The CBF sketch is simply the histogram on these $`m`$ buckets among all the
+reached users.
+We can estimate the reach based on the number of non-empty buckets in the
+sketches.
+The exact formula for this estimation is based on the hash function
+distribution.
+
+The main advantage of this sketch is that it can be merged: if we have two CBFs,
+summing them up gives us the CBF corresponding to the union of the two
+(multi)sets.
+This allows us to be more flexible when answering queries.
+Recall that, in the direct method, we need to know all the queries beforehand
+since we need to allocate each bucket and each query.
+This is not needed when using sketches: We can simply create a sketch for each
+fine-grained unit (e.g. the reach for each day) and, when we make a query for a
+day range, we take the union of all the sketches in that range.
+This means that the analyst can supply the queries in an on-demand fashion,
+which is more convenient. Moreover, sketching methodology offers another
+significant advantage: the ability to deduplicate user IDs across multiple
+devices, providing a more accurate picture of individual engagement.
+This would typically require using the same user ID on multiple devices.
+Shared Storage is partitioned per browser, so the ad tech would need to identify
+the user across devices independently. Alternatively, there are modeling-based
+approaches (e.g.
+[virtual people](https://research.google/pubs/virtual-people-actionable-reach-modeling/))
+that would avoid the need for these
+IDs to map directly to real-world users.
+
+Nevertheless, there are also several disadvantages of this sketch.
+Firstly, each sketch is a histogram with $`m`$ buckets.
+In contrast, the direct method only outputs a single number per query.
+Therefore, the sketching method can result in a memory usage overhead during
+processing of the aggregatable reports and during post-processing of the summary
+reports compared to the direct or point contribution methods.
+Secondly, since the noise is added to every entry of the sketch, this can lead
+to inaccurate estimates if the noise is large.
+Specifically, as we will see below, we need to set the capping parameter to be
+small to ensure the noise is small but doing so results in a large error due to
+capping.
+This tension means that we have to be very careful in terms of parameter
+settings to ensure (reasonably) accurate estimates.
+
+The overall scheme of the reach estimation involving sketches is described on
+the following diagram.
+
+
+
+
+We remark that there are many other types of sketches beyond counting bloom
+filters (CBFs), such as
+[(boolean) bloom filters](https://en.wikipedia.org/wiki/Bloom_filter);
+and even CBF’s could use different hashes with different distributions of
+values.
+In this paper, we only focus on uniform CBFs since they are histograms and thus
+most compatible with the API and change of the distribution didn’t change the
+experimental errors in our dataset.
+However, it is plausible that other types of
+sketches can allow for better utility.
+
+As the sketch is simply a histogram, it is simple to implement via the Shared
+Storage and Private Aggregation APIs.
+Again, for simplicity, we only include the code snippet for the cap-one case
+below. (Note that if there are many different content ids, one might consider
+splitting them into groups using
+[filtering ID’s](https://github.com/patcg-individual-drafts/private-aggregation-api/blob/main/flexible_filtering.md).)
+
+
+```javascript
+// Sketch size m
+const SKETCH_SIZE = 10000
+const L1_BUDGET = 65536;
+
+function sketchHash(userId) {
+ // Should output a number in 0, ..., SKETCH_SIZE - 1 based on which bucket of
+ // the sketch the user id is hashed to.
+}
+
+function convertContentIdToBucket(contentId, userId) {
+ // Note that the remainder of convertContentIdToBucket when divided by
+ // SKETCH_SIZE is sketchHash(userId) and the quotient is contentId; hence,
+ // this formula gives a unique id to each pair of contentId and
+ // sketchHash(userId).
+ return SKETCH_SIZE * BigInt(contentId) + sketchHash(userId);
+}
+
+class ReachMeasurementOperation {
+ async run(data) {
+ const { contentId } = data;
+
+ // Read from Shared Storage
+ const key = 'has-reported-content';
+ const hasReportedContent = (await sharedStorage.get(key)) === 'true';
+
+ // Do not report if a report has been sent already
+ if (hasReportedContent) {
+ return;
+ }
+
+ // Generate the aggregation key and the aggregatable value
+ const userId = getUserId();
+ const bucket = convertContentIdToBucket(contentId, userId);
+ const value = 1 * L1_BUDGET;
+
+ // Send an aggregatable report via the Private Aggregation API
+ privateAggregation.contributeToHistogram({ bucket, value });
+
+ // Set the report submission status flag
+ await sharedStorage.set(key, true);
+ }
+}
+```
+
+
+After aggregation, each content id will have a sketch associated with it.
+To estimate the reach given sketches the following algorithm can be used.
+
+
+```python
+import numpy as np
+
+def _invert_monotonic(
+ f: Callable[[float], float], lower: float = 0, tolerance: float = 0.001
+) -> Callable[[float], float]:
+ """Inverts monotonic function f."""
+ f0 = f(lower)
+
+ def inversion(y: float) -> float:
+ """Inverted f."""
+ assert f0 <= y, (
+ "Positive domain inversion error."
+ f"f({lower}) = {f0}, but {y} was requested."
+ )
+ left = lower
+ probe = 1
+ while f(probe) < y:
+ left = probe
+ probe *= 2
+ right = probe
+ mid = (right + left) / 2
+ while right - left > tolerance:
+ f_mid = f(mid)
+ if f_mid > y:
+ right = mid
+ else:
+ left = mid
+ mid = (right + left) / 2
+ return mid
+
+ return inversion
+
+def _get_expected_non_zero_buckets(
+ bucket_probabilities: list[float],
+) -> Callable[[int], float]:
+ """
+ Create a function that computes the expected number of non-zero buckets.
+
+ Args:
+ bucket_probabilities: A list of probabilities of each bucket
+ being selected when a user is added to a sketch.
+ Returns:
+ A function that given the number of users, returns the expected number of
+ non-empty buckets.
+ """
+ def internal(count: int):
+ return sum(
+ 1 - pow(1 - p, count)
+ for p in bucket_probabilities
+ )
+ return internal
+
+
+def estimate_reach(
+ sketches: list[list[int]],
+ bucket_probabilities: list[float],
+) -> float:
+ """
+ Estimate reach given the sketches.
+
+ Args:
+ sketches: the list of sketches, where each element of a sketch is an
+ element of the histogram.
+ bucket_probabilities: probability of a given bucket being chosen for a
+ user; for uniform CBF's all the values are the same, for exponential
+ CBF ith element has value `alpha ** i` for some fixed value alpha.
+ """
+ sketches = np.array(sketches)
+
+ thresholded_sketches = (sketches >= 0.5).astype(int)
+ merged_sketch = thresholded_sketches.sum(axis=0)
+ thresholded_merged__sketch = (merged_sketch >= 0.5).astype(int)
+ non_zero_buckets_count = thresholded_merged__sketch.sum()
+
+ estimator = _invert_monotonic(
+ _get_expected_non_zero_buckets(bucket_probabilities),
+ lower=0,
+ tolerance=1e-7,
+ )
+
+ return estimator(non_zero_buckets_count)
+```
+
+
+
+## Empirical Evaluation
+
+
+### Data
+
+Due to privacy concerns, in this paper, we choose to evaluate errors on
+synthetic data.
+Working on real ad datasets, we find out that the reach on datasets can be
+modeled in the following way. Reach for one day follows
+[power-law distribution](https://arxiv.org/pdf/2311.13586) with shape parameter
+$b$.
+When analyzing different datasets based on the different query or various slice
+definitions, such as hierarchical queries, we noticed a consistent pattern.
+Specifically, these datasets exhibit a power-law distribution, albeit with
+differing shape parameters.
+In our observations, it was noted that capping on the client side does not
+affect the shape of the power-law distribution, indicating that campaign
+impressions are dropped by capping with equal probability.
+In contrast, capping does have a significant impact on the volume reports from
+clients.
+The rate of reports dropped by capping, i.e., the capping discount rate, follows
+a power-law distribution with respect to the capping value.
+Figure 2 displays a representative discount rate versus capping plot and
+corresponding curve fitting.
+
+Furthermore, we examined the impact of the time window on the reach. Reach does
+not demonstrate a linear relationship with time window size.
+Instead, it exhibits a diminishing return compared to linear growth as
+illustrated in Figure 3.
+This discount follows a power-law function relative to the size of the time
+window.
+
+
+
+
+
+
+```python
+def sample_slices(
+ number_of_days,
+ cap,
+ dataset_power_law_shape,
+ n_samples
+) -> list[SliceSize]:
+"""Generates a synthetic dataset in slices (tuples of capped and uncapped numbers).
+
+
+ Args:
+ number_of_days: what time window the query is using.
+ cap: the maximal number of slices a user might contribute.
+ dataset_power_law_shape: dataset specific power-law shape param.
+ n_samples: number of slices to generate.
+ """
+
+
+ # sample reach distribution from power-law distribution.
+ reach_1_day = sample_discrete_power_law(
+ b=dataset_power_law_shape,
+ n_samples=n_samples,
+ ...)
+ # approximate impact of capping.
+ # compute probability of being reported (success, not impacted by capped)
+ # after capping.
+ p_reported = (1 - cap_discount_rate(cap=cap))
+ # for a slice of true size n, each contribution has p_reported probability to
+ # be reported. Thus after capping, observed contributions become
+ # np.random.binomial(n, p) (there may be faster approximations)
+ reach_1_day_capped = np.random.binomial(reach_1_day, p_reported)
+
+
+ # approximate impact of time window
+ reach_n_days = reach_1_day * number_of_days * window_discount_rate(number_of_days)
+ reach_n_days_capped = reach_1_day_capped * number_of_days * window_discount_rate(number_of_days)
+
+
+ # round to nearest int
+ reach_n_days = np.round(reach_n_days).astype(int)
+ reach_n_days_capped = np.round(reach_n_days_capped).astype(int)
+
+
+ return [
+ (uncapped, capped)
+ for uncapped, capped in zip(reach_n_days, reach_n_days_capped)
+ ]
+```
+
+
+Listing 1: pseudocode to generate synthetic data.
+
+
+