Federated Learning of Cohorts (FLoC) was a Google Privacy Sandbox proposal designed to replace third-party cookies by assigning users to large, interest-based cohorts using on-device machine learning. The browser analyzed local history to generate a cohort ID representing thousands of users with similar browsing patterns, which was then shared with advertisers for interest-based targeting without revealing individual site visits.
Glossary
Federated Learning of Cohorts (FLoC)

What is Federated Learning of Cohorts (FLoC)?
A deprecated browser-based targeting mechanism that grouped users into large interest-based cohorts on-device, aiming to enable interest-based advertising without exposing individual browsing history to third parties.
FLoC was deprecated in 2022 and replaced by the Topics API due to significant privacy concerns, including fingerprinting risks and the potential for cohorts to inadvertently reveal sensitive categories. Unlike FLoC's unsupervised clustering, the Topics API infers a limited set of high-level interest categories from recent history, providing a more transparent and privacy-preserving mechanism for post-cookie advertising.
Key Architectural Features of FLoC
Federated Learning of Cohorts (FLoC) was a Privacy Sandbox proposal designed to enable interest-based advertising without third-party cookies. The architecture shifted the processing of browsing history to the client device, grouping users into large cohorts to obscure individual identity. Although deprecated in favor of the Topics API, its architectural principles remain instructive for privacy-preserving computation.
On-Device Clustering
The core privacy innovation of FLoC was moving the clustering algorithm to the browser. Instead of a central server collecting raw browsing history, the SimHash algorithm ran locally. The browser computed a compact, lossy representation of the user's history and assigned a Cohort ID based on this hash. This ensured that granular URL-level data never left the device, adhering to the principle of data minimization.
SimHash Locality-Sensitive Hashing
FLoC relied on Locality-Sensitive Hashing (LSH) , specifically SimHash, to group similar browsing behaviors. Key properties include:
- Dimensionality Reduction: High-dimensional browsing vectors were compressed into a low-bit fingerprint.
- Cosine Similarity: The Hamming distance between two SimHash values approximated the cosine similarity of their original history vectors.
- Fuzzy Matching: This allowed users with similar, but not identical, interests to land in the same cohort, creating the necessary anonymity set.
Cohort Assignment & k-Anonymity
A central server maintained a list of valid, public cohorts, but the browser made the final assignment decision. To prevent fingerprinting, the API enforced a k-anonymity constraint. A cohort was only exposed to advertisers if it contained a minimum threshold of distinct users (e.g., thousands). If a user's calculated cohort was too small, the browser would either suppress the ID or assign a more general, larger cohort, preventing the creation of micro-groups that could identify individuals.
Cohort Rotation & Temporal Decay
To prevent long-term tracking via a static ID, FLoC implemented strict temporal dynamics:
- Weekly Recalculation: The browser recalculated the cohort assignment every 7 days based on the recent history window.
- History Windowing: Only a sliding window of recent browsing data was used, preventing a user's entire lifetime history from defining their cohort.
- Anti-Fingerprinting: The rotation logic ensured that a user's ID changed frequently enough to prevent it from becoming a persistent, stable identifier.
Sensitive Category Filtering
The browser applied a local sensitive category blocklist before calculating the SimHash. Domains associated with sensitive topics—such as medical conditions, religious beliefs, or sexual orientation—were automatically excluded from the clustering input. This was a critical architectural safeguard to ensure that cohort assignment did not inadvertently reveal protected characteristics, aligning with differential privacy goals and anti-discrimination regulations.
Deprecation & Transition to Topics API
FLoC was deprecated due to concerns over fingerprinting entropy and the potential for cohorts to be combined with other signals (like IP address) to re-identify individuals. It was replaced by the Topics API, which uses a fundamentally different architecture:
- Taxonomy-Based: Instead of unsupervised clustering, Topics maps history to a fixed, human-curated taxonomy of ~350 interest categories.
- Random Noise Injection: Topics introduces 5% random noise to provide plausible deniability.
- On-Device Inference: A lightweight classifier runs locally, eliminating the need for a central cohort list.
Frequently Asked Questions
Clear, technical answers to the most common questions about Google's deprecated Federated Learning of Cohorts proposal and its implications for identity resolution and ad-tech.
Federated Learning of Cohorts (FLoC) was a Privacy Sandbox proposal designed to enable interest-based advertising without exposing individual browsing history. The mechanism operated entirely on-device within the Chrome browser. The browser would analyze a user's local web history and, using a clustering algorithm, assign them to a large cohort of thousands of users with similar browsing patterns. Only this high-level Cohort ID—a number representing a group interest, not an individual profile—was exposed to advertisers via an API. The core premise was to hide the individual 'in the crowd' by ensuring each cohort met a k-anonymity threshold, preventing the re-identification of single users while still allowing contextual and interest-based ad targeting without third-party cookies.
FLoC vs. Topics API vs. Third-Party Cookies
A technical comparison of browser-based interest advertising mechanisms, contrasting Google's deprecated FLoC proposal, the current Topics API, and legacy third-party cookies across privacy, architecture, and utility dimensions.
| Feature | FLoC | Topics API | Third-Party Cookies |
|---|---|---|---|
Current Status | Deprecated (2022) | Active (Chrome 115+) | Phasing Out (2024-2025) |
Grouping Mechanism | Unsupervised clustering (SimHash) | Browser-inferred topic taxonomy | Cross-site tracking via unique ID |
Granularity | Cohort ID (thousands of users) | Top 5 weekly topics per user | Individual browsing history |
Data Processing Location | On-device only | On-device only | Third-party servers |
k-Anonymity Guarantee | |||
Fingerprinting Risk | Moderate (cohort entropy) | Low (limited bits of info) | High (persistent identifier) |
Cross-Context Exposure | Cohort ID visible to all sites | Different topics per site (randomized) | Full tracking across all sites |
User Opt-Out Mechanism | Privacy Sandbox toggle | Browser settings + per-site block | Cookie deletion + browser blocks |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Related Terms
FLoC was a specific proposal within a broader ecosystem of privacy-preserving advertising and identity technologies. These related terms provide context on the alternatives and underlying concepts that define the post-third-party-cookie landscape.

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us