🤖 machine learning

AdFL: In-Browser Federated Learning for Online Advertisement

This paper introduces AdFL, a browser-based Federated Learning framework that enables online publishers to train global models for targeted advertising using local user data without compromising privacy, achieving high prediction accuracy (up to 92.59% AUC) while maintaining performance even with differential privacy safeguards.

Original authors: Ahmad Alemari, Pritam Sen, Cristian Borcea

Published 2026-02-09

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Ahmad Alemari, Pritam Sen, Cristian Borcea

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine the internet is a giant, bustling marketplace. In this marketplace, publishers (like news websites) want to show you ads to make money, and advertisers want to show you ads that match your interests.

For a long time, the way this worked was like a spy game: to show you the right ad, the website had to send a copy of your personal diary (your browsing history, what you clicked, how long you stayed) to a central office. This raised privacy alarms, leading to new laws (like GDPR) that say, "Stop sending people's diaries around without permission."

AdFL is a new invention that solves this problem. It's like a mobile classroom that happens inside your web browser.

Here is how it works, using simple analogies:

1. The "No-Spy" Classroom (Federated Learning)

Instead of sending your diary to a central office, AdFL brings the teacher to your house.

The Old Way: You mail your diary to the school principal. The principal reads it, learns what you like, and then tells all the teachers.
The AdFL Way: The teacher (the AI model) comes to your house (your browser). It reads your diary right there, learns what you like, and then only sends back a summary of what it learned (like "Students who like cars also like sports"). It throws away the diary immediately. The teacher never sees your raw data, and your data never leaves your computer.

2. The "In-Browser" Workshop

The paper describes AdFL as a system that runs entirely inside your web browser (like Chrome or Safari). You don't need to install any special apps or software.

The Metaphor: Think of your browser as a workshop. When you visit a website, the AdFL system quietly sets up a small workbench inside that workshop.
The Tools: It uses standard tools that every modern browser already has (like "MutationObserver," which is just a fancy way of saying "a watchful eye that notices when something changes on the page").
The Job: This workbench watches the ads as they load. It measures things like:
- Did the ad actually appear on your screen? (Viewability)
- Did you look at it? (Dwell time)
- Did you click it?

3. The "Global Brain"

Once the teacher (the AI) learns from your local workshop, it sends its "lesson notes" (model updates) back to the publisher's server.

The Aggregation: The publisher takes lesson notes from thousands of different students (users) and mixes them together to create a Super-Teacher (a global model).
The Result: This Super-Teacher is then sent back to everyone's browsers. Now, every browser has a smarter teacher that knows how to pick better ads for everyone, without anyone ever having shared their private diary.

4. Why This Matters (The "Viewability" Test)

The researchers built a specific test model to see if this works. They asked: "Can this system predict if an ad will actually be seen by a user?"

The Analogy: Imagine a billboard. If it's hidden behind a tree, no one sees it, and the advertiser wastes money. AdFL tries to predict if the "tree" (your screen size, scrolling speed, etc.) will block the ad.
The Speed: The system is incredibly fast. It does its math in milliseconds (faster than a blink). It doesn't slow down your computer or drain your battery.
The Privacy Shield: They even tested a "privacy armor" called Differential Privacy. This adds a little bit of "static noise" to the lesson notes so that even if someone tries to reverse-engineer the notes, they can't figure out exactly what you did. The paper found that this armor works well, with only a tiny drop in how smart the teacher becomes.

The Bottom Line

The paper claims that AdFL is a working prototype that:

Protects Privacy: Your personal data stays on your device.
Saves Money for Publishers: It helps show ads that people actually see, which means publishers make more money.
Works Fast: It runs in the background without making your browser slow.
Needs No Installation: It uses the tools your browser already has.

In short, AdFL is a way to have your cake (targeted ads that work) and eat it too (keeping your private browsing history completely private).

Technical Summary: AdFL – In-Browser Federated Learning for Online Advertisement

Problem Statement

The online publishing ecosystem faces a critical tension between the need for targeted advertising revenue and increasing user privacy regulations (e.g., GDPR, CCPA). Traditional data-sharing practices, which send user behavioral data to external ad agencies, are increasingly restricted, forcing publishers to rely on less effective contextual ads. Existing Federated Learning (FL) solutions for advertising face significant integration hurdles:

Architectural Complexity: Some proposals require hierarchical server structures that do not integrate seamlessly with existing ad servers (e.g., Google Ads Manager) which rely on key-value bid structures rather than embeddings.
Data Dependencies: Vertical FL approaches often require cooperation with advertisers and access to external conversion data not available within the browser.
Browser Limitations: Existing in-browser FL frameworks often lack specific support for ad metrics, fail to perform real-time data collection, or are computationally too expensive for the constrained duration of a user's visit.

The core challenge is to enable targeted advertising that respects user privacy by keeping raw data on the user's device while maintaining the low latency and high efficiency required for real-time ad serving.

Methodology: AdFL Framework

AdFL is a horizontal FL framework designed to operate entirely within the user's web browser. It enables the training of global models using local user data without the data ever leaving the browser.

System Architecture

The system consists of two primary entities:

AdFL Server (Publisher-side): Hosts the global model and coordinates the learning process. It manages model versioning and aggregates local updates.
AdFL Client (Browser-side): A JavaScript-based client that runs asynchronously alongside online ads. It handles data collection, preprocessing, local model training, and inference.

Client Components

The AdFL client is composed of five modular components implemented using standard browser APIs (e.g., MutationObserver, IndexedDB, TensorFlow.js):

Session Manager (SM): Manages the lifecycle of the client, handles loading/unloading of components, and oversees browser storage (IndexedDB).
Data Collector (DC): Captures contextual data (user agent, OS, URL, page content) and session history. It aggregates features from current and past sessions to build a complete user-page pattern.
Ad Utility (AdU): Specifically designed to capture ad-specific metrics in real-time as ads load. It tracks viewability, click-through, and attention metrics. It triggers model inference to adjust ad behavior (e.g., modifying refresh rates) based on predictions.
Data Preprocessing and Storage (DPS): Preprocesses raw data using techniques like MinMax scaling and hash encoding. It ensures consistent feature representation across clients and manages the storage of processed data samples.
Model Utility (MU): Handles model loading, training, and inference. It manages configuration parameters, optimizes for device constraints (memory, battery), and executes the training loop.

Workflow

Initialization: Upon page load, the SM downloads AdFL scripts and initializes storage.
Data Collection: The DC and AdU collect contextual and ad-specific data, respectively.
Preprocessing: The DPS processes raw data into feature vectors.
Inference: For each ad load, the MU performs inference to predict metrics (e.g., viewability). The AdU uses these predictions to dynamically adjust ad display parameters (e.g., extending or shortening ad duration).
Training: Periodically, the MU trains the local model on accumulated data.
Aggregation: Local model parameters are uploaded to the AdFL server. The server aggregates them using FedAvg (weighted by dataset size) to update the global model, which is then redistributed to clients.

Privacy and Security

Data Locality: Raw user data never leaves the browser.
Threat Model: Assumes an "honest-but-curious" server that follows the protocol but may attempt to infer user behavior from model updates.
Mitigation: The framework supports Differential Privacy (DP) to add noise to local model updates, protecting against gradient-based inference attacks.

Key Contributions

AdFL Framework: A novel, end-to-end FL system designed specifically for the browser environment, enabling seamless local data collection, preprocessing, and model training for online ads without requiring client-side software installation.
Ad Viewability Prediction Model: A proof-of-concept model built on top of AdFL that predicts ad viewability. It utilizes a lightweight neural network architecture capable of handling dynamic input features and running efficiently on resource-constrained devices.
Prototype Implementation: A fully functional prototype demonstrating real-time ad data collection and effective FL training using standard browser APIs (TensorFlow.js, IndexedDB) and first-party cookies, avoiding the need for third-party cookies.

Experimental Results

The authors evaluated AdFL using two non-overlapping datasets (10-day and 30-day periods) from a publisher website with ~40,000 daily visitors.

Performance and Latency

Latency: The system operates with low latency suitable for real-time ad serving.
- Inference: < 3ms on desktop, < 7ms on mobile.
- Preprocessing: ~40ms on desktop, ~50ms on mobile.
- Training: ~378ms per round on desktop, ~469ms on mobile.
Memory Overhead: The system consumes approximately 50MB of JavaScript memory initially, rising to ~230MB (desktop) and ~198MB (mobile) after training and inference, which is feasible for modern devices.

Model Accuracy

Viewability Prediction: The FL model achieved an Area Under the Curve (AUC) of up to 92.59% on the 30-day dataset.
FL vs. Centralized Learning (CL): The FL model's performance was comparable to a centralized model, with only modest declines (e.g., 87.36% AUC for FL vs. 89.19% for CL in a 50-user setting).
Differential Privacy: Applying DP (with noise $\epsilon$ ranging from 0.1 to 1.0) resulted in only modest performance reductions compared to the non-DP variant, demonstrating that privacy safeguards can be implemented with acceptable trade-offs.

Feature Importance

Using SHAP analysis, the study identified that ad-specific features (e.g., ad dimensions, placement) and customized metrics were the most significant contributors to model performance, validating the importance of the AdFL client's specific data collection capabilities.

Significance and Claims

The paper positions AdFL as a practical solution to the "privacy vs. revenue" dilemma in online advertising. Its significance lies in:

Feasibility: Demonstrating that complex FL pipelines can run efficiently within the constraints of a web browser without requiring user software installation.
Privacy Preservation: Offering a mechanism for publishers to utilize user data for targeted advertising while keeping raw data local and compliant with privacy regulations.
Revenue Optimization: Showing that privacy-preserving models can achieve high accuracy (up to 92.59% AUC), potentially allowing publishers to maintain revenue levels close to those of centralized, non-privacy-preserving systems.

The authors conclude that AdFL represents a promising step toward balancing user privacy with publisher revenue, providing a viable alternative to current data-sharing practices and ad-blocking workarounds.