WhoTracks.me Documentation

This study provides a detailed performance analysis of popular network request-blocking engines to evaluate their efficiency and address performance concerns related to Manifest V3.

Key findings include:

• All popular content-blockers are highly efficient, with a sub-millisecond median decision time per request.
• The performance-based arguments for Manifest V3 are inaccurate based on these measurements.
• The adblocker used by Cliqz and Ghostery performs as well as or better than other popular engines.
• Blocking ads and trackers can reduce website loading times by up to a factor of 2.

You can use whotracks.me data to measure the market share and prevalence of third-party trackers (especially advertising services) by monitoring two key metrics:

1. reach: The percentage of measured web traffic that the tracker was observed to load.
2. site_reach: The percentage of websites on which the tracker is present.

By ranking trackers by these metrics, you can observe trends in market concentration and how different services respond to regulatory changes like GDPR.

When analyzing tracker data on WhoTracks.Me, it is important to distinguish between two primary metrics:

• reach: The percentage of total page loads where a specific tracker was present.
• site reach: The percentage of unique domains (websites) where a specific tracker was present.

These metrics allow you to differentiate between how often a tracker appears across all traffic versus how many individual websites have integrated it.

Ghostery provides two primary metrics for analyzing website performance and privacy impact:

1. Tracker Count: Ghostery detects third-party trackers by matching URLs from HTTP requests against its database, which contains over 3,000 tracker companies and 4,700 tracker patterns.
2. Page Latency (Load Time): Ghostery measures the time it takes for a page to load using Mozilla’s Window.performance API. It calculates the delta between domContentLoadedEventStart and requestStart.

Users can replicate these measurements by installing the Ghostery browser extension and loading a website to view these metrics directly.

OneTrust is a highly configurable CMP with varying levels of implementation:

• Banner Variability: Some sites show a bottom-of-page banner with a 'More Information' button (e.g., CNN), while others may only provide an 'Accept' option (e.g., express.de).
• Preference Center Variability: The information dialog may or may not allow for opt-outs. Some implementations provide full control over non-essential categories (e.g., MailChimp), while others only provide information without offering opt-out toggles (e.g., CNN).
• UX Behavior: Opt-out is typically instant when available.

The project uses a tracker database to provide metadata for trackers. While it is recommended to get the latest version directly from the upstream TrackerDB project, a snapshot used for the monthly datasets is provided in assets/trackerdb.sql.

This file is a SQLite3 database dump containing the following tables:

• categories: Categories for trackers (e.g. advertising, social_media).
• companies: Metadata on companies, including name, description, and various links.
• trackers: Metadata on trackers, including name, description, category, website, and an optional link to a parent company.
• tracker_domains: Links trackers to their associated domain names.

Online tracking relies on third-party service providers being loaded across many different websites. A tracker can reconstruct a user's browsing history by collecting two key pieces of information:

1. User Identifier (UID): A unique value that identifies the specific client.
2. Referer Header: The address of the first-party page the user is currently visiting.

By aggregating the first-party pages visited for each unique UID, trackers build a comprehensive browsing history. This data can be used to infer browser/OS details, geographical location via IP, or even identify membership in private services (like banking or social media) if the URLs contain Personal Identifiable Information (PII).

A key finding in the study is that only ~19.2% of requests in the dataset are actually blocked.

Takeaway for developers: Content-blockers perform better on average if they can efficiently decide which requests to not block. Optimization efforts should focus on the 'matching' process for allowed requests to minimize latency for the majority of network traffic.

The project provides five primary datasets, each offering a different perspective on tracking activity. Note that trackers.csv, companies.csv, and sites_trackers.csv only include third parties present in TrackerDB. Consequently, summing their totals for a site will likely be less than the value in sites.csv, which includes all observed third parties.

• sites.csv: Statistics for the number of trackers seen on popular websites (keyed on first-party sites).
• sites_trackers.csv: Statistics for each specific tracker on each site (site/tracker association).
• domains.csv: Top third-party domains seen tracking (keyed on third-party domains).
• trackers.csv: Top trackers (aggregates domains operated by the same tracker).
• companies.csv: Top companies (aggregates trackers owned by the same company).

The dataset includes two signals designed to measure the effectiveness of ad-blockers against specific trackers:

• has_blocking: Represents the proportion of pages on which a specific tracker was affected by some form of blocking.
• requests_failed: Represents the average number of failed requests per page load. This is intended to be compared against the total requests count to determine the aggressiveness of the blocking.

Note: As of the December 2017 update, these signals are only available in the raw data and may not yet be visualized on the main website UI.