SPARROW: An overview of the Privacy Sandbox proposal

Secure Private Advertising Remotely Run On Webserver, or SPARROW, is another proposed mechanism for effective cookieless advertising with Privacy Sandbox. Criteo, a company that works for the buy-side, has submitted it intending to provide more control in the hands of advertisers. At its essence, it is a set of amendments for Google’s TURTLEDOVE proposal to facilitate better performance-driven advertising. Some of these amendments already became parts of FLEDGE which is an update to TURTLEDOVE.

“This is a case where we’ll be happy if these ideas are stolen for other proposals moving forward.”

– Arnaud Blanchard, Senior Analytics and Product Manager, Criteo

SPARROW’s main highlights are the features for audience discovery for advertisers and the appointment of an independent body (a gatekeeper) to carry out unbiased real-time bidding for publishers and bidders. Put simply, TURTLEDOVE delath with retargeting in the post-cookie world. SPARROW suggests improvement to TURTLEDOVE’s retargeting methods. Let’s dig deeper.

What problems does SPARROW solve?

SPARROW wants to address the issues that TURTLEDOVE  doesn’t resolve. For instance, TURTLEDOVE suggests that the browser will handle the auction. But browsers have limited bandwidths that can slow down the process. So, SPARROW wants the auction outside the browser.

TURTLEDOVE wouldn’t allow A/B testing, attribution, CTR, and conversion optimization, etc. As Criteo works with the demand side, it knows the importance of these features for advertisers. So, it tries to facilitate these features with SPARROW.

TURTLEDOVE allows simple segmentation of the audience. Complex operations like refining the segments by merging two interest groups aren’t possible with it. SPARROW suggests ways to do so.

The real-time availability of auction data is also a problem with TURTLEDOVE. But, live data allows advertisers to tune up their campaigns on the fly and saves them from overspending. Thus SPARROW advocates for real-time capabilities over TURTLEDOVE’s aggregated and delayed reporting.

Let’s see how it does so.

Single-domain Interest Groups

TURTLEDOVE’s interest groups have three properties:

• Owner Domain: The domain of the advertiser that creates the group.
• Name: The name of the group.
• List of reader domains: Ad tech parties, such as ad networks that are allowed to access the group details.

Refer to our article on TURTLEDOVE and you’ll find that the advertiser adds visitors to custom groups so that he can retarget them later. The list of reader domains consists of ad tech companies helping the advertiser to retarget.

SPARROW has suggested adding three more properties to TURTLEDOVE’s interest groups and calls them Single-domain Interest Groups. The suggested properties are:

• List of Builder Domains: The domains that can use the interest groups to create meta interest groups (we’ll discuss meta interest groups in a while.)
• Should_send_request: True or False to activate or deactivate interest groups.
• Number of users: The number of users in a group, computed by the browser.

Adding these properties will help create meta interest groups that’ll be useful in purposes such as audience re-engagement, creating new audience groups, finding similar audiences, etc. You can say that SPARROW enables wider applications of retargeting by adding the above three properties.

Meta Interest Groups

Meta Interest Groups are the union and/or intersection of interest groups. For example, people of New York form one group of audience whereas people interested in running shoes make another group. The intersection between both these groups gives us potential running-shoe buyers in New York. This intersection is a meta interest group.

Similar to Single Domain Interest Groups, meta groups also have six properties. They are:

• IG Builder: The advertiser or DSP doing the aggregation for creating the meta group.
• List of owner domains used in this meta IG: The list of the owner domains for all single-domain IG used for this meta IG creation. For example, the interest group consisting of people living in New York will come from one owner domain whereas the interest group with running shoes buyers will come from another owner domain. Please note that the owner domain wouldn’t know whether a user belongs to a specific meta group even when the user is on the owner domain. Doing so will reduce the chances of fingerprinting. The browser is in charge of adding the user to the meta interest group using information from existing groups.
• List of interest groups: It consists of all the interest groups (single-domain or meta) used to create the new meta IG creation.
• List of readers domain: Ad tech parties, such as ad networks that are allowed to access the group details.
• Should_send_request: True or False to activate or deactivate interest groups.
• Interest group formula: The formula of intersection or union of IG is used to define the meta IG. For instance, ‘New York residents interested in running shoes’ is the intersection between the two groups.

Ads for awareness

The above concept can work best when an advertiser is trying to find new customers. Below is the workflow of the execution.

Source: GitHub

This is not a case of retargeting. Here wereallylikeshoes.com is an advertiser. It can be working with a DSP connected to two publishers namely RunningShoes.com, and NYlocalnewspaper.com. So, it created a new meta interest group called NY-ShoesLover IG to target a new audience. This audience consists of visitors that go to both sites. The browser does the work of assigning the users to the meta group and this assignment doesn’t need to be instantaneous (or during the bidding process). Once created, the meta groups can be used as single domain groups for ad serving.

If you see the Should_send_request field, you’ll find that it’s set to False for both the individual groups but True for the meta group. It is so because the advertiser wants to target only the intersection of the two groups. The browser computes the number of users in a group so that the advertiser can ensure that the size of the target audience is large enough.

In this way, meta groups can allow ads for product awareness.

Retargeting (Re-engagement)

In our TURTLEDOVE article, we saw a simple retargeting of the visitors to a specific page. Meta-interest groups can help us with a special case of retargeting called re-engagement. For example, showing ads to users who visited the advertiser’s site till the last month but never returned afterward. Such visitors can be re-engaged and brought back to the site.

An advertiser can combine two interest groups and form a meta-group for re-engagement. Continuing with our previous example, the first group can be all the visitors of wereallylikeshoes.com. The second group can be all the visitors who came to wereallylikeshoes.com in the last 30 days. wereallylikeshoes.com can form a meta-group by subtracting the second group from the first group. It means the meta group will have all the visitors except the ones that came to the site in the last 30 days.

Here, the advertiser is using his own first-party data but he is able to utilize it for a broader application than TURTLEDOVE’s simple retargeting. In this way, meta-interest groups can help with re-engagements.

Gatekeeper

The involvement of a third party in the bidding process is another big suggestion in SPARROW.

Why does SPARROW suggest a third-party gatekeeper?

The third-party (a gatekeeper) will ensure that the browser doesn’t have all the power in the auction, thereby making it unbiased. It can also prevent ad tech companies from obtaining too much user data. The gatekeeper can filter the flow of data to ensure the safety of every party.

What would a gatekeeper do?

To perform its functions, the gatekeeper will hold the rules about how to handle the requests. It’ll follow clear guidelines on how to treat and process the data, how to transfer it and how long to store it. And finally, it’ll be able to prevent fingerprinting. 

Source: GitHub

The above diagram explains the workings of the gatekeeper:

1. It’ll receive the bid requests from the browser along with the user’s interest group information and contextual signals.
2. It’ll split the received request and create one request per interest group. Doing so will ensure no DSP can do micro-targeting by having multiple interest group data of the user.
3. The DSPs will receive the requests and bid accordingly for each interest group. The responses will also have ad rendering information and other metadata like product shown, video length, etc., for reporting purposes.
4. The gatekeeper receives the response from the DSPs. It’ll check whether the bids are as per the auction rules. It’ll also create an anonymized URL so that the ad renders into a fenced frame. The gatekeeper can also check for the publisher’s ad quality guidelines. Depending on the rules of the action, the gatekeeper can run an internal auction. For example, if only one bid has to be sent to the SSP, an internal auction would be required.
5. It sends the bid to the SSP and records reporting logs for the involved parties.
6. The SSP runs the auction and sends the winning bid to the ad server. This step depends on the dynamics between the Gatekeeper and the SSP. For example, the gatekeeper can run an internal auction based on ad quality and send naked bids to SSP so that the SSP has to choose the highest bid. Or the SSP can take over the ad quality aspect and run a more nuanced auction.

Sidenote: Cloud service providers and SSPs are best suited for the role of gatekeepers. They have the technical expertise, hosting capabilities and pre-existing integrations with publishers.

You can refer to Criteo’s documentation if you wish to dig deeper into how the auction takes place in SPARROW. But, here’s a quick overview.

Auction Dynamics in SPARROW with a Gatekeeper

1. The publisher sends a request to the ad server, and the ad server calls the connected SSPs,  just like the current RTB process. Another request goes to the browser for the user’s interest group. The publisher also sends contextual signals, information about the SSP-in-charge of the auction, and an ID for the auction. It is not clear how the SSP-in-charge will be decided but SPARROW mentions a Code of Conduct as a playbook for gatekeepers, so we might see similar documentation for SSP-in-charge as well. Or, it might be an SSP chosen by the publisher, but we couldn’t find any concrete answer yet. The SSP in charge will receive the responses from DSPs and Gatekeepers to run auctions and ensure ad quality from contextual. 
2. On one side, the SSPs call the DSPs. On the other side, the browser adds the interest group info and forwards its request to the appointed gatekeeper. As discussed in the previous section, the gatekeeper will regulate the information about interest groups so that the DSPs cannot do micro-targeting. Here, only the browser/gatekeeper involvement is a new aspect. After the cookie is out of the picture, a standard bid request will have only contextual information. 
3. The gatekeeper receives the bids and performs the tasks mentioned in step 4 of the previous section and sends the highest bids to the SSP in charge.
   
4. The SSP runs the auction and sends the winning contextual and interest-based ads to the ad server. Finally, the ad server chooses the right ad and delivers it to the publisher’s site. Ad selection is not completely dependent on bid amount, ad quality and internal auction mechanism will impact the process. Possible ways to handle ad quality have been discussed in this thread.
   

Over time, any advertiser/DSP will have a single gatekeeper but the gatekeeper will answer to multiple SSPs. These SSPs in turn are connected to different publishers as shown below: 

Note: The above images are from github.com

Who appoints the gatekeeper?

A gatekeeper has to be trustworthy and responsible. So, from where would this trust come? SPARROW suggests that existing auditing and certification authorities can certify gatekeepers. An appropriate policy body can define a code of conduct for the process.

Companies such as the National Institute of Standards and Technology (NIST), Financial Industry Regulation Authority (FINRA), Entertainment Software Ratings Board (ESRB), etc. are specialized in providing certifications. Similarly, a company from outside of the ad tech industry can be chosen as a certification body.

How would gatekeeper certification work in SPARROW?

The gatekeepers would pay for the certifications. Only certified gatekeepers would be eligible to receive bid requests from the browser. An API mechanism can help the browser to check the gatekeeper’s eligibility before sending the requests.

The policy body can be formed by W3C members, browsers, Trade Associations (e.g. IAB), publishers, privacy advocates, etc. It can also decide the code of conduct that’ll have the rules of operation and general guidelines for gatekeepers. Below is the diagrammatic representation of the dynamics between all the parties.

Reporting

In the initial phase, TURTLEDOVE was missing real-time reporting. SPARROW suggested some features so that advertisers and publishers can receive real-time auction data. For instance, moving the auction from browser to gatekeeper can fasten reporting.

It proposes granularity in reporting for more transparency, control, and safety in the process. Granular reports are important for publishers for accurate billing and fraud detection. On the other side, advertisers need them to measure and improve campaign performance.

What’s Next?

These were the main highlights of the SPARROW proposal for Privacy Sandbox. You can find its complete documentation on GitHub with all the details. Google took SPARROW seriously and started working on DOVEKEY while referring to the proposal. As Google has extended its support for the third-party cookie in Chrome, we can expect more changes and even the acceptance and implementation of the proposals can take a few more months. Till then, you can stay updated with all the new developments with our weekly newsletter for publishers.