Last Updated on: 20th December 2023, 09:00 am
Google has released an article announcing the availability of Bidding and Auction services in the web version of FLEDGE, as well as the status on pending FLEDGE capabilities. These two Google releases could have a major impact on the adoption of FLEDGE in the near future.
Table of Contents:
- What has Google actually released?
- What this means for the advertising ecosystem
- Google release—what RTB House thinks about these changes
- RTB House predictions on the near future
What has Google actually released?
Starting mid-2023, Google Chrome will begin testing its Bidding and Auction services on the web platform, with the goal of scaling them by the end of 2023. In short, Bidding and Auction services will move a part of the FLEDGE workflow, including the auction process, from the Chrome browser on the user’s device to the Trusted Execution Environment (TEE) on a public cloud platform. Until now, this approach was dedicated to the Android Privacy Sandbox, so this brings both ecosystems even closer together. Bidding and Auction services also support both single-seller and multi-seller auctions, which is especially crucial to ensure a fair advertising ecosystem.
In addition to this, the company has also outlined several key timeline updates:
- Event-level auction win reporting will be supported until at least 2026
- The use of TEE for Key/Value service will be required no sooner than Q3 2025
- Fenced frames will also be required no sooner than 2026
- The availability of integration between FLEDGE and Attribution Reporting is expected for Q2 2023
- K-anonymity requirements will be available for testing soon, to prepare for enforcement later in 2023
Despite the abundance of news being released, Google specifically emphasized that the overall timeline for the Privacy Sandbox and third-party cookies deprecation remains the same.
What this means for the advertising ecosystem
Google’s post does not seem to bring many changes, while in reality, the consequences for the advertising industry are far-reaching.
Firstly, it is clear that AdTech vendors have to start updating their reporting mechanisms for FLEDGE reporting. Even though event-level reporting will be preserved for the next few years, it is inevitable that the aggregated reporting approach will eventually be the new standard. It is also related to the fact that the Attribution Reporting for FLEDGE will initially work in both Fenced Frames and iframes. This could accelerate the adoption of the reporting API, as it will be easier for AdTech to start by using iframes, a technology they are familiar with.
Even though iframes are allowed by the Chrome browser for FLEDGE until 2026, some sellers (SSPs) may still require using Fenced Frames when interacting with this API. It means that AdTech vendors cannot just relax and wait until 2026 to start working on Fenced Frames adoption. It’s the same for the Key/Value signals server, which can still be hosted by the AdTech vendor until the mandatory transition to TEE in late 2025. This schedule is favorable for adoption, but it does not remove the eventual requirement.
Next comes the k-anonymity parameter. Until now, it was unclear what the k-anonymity parameter would actually be. In the recent post, Google shared that “For rendering creatives, the k-anonymity threshold of ‘a crowd of 50 users per creative over 7 days’ must be met.” Now the work is on the AdTech vendors to provide feedback on whether this number allows for the proper personalization of ads.
Lastly, even though the Bidding and Auction services will be available soon, on-device auctions will still be supported. Google’s rationale for bringing cloud-based auctions is focused on improving the on-device latency of FLEDGE. Moving some computations away from the user’s device to a cloud-based infrastructure should help. However, if the latency of the on-device workflow proves good enough, this workflow can still be used. Both of these approaches should be thoroughly tested by the advertising companies, and feedback should be submitted.
Google release—what RTB House thinks about these changes
Being a leading Privacy Sandbox contributor and tester, RTB House is far from being surprised by the recent developments. We have managed to foresee most of these, and it’s satisfying to see Google follow the recommendations from the advertising community (including RTB House’s).
We believe that the recent announcements will help accelerate the adoption on the market. The possibility of displaying FLEDGE ads in iframes and using a proprietary K/V server is a much-needed simplification of integration for many market players. The introduction of Bidding and Auction services also brings web-based FLEDGE closer to its Android relative, which is another key piece to make adoption easier. At the same time, we acknowledge that only when Fenced Frames and TEE-based K/V servers are implemented can we talk about the fulfillment of all privacy promises by FLEDGE.
On the other hand, up until now, FLEDGE has been perceived as a difficult-to-implement API in contrast to the very simple Topics API. The recent criticism around Topics and, at the same time, the simplification of FLEDGE may lead to a big shift in the market’s perception of this proposal. A few favorable articles about FLEDGE have recently been published in advertising media, such as the recent Adweek piece. We believe that this trend will continue, especially since FLEDGE API provides much more utility for advertising use cases in comparison to Topics API.
Most importantly, we are pleased that despite the short-term simplifications, Google has not backtracked on the end goal of making FLEDGE a privacy-preserving advertising API working in a sandbox environment where both the user data and AdTech’s bidding data cannot be shared with third parties.
What’s ahead for Topics API? It is difficult to predict. In recent months it’s become clear that this proposal has failed to deliver on its promised utility and privacy. However, what if Google took a step back and revived the FLoC approach? The original idea was much more powerful for advertising. Its main drawback was that it could fuel fingerprinting mechanisms for user reidentification due to FLoC signals being sent in parallel to contextual data. A lot has changed in the Privacy Sandbox since then, especially in FLEDGE. What if FLoC was moved to an isolated FLEDGE environment so that data would not leak to third-party servers? Perhaps it’s an idea worth rethinking?
RTB House predictions on the near future
Obviously, the first expectation is around Google’s delivery of the promised features. The integration between Attribution Reporting API and FLEDGE, k-anonymity verification, and cloud-based Bidding and Auction services sounds good, but we need to validate them in practice.
In the meantime, we are waiting for a standardized framework for testing FLEDGE’s performance, which will help guide testers on what to do in the second half of 2023. This effort is coordinated by the UK’s CMA, and the initial document has already been released. However, the conclusions from the market feedback and the final report are yet to be published.
Lastly, we expect more companies to join the FLEDGE testing. As a recap, in September, we reported that only three companies had been testing FLEDGE: Google, Criteo, and RTB House. Since then, we have observed new participants joining, such as Amazon and Teads. Last week’s announcements lowered the barriers of entry for many more players. The arguments around the lack of clarity about what to implement or the difficulty of integration have been significantly weakened.
If you have any questions, comments or issues, or you’re interested in meeting with us, please get in touch.
