How will audiences be targeted once the cookie crumbles? How will buyers and sellers measure campaigns?
These are all questions that the advertising ecosystem needs to answer before Chrome finalizes plans to follow Safari and Firefox in maintaining users’ privacy by killing off third-party cookies.
So many alternatives have been proposed for tracking and measuring in a cookieless world. Google, for its part, has proposed the Privacy Sandbox—a series of browser APIs that are intended to secure users’ privacy while also enabling advertising tracking and measurement—which includes Two Uncorrelated Requests, Then Locally-Executed Decision On Victory (TURTLE-DOV).
Criteo submitted a proposal, SPARROW (Secure Private Advertising Remotely Run On Webserver), to the W3C in response to Google’s proposal. Then there was DOVEKEY, proposed by Google to improve upon SPARROW. And now Magnite has another avian-named proposal on the W3C table that intends to improve upon TURTLEDOVE.
We reached out to Garrett McGrath, VP of Product Management at Magnite, to sort out all of these birds so we can figure out how each of them might shape the future of advertising.
Lynne d Johnson: Can you explain PARRROT to me like it was an elevator pitch?
Garrett McGrath: Google’s TURTLEDOVE, part of the Privacy Sandbox proposals authored by Chrome engineers, attempts to maintain retargeting functionality in an environment without third-party cookies and therefore without cross-site tracking as we know it today. TURTLEDOVE aims to accomplish this by centralizing the auction and all component actions within the browser — buyers and sellers only have access to aggregate reporting some number of hours or days after an impression is won. The browser itself becomes a giant black box that only has one key, which belongs to Google.
Whether or not a browser could even computationally handle all of this is an excellent question, to say nothing of this proposal making Google essentially the only ‘trusted’ entity within the programmatic advertising ecosystem.
SPARROW, a TURTLEDOVE counter-proposal from Criteo, maintains the TURTLEDOVE segment management model but recommends moving the auction out of the browser (auctions, like everything else, are handled solely in the browser under TURTLEDOVE), and to some external trusted 3rd-party server called a Gatekeeper.
How an entity qualifies to be a Gatekeeper, how many Gatekeepers there are, and how they are governed are all questions that would need to be answered.
DOVEKEY, also from Google but this time the Ads team, attempts to reduce the complexity of the SPARROW design by using simple key-value pairs to represent audience membership, rather than relying on more complex computations within a browser.
This concept may possibly be workable, however, the likely explosion of key-value pairs necessary to accomplish this at scale and the resources required to manage them are certainly open questions, especially for smaller publishers.
At the heart of all of this is the notion that, starting with TURTLEDOVE, somehow the browser is responsible for actually running the auction(s) and choosing a winner for any given impression. Digging deeper into that statement, this means the browser would have to have all the information necessary to make these decisions — well beyond bid price, which seems to be the primary input for the TURTLEDOVE auction.
A programmatic auction for any given ad impression must consider many more factors beyond bid price. Frequently the highest bid does not necessarily win.
Within the publisher/SSP set-up there exists a long list of contributing factors: ad quality filtering, domain, creative or buyer blocks, prioritization, buying models, pacing, whether or not the impression is eligible for a Deal and if so how that Deal affects the relevance of bid price, regional factors, dayparting, targeting, custom parameters — this list can be quite extensive and can vary greatly pub by pub and impression by impression. As such, TURTLEDOVE as written falls well short of being a workable solution.
PARRROT (The Publisher Auction Responsibility Retention Revision of TurtleDove), from Magnite, maintains the privacy tenets of TURTLEDOVE but moves the auction decisioning back to where it belongs: the publisher.
Leveraging a proposal called the Fenced Frame, PARRROT gives back the publisher and/or the publisher’s systems (ad servers, SSPs) the job of considering the myriad of contributing factors necessary to determine auction outcome. It essentially brings header bidding, or any publisher selected transaction technology, back to this model.
LdJ: How does PARRROT aim to improve upon TURTLEDOVE?
GM: 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.
LdJ: In that regard, how does PARRROT differ from DOVEKEY?
GM: PARRROT is complementary to DOVEKEY (or SPARROW) in that a server-side entity exists outside of the browser in both proposals.
PARRROT extends the key-value store component of DOVEKEY by allowing DSPs to directly and explicitly declare their bidding wishes; otherwise this is theoretically accomplished through Machine Learning in DOVEKEY.
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.
LdJ: There’s been a lot of controversy over whether the gatekeeper should be the browser or a third-party. What would be the benefit of allowing the publisher to retain control of the auction?
GM: Allowing the browser to be the sole repository of audience data or auction mechanics simply isn’t a workable concept — unless you happen to be the owner of that browser.
But 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.
LdJ: Do you see any limitations with any of the proposals, especially in terms of reporting?
GM: Yes, they all have limitations starting with the fact that none of them exist yet and the clock is ticking.
Reporting is an especially big issue since it seems to be marginalized in the Sandbox proposals (most answers are “the aggregate reporting API”, which no one has seen or understands).
However, we need consensus on how and where impressions are transacted before we have the luxury of figuring out how to report on them.