For those who thought the conversation around third-party cookie deprecation couldn't get more complicated, in steps Microsoft Edge with their latest contribution: Ad Selection API.
Ad Selection API is an alternative to Google's Protected Audience API, which is a proposal that facilitates retargeting and custom audience targeting without third-party cookies.
Before we explore the Ad Selection API, we must review Microsoft's participation in the Privacy Sandbox to establish context.
PARAKEET vs. FLEDGE
Around the same time TURTLEDOVE was migrating to become FLEDGE, Microsoft released its own Privacy Sandbox proposal to the world with PARAKEET. FLEDGE and PARAKEET were broadly seen as two competing proposals equally likely to make it into the final form of whatever the Privacy Sandbox became.
Microsoft built PARAKEET on the same principle as Ad Selection API — that no new advertising technology should process auctions on the user's device due to performance concerns and that the disruption to ad tech companies following third-party cookie deprecation should be kept to a minimum.
However, Microsoft soon recognized that parts of PARAKEET were impractical, so it began working on different iterations of its proposal, largely unseen by the industry and the web community. At the same time, Microsoft also started to make serious investments into confidential computing, or so-called Trusted Execution Environments.
During this period, Google Chrome accelerated (with regular intermissions) its Privacy Sandbox program, and FLEDGE (now named Protected Audience API) became the clear front-runner in the race to be the privacy-preserving targeting solution of the future (at least in Chrome).
However, as Microsoft developed its proposal, it noticed several gaps and potential problems with the Protected Audience API and consequently released the Ad Selection API into the wild.
But what is the Ad Selection API, and how does it differ from the Protected Audience API?
What is Ad Selection API?
In many ways, Ad Selection is very similar to Protected Audience. For example, it will share the same API surface (to the relief of publishers and SSPs alike) — which is the part of an API that others can see and interact with. This choice was deliberate and required to reduce unnecessary friction in adoption.
However, on the back end, there are a couple of relatively small but crucial differences:
- Auctions run in Trusted Execution Environments (TEEs)
The right place to conduct processor-heavy ad auctions and bidding functions is on the server side. Neither the user nor the publisher should pay the price for the complexity of optimization algorithms that drive the ad tech industry. That's why the Ad Selection API will leverage TEEs for the bidding and auction processes.
By moving the ad auction server-side, the Ad Selection API can lower the time it takes to complete an auction and deliver a winning ad compared to the Protected Audience API.
- Data owners can merge interest groups
With Ad Selection API, data owners can merge their Interest Groups (the Privacy Sandbox version of audience segments) before bidding begins, which is impossible in Protected Audience API.
But why is it important to merge interest groups?
Bidding platforms typically assess all the segments a user belongs to before dynamically choosing the optimal creative to serve. Evaluating all the audiences a user belongs to leads to performance enhancement of creative selection — improving advertiser ROIs and maximizing the potential value of each user.
Google decided to drastically restrict the cross-site use of any information on a user, at least on the demand side. This means that if a bidder is bidding on an interest group, they must create bids based on those groups in isolation.
This quirk may lead to a dip in performance, and Microsoft wants to avoid this eventuality.
Merging interest groups will allow data owners to maximize their understanding of their audiences and optimize bidding algorithms effectively.
However, privacy is paramount for Microsoft. So, although merging interest groups will be supported, core privacy safeguards, such as encryption, k-anonymity, and domain-based partitioning, will remain firmly in place —ensuring that privacy standards remain robust despite the merging of interest groups.
It is unlikely that we will collectively figure out how to replicate every ad tech use case today in a world without third-party cookies. However, the IAB Tech Lab recently highlighted some use cases that need to be sufficiently accounted for by the Protected Audience API. Microsoft looks to address some of those before we take irreversible steps toward third-party cookie deprecation.
What's next for the Ad Selection API?
Publishers and ad platforms can now evaluate the Ad Selection API and see if these benefits over the Protected Audience API hold in practice.
Complaints of latency from publishers testing the Protected Audience API are beginning to surface. Latency results in lost impressions and negatively impacts other KPIs like viewability.
The promise of addressing this latency issue alone may drive the industry to take a hard look at the Ad Selection API over the Protected Audiences API.
The Ad Selection API will be available for testing in Microsoft's Edge browser in the second half of 2024.
If the potential benefits gained from the Ad Selection API are there, it could force Google's hand to incorporate some of its features into the Privacy Sandbox.