PARRROT is one of the APIs in the Google Privacy Sandbox and belongs to the TURTLEDOVE family. 

Even though the demise of third-party cookies has been extended till late 2023, all the major parties in the ad tech industry are bent upon finding solutions to deal with the situations. One of the most anticipated of all the possible solutions or ideas out there is Google’s Privacy Sandbox. 

Privacy Sandbox APIs have suggested some key developments that may allow publishers and advertisers to target audiences in a fruitful yet compliant manner, however, nothing is set in stone as of now. 

We previously discussed TURTLEDOVE and SPARROW, web browser APIs that have defined ways to retarget audiences without compromising their privacy. After these, the DOVEKEY proposal has also been submitted by the Google Ads team. 

Read all about TURTLEDOVE and SPARROW here. 

While these proposals have introduced some key features, there have been various concerns regarding their functioning. Due to this, other parties in the ad tech industry have also submitted subsequent proposals that build upon and improve the initial proposals, one of which is PARRROT.  

What is PARRROT?

PARRROT (Publisher Auction Responsibility Retention Revision of TurtleDove) is a proposal submitted by Magnite (previously Rubicon Project) and is a recent development in the TURTLEDOVE family. 

The key change in this proposal is that it gives back the control of the auction back to the publisher. The TURTLEDOVE proposal initially suggested that auction-based decisions take place in the browser in order to make sure that user data is not shared with any third party. However, it was soon pointed out that this may put a lot of strain on the browser. 

Therefore, while PARRROT retains the original privacy-related principles of TURTLEDOVE, it suggests that decisions related to the auction should lie with publishers. This is done by making use of the Fenced Frame proposal (we’ll get to it in a minute). 

What is the significance of giving publishers the control of auction decisioning?

PARRROT is majorly built upon TURTLEDOVE and aims to improve the API by restoring the control of the auction with the publisher. This is because when a programmatic auction is conducted, a lot of factors come into play: the bid price, targeting, domain, regional factor, buying models etc. And, this is true for every ad impression. 

If the browser is in control of the auction, as is the case with the original TURTLEDOVE proposal, the publisher will not be able to consider all these factors for determining the outcome of an auction. But, PARRROT allows publishers or SSPs to get control of the auction, thereby putting them in a better position to see how header bidding auctions are working out. 

Here’s what Garrett McGrath, VP of Product Management at Magnite, told Lynne D. Johnson during an AdMonsters’ interview:

Running a programmatic ad auction within the browser leaves out many necessary factors and data points. PARRROT lets the publisher run and decision on the auction while still maintaining the anonymity design of TURTLEDOVE. 

…PARRROT is more focused on maintaining the aspects of the auction that are beyond audience membership and bid price because, as noted, there are many other factors that need to be considered. And almost none of those additional inputs are available to the browser.

What is Fenced Frame?

Currently, third party iframes are used during the ad serving process. These iframes are able to communicate with the page they are embedded on. However, once third-party cookies are deprecated, this type of communication will not be possible. 

The fenced frame API has basically been introduced by Google software engineers to prevent cross-site tracking, which is currently possible due to third-party iframes. 

The fenced frame enforces a boundary between the embedding page and the cross-site embedded document such that user data visible to the two sites is not able to be joined together. This can be helpful in preventing user tracking or other privacy threats.

Github

As an ad will be served within the fenced frame, the surrounding page will not be able to track the kind of ad that the user is seeing. The major use-cases of this API are conversion lift measurement studies and interest group based advertising. Since the page will not know which ad is being served, the interest group of the user will also not be disclosed. 

PARRROT’s Workflow

PARRROT’s proposed workflow is initiated much like a programmatic auction is conducted now: the header bidding code will send ad requests and connect with the ad server for responses. 

Once a response is received, the code would either initiate a TURTLEDOVE request or see if a directly sold ad is of higher value than any programmatic ad. The TURTLEDOVE workflow can also be initiated despite the high value of a direct ad if the publisher wants that. 

The ad would then be rendered inside the fenced frame, preventing any data leakage, after the code takes into account interest group and contextual data for determining the winning ad. 

Final Thoughts

PARRROT aims to enhance TURTLEDOVE and is complementary to previously proposed APIs, SPARROW and DOVEKEY. While this proposal maintains the key objectives of TURTLEDOVE, the auction decisions exist not within the browser but with an external entity, the publisher. By doing so, PARROT also addresses the concerns associated with the ‘gatekeeper’ concept. 

PARRROT and DOVEKEY simplify the Gatekeeper by removing any computation tasks thereby increasing trust among users. PARRROT addresses where the auction logic is run, not how audiences are handled.

Garrett McGrath

Despite all the necessary developments in this proposal, PARRROT is still not the last word and has limitations. One of the key issues with PARRROT, as was the case with previous proposals, is reporting. Currently, Aggregate Reporting API, which as McGrath puts it “no one has seen or understands”, is suggested as the only solution for the reporting issue. 

The recent proposal FLEDGE has some additional advancements in certain areas, which we’ll shed light on in the upcoming blog posts. 

---