What are Google’s FLoC & FLEDGE Updates - Time to Prepare
Important Note: As of January 25th, 2022 - Google has announced the discontinuation of FLoC and FLEDGE - proposing instead to replace the program with a new approach called "Topics" - read more here.
In many ways, the information below is still relevant, and may still be worth review if you're unfamiliar with Google's original plan.
Despite Google updating their Privacy Sandbox timeline to extend the use of third-party cookies into late 2023, the attention of the AdTech world remains firmly on the state of online privacy and Google’s next move.
The way online advertising is conducted is set to radically shift pending two major changes to the internet’s most used web browser with Google’s FLoC & FLEDGE updates.
These two updates are both part of a Google project known as the Privacy Sandbox – a “test environment” in which solutions that address online privacy concerns are being developed.
This post provides a summary of what each update is all about – and more importantly, what you can do to prepare for them.
Table of Contents
- What is Google’s FLoC?
- What is Google’s FLEDGE?
- Criticism surrounding FLoC & FLEDGE
- How publishers and advertisers can prepare
What is Google’s FLoC?
FLoC (Federated Learning of Cohorts) is a web tracking solution in development by Google which will replace the use of third-party cookies with interest-based cohorts.
A “cohort” is simply the term used to describe a group of anonymous users which are confirmed to possess a set of particular interests.
In other words, cohorts themselves are a series of identifiable, interest-based actions, which are separated entirely from the specific identities of the users performing those actions.
FLoC aims to allow advertisers to target cohorts with ads, without compromising the personal details or privacy of the users being served those ads.
How does FLoC contribute to cookieless advertising?
Digital advertising has traditionally been dependent on third-party cookies to identify specific users and their interests.
With the end of third party cookies approaching rapidly, publishers and advertisers alike have been scrambling to make a pivot to privacy-friendly ad serving techniques.
In response, one of the most popular techniques making a resurgence across the digital advertising space is contextual advertising.
As a technique, contextual advertising involves serving advertisements to websites which are contextually tagged to indicate the “context” of their composition – or in other words, what topics the website focuses on.
Advertisements about cars are served to car websites, while cooking and food advertisements are matched to websites that create culinary, diet, and lifestyle content.
You may have realised that this description sounds strangely similar to the way Google’s FLoC update works – and that’s because they both share the same objectives and functions.
FLoC is Google’s way of allowing advertisers to continue serving effective and contextually relevant ads through its platforms without compromising user privacy.
What is Google’s FLEDGE?
FLEDGE (First Locally-Executed Decision over Groups Experiment) is Google’s latest Sandbox update that seeks to put into practice the original TURTLEDOVE API framework.
The framework works in a similar way to FLoC, allowing the owner of a website to assign the web browser of a visitor to an “interest group”.
An “interest group” can be created and managed by anyone, including website owners or parties like DSPs (demand-side platforms).
How and why FLEDGE was developed
You may want to duck (quack), as a large floc (ha) of bird acronyms are flying straight your way.
TURTLEDOVE (Two Uncorrelated Requests, Then Locally-Executed Decision On Victory) was originally a framework which proposed that all ad auction decisions should take place in the web browser, rather than within ad servers.
The purpose of TURTLEDOVE was to improve data security by alleviating the need to have customer data pass through ad servers.
The primary difficulty with implementing TURTLEDOVE was the bandwidth requirement associated with shifting the large amount of ad auction activity into the web browser itself.
SPARROW (Secure Private Advertising Remotely Run On Webserver) later proposed to introduce a “gatekeeper”, rather than an ad server, to facilitate the ad auctions.
The SPARROW proposal would address the bandwidth requirement by introducing a dedicated “third-party” which would exclusively manage all of the ad auction activity.
However, this proposal was more or less rejected, due to the difficulty of entrusting any single company entity with the role of acting as the “gatekeeper”.
Dovekey (no acronym this time around) improved upon SPARROW by introducing the concept of a “key value server” – which would act as a simplified version of an ad server with basic lookup table functionalities.
The “key value server” would be run by a third-party company (instead of, for example, Google themselves), and be capable of receiving contextual ad signals and interest groups, while returning associated bid values for those signals.
In other words, ad auction activity and its associated user data would effectively be redirected to the “key value server” – instead of to an ad server owned by a publisher.
This diagram illustrates what the full process of serving a contextual ad using the Dovekey framework looks like:
(Source: Google/GitHub)
If the diagram above looks more like an equation for launching a rocket ship than serving an ad, you may be interested to learn about how SSPs, DSPs and ad servers work together to manage an ad call (or “ad request”) through the guide – What is an Ad Server?
If you’d like to fly the coop for more info about how we got to the modern version FLEDGE, an article by Digiday, aptly named “WTF Is Dovekey”, contains the full technical details surrounding how the TURTLEDOVE project has evolved over time.
How does FLEDGE contribute to cookieless advertising?
FLEDGE’s contribution to cookieless advertising comes in the form of a privacy-friendly replacement to retargeting – a popular advertising technique in which users that visit or engage with a certain brand or website are “retargeted” with ads from those platforms.
As an example of how FLEDGE works, a user may visit a publisher’s blog about cars, and click through to an article about high-performance sports cars.
Upon doing so, the user’s browser might be assigned to a “cars_sports” interest group.
If the further clicks through to a specific make of sports car, the user’s browser might have its assignment updated to a “{brand}_cars_sports” interest group.
When a user clicks through to a website, a bidding process takes place over which ad to be displayed, based on the interest groups assigned to the user’s web browser.
Through the use of a newly developed “Fenced-Frame HTML component”, publishers are unable to identify information about other interest groups assigned to the web browser, or details about the ad being served to it.
Similarly, advertisers are unable to discern which site their ad was served to – instead, receiving only a confirmation of which interest group qualified the ad to be served.
This allows various ad serving parties to retarget a user’s browser with ads that are relevant to their past browsing activity, without compromising their privacy as an individual.
Criticism surrounding FLoC & FLEDGE
Despite all of their pro-privacy feature proposals, both FLoC and FLEDGE have come under criticism by various parties online.
The arguments for and against Google’s latest Privacy Sandbox updates have made it a somewhat controversial subject.
So, why is FLoC considered a bad idea?
In a publication by Dr. Augustine Fou, attention is drawn to the numerous ways in which FLoC seems to undermine privacy, rather than amplify its integrity.
It’s suggested that FLoC cohort IDs and FLEDGE interest group IDs will do little more than add an additional layer of tracking to the internet – benefiting only Google and its users.
Google’s track record of misleading documentation that subverts the true functionality of its products is also called into question within the article.
These sentiments are shared by founders and spokespeople from other web browser platforms, including Brave, DuckDuckGo, and Vivaldi.
A post titled “Why Brave Disables FLoC” contains more details about the general stance of these web browsing platforms on Google’s proposed updates.
Similarly, many marketers and analysts are both skeptical and worried about the updates.
After all, with a lack of transparency into the nature of how and where ads are being served to end users, many analytics implementations and ad ops personnel will be left with little to no way to properly gauge ad effectiveness.
While Google may still make adjustments to their proposals (it’s all part of a testing sandbox, after all) – with about 65.27% of the internet using the Chrome web browser at the time of writing, it’s best to be prepared for whatever changes may be flying towards us in the future.
How publishers & advertisers can prepare
When it comes to preparing for Google’s FLoC & FLEDGE updates, contextual advertising and direct deals are the name of the game.
Publishers will want to structure and tag the content of their web properties to align with Google’s new contextual IDs.
Publishers may also find it beneficial to familiarize themselves with the FLoC API by participating in Google’s FLoC Origin Trial.
Advertisers who value in-depth analytics surrounding their ad engagements will want to begin establishing direct deals with relevant and trusted publishers more than ever.
Direct deals which include custom reporting based on a publisher’s first-party data may soon become one of the few ways to access granular analytics surrounding served ads.
Interested in more ways to improve your ad serving strategy?
We’d love to share a conversation with you. Ask us a question today!
