The Topics API for interest signals
The Topics API is a Privacy Sandbox proposal that lets a browser share a handful of coarse interest topics, inferred on-device from recent browsing, with sites and their ad partners — without revealing the underlying browsing history. This page explains the mechanism, its deliberate limits, and why it is not a replacement for per-user analytics.
How Topics works
The browser observes which sites a user visits and maps them to a curated, human-readable taxonomy of topics. Each epoch (a period of roughly a week), it computes the user's top topics on-device. When a caller invokes the API, the browser returns a small number of topics — one per recent epoch — chosen so that the API cannot be used to rebuild a full history.
A caller only receives topics for sites where it was itself present, and a fraction of returned topics are random to provide plausible deniability.
Limits by design
Topics is intentionally coarse: a constrained taxonomy, only a few topics returned, per-epoch rotation, and random noise. It is meant to support interest-based advertising at a privacy-preserving granularity, not to feed precise user-level analytics. Sensitive categories are excluded from the taxonomy, and users can disable the feature.
- On-device inference from a curated topic taxonomy
- Few topics per epoch, with random noise injected
- Sensitive categories excluded; user-controllable
How it appears in analytics and logs
Topics provides a few broad categories per epoch, not a profile. If an integration expects granular interest data, Topics will look sparse by design.
Diagnostic use case
Understand what interest signal Topics actually exposes, so audience planning does not assume access to a user's full browsing history or identity.
What WebmasterID can help detect
WebmasterID does not rely on cross-site interest signals; it measures first-party engagement, so Topics adoption does not change its core counts.
Common mistakes
- Treating Topics as a substitute for full interest profiles.
- Assuming Topics reveals which sites a user visited.
- Expecting stable topics — they rotate per epoch.
Privacy and accuracy notes
Topics is engineered to avoid revealing browsing history or identifying users; it returns coarse categories with deliberate noise. This page is educational and does not endorse re-identification.
Related pages
- Chrome Privacy Sandbox and analytics
The Privacy Sandbox is a set of Chrome web-platform APIs intended to support advertising and measurement use cases without cross-site tracking of individuals. It includes interest-based targeting, conversion measurement, and anti-abuse APIs that return aggregated or noised results rather than per-user identifiers. This page maps the pieces and what they mean for analytics.
- The Protected Audience API
The Protected Audience API (formerly FLEDGE) is a Privacy Sandbox proposal for remarketing and custom-audience advertising that runs the ad auction inside the browser. Interest-group membership is stored on-device and used in a local auction, so a buyer cannot learn which user belongs to which audience across sites. This page explains the model and its measurement implications.
- The Attribution Reporting API
The Attribution Reporting API (ARA) is a Privacy Sandbox API that connects ad clicks or views to later conversions without third-party cookies or cross-site identifiers. It produces two kinds of output — limited, noised event-level reports and aggregatable summary reports processed through an aggregation service. This page explains both and their trade-offs.
- Privacy-first analytics
First-party engagement instead of cross-site interest signals.
Sources and verification notes
- Chrome for Developers — Topics APIOfficial Topics API documentation.
- W3C — Topics API explainer (PATCG / proposal)Specification draft for the API.
Last reviewed 2026-06-24. Facts are checked against primary/official sources where available; uncertain specifics are marked “Data not yet verified” rather than guessed.