 Since NoiseLab focuses on summary reports, we will do an overview of summary reports and what that workflow looks like. Summary reports enable detailed campaign and conversion reporting to support attribution modeling. The output of summary reports contains only aggregated results with noise added and timing delays. It's important to remember that summary reports are made up of batches of aggregate reports. In this next slide, we will see how a summary report is constructed from multiple aggregate reports and what that flow from an ad tech and user perspective looks like. Aggregate reports are made up of buckets which are dimensions an ad tech wants to track and values which are various values an ad tech also wants to track. In our example here, we're going to pretend that an ad tech wants to track these three various dimensions campaign ID, geography, and product category. And each of these dimensions has the following values. So for campaign ID, you can see four different campaign values. For geography, you can see three different values. And then for product category, we have two values, home and sports. These various values make up the aggregation buckets, which are also referred to as keys. So for example, a bucket takes one value from each of these dimensions. So if you look at bucket number one, we can see that it takes one campaign ID. It takes the geography of US and it takes the product category home. Based on the number of values that we have per dimension, the total number of buckets that we would have is equal to the values in the first dimension times the values in the second dimension times the values in the third dimension. So for this scenario, that would be 24 total buckets that the ad tech plans to track. Now that we understand the idea of tracking dimensions and buckets, we can see how an ad tech would use this concept to generate actual aggregate reports, which then turn into summary reports. The first step is when a user clicks or views an ad. At this time, the ad tech can register this event and basically start to generate their aggregation bucket or key as we saw on the previous slide. So in this example, when a user clicks or views an ad, the ad tech would then start creating their aggregation bucket by writing some of their publisher or source site information into this aggregation bucket. In this example, let's say the ad took place in the US. So the ad tech would write down this information as geo us as we can see right here. And then they also serve a specific campaign ID, which they would also add as part of the aggregation bucket, which in this case would be the one a three that they have added to the aggregation bucket or also referred to as key. In addition to that, the ad tech would also specify what value they are planning on tracking. In this example, they have decided to track purchase value, which they have indicated here as well. Then at a later time, when the user makes a purchase or some sort of conversion, the ad tech can then add in the conversion site information into the aggregation bucket. In this case, that would be the product category, which wouldn't be known until the user makes a purchase. So at that time, the ad tech would register this event and add to the aggregation bucket, which in this example would be the home value. Additionally, at this time, the ad tech would also go ahead and set the associated value for this bucket. So in this case, that would be the purchase value, which is indicated here by the 200 that has been placed in the purchase value bucket. The aggregation bucket now consists of a geography value, a campaign ID value, a product category value, and an associated purchase value. After all of these values are set, an aggregate report is generated by the browser which includes encrypting the data and then sending it to the ad tech servers after a certain amount of delay. And that summarizes the creation of one aggregate report. One important call out, which we will also discuss more in future slides and the Noiselab demo is the concept of scaling. When an ad tech is setting the associated purchase value, they can scale this value based on the contribution budget. By scaling this value, Nois will have lower impact. We will go into more detail regarding this in a later section. Now that we have seen the creation of one aggregate report in practice, an ad tech would most likely receive many of these encrypted aggregatable reports from various browsers as users go through the flow of seeing an ad and then converting. The ad tech can store these encrypted aggregatable reports on their servers as seen in the middle column. The ad tech can then decide how they want to batch these reports, for example, daily, weekly, monthly, or other ways as well. They would then send a batch of aggregatable reports to the aggregation service or trusted execution environment. Here, the reports in the batch will be decrypted and then aggregated together. So in this example, all buckets that are the same will have their purchase value summed together. And then within this environment, Nois will be added to the aggregated purchase value. Once this is completed, a summary report is sent back to the ad tech. In this example, the ad tech would receive back information that for this bucket, there was an aggregate purchase value of $53,000. The ad tech will not know the true value of $50,000, but rather the aggregate purchase value with Nois added.