Tracker Radar is a metadata data set, and its licence rules out commercial use

What a domain record contains

The README is explicit about the framing in its first line: this is not a block list. It is a data set of the most common third party domains on the web with information about their behaviour, classification and ownership, and the stated purpose is to allow custom solutions using the metadata each domain carries.

The metadata list is the substance of the project. Parent entity, so a domain can be resolved to the company that operates it. Prevalence, which is a measurement rather than a flag. Use of fingerprinting. Use of cookies. Privacy policy. Performance.

Each of those changes what you can build. A block list answers one question, whether to block. A record with prevalence and parent entity supports questions like which of the domains on a page are ad networks, which ones are shared across many unrelated sites, and which of them set cookies at all. Fingerprinting and privacy policy are the fields that let you separate analytics vendors from the ones whose business model depends on identifying a device.

The per-domain data lives in the domains directory, and the repository is organised around it, with build-data/, entities/, docs/ and test/ alongside. An entities directory alongside per-domain records suggests the ownership data is maintained as its own structure rather than duplicated into every domain file, which is what you would expect for a data set that has to be updated on a schedule.

The data format is documented separately

Two documents carry the detail the README does not: docs/DATA_MODEL.md for the data format and docs/FAQ.md for questions about Tracker Radar itself.

That division is the right one for a data project. The README tells you what the data means, the data model tells you what each field is, and the FAQ answers the questions a consumer actually asks. If you are writing a parser, the data model document is the file to read first, because the shape of a record is a contract you should not guess at.

The repository also has tests, which is unusual for a data set and says something about how the data is validated. package.json carries a single test script.

"scripts": {
    "test": "mocha --timeout 30000"
}

Mocha with a 30 second timeout, and ajv as the only runtime dependency. So the tests are checking that records conform to a schema rather than comparing against a golden file, and the thirty second timeout is a hint that the validation walks the whole data set.

Build tooling is auto, the conventional JavaScript release tool, driven from.autorc, which matches the dated snapshot releases: 2026.09.21, 2026.08.28 and 2026.07.27. Each release is a dated version of the data rather than a code release.

The tooling that produced the data is separate

The README names the two projects behind the data: the Tracker Radar Collector, which is the code used to build Tracker Radar, and the Tracker Radar Detector, linked separately.

Keeping them out of this repository is the correct boundary. The data set here is the artefact; the collector is the measurement apparatus that regenerates it, and it will carry a different set of dependencies and a different release cadence. If you want to reproduce the data rather than consume it, the collector is where the work happens, and the release tags here tell you which snapshot of the data you have.

It also affects how you should read the fields. Prevalence is whatever the collector measured, and the README does not document the sampling method, the panel composition or the confidence attached to a number. The DuckDuckGo blog post on Tracker Radar is linked for background on that. If your use of the data depends on the exact meaning of a prevalence figure rather than its rough ordering, the collector repository and the blog post are the places to confirm it.

Practically: treat a snapshot as a measurement with a date, not as a permanent fact about a domain. Domains change ownership, change their privacy policy and change their tracking behaviour, and the data is regenerated rather than maintained by hand.

The licence is the binding constraint

The data is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License, and package.json records the same identifier as CCBY-NC-SA 4.0. Copyright is held by Duck Duck Go, Inc. from 2020.

Three words in that identifier carry the practical weight. NonCommercial means the data cannot go into a commercial product as data, including as the engine behind a feature you sell. ShareAlike means a derivative data set has to carry the same terms, so you cannot launder it into a permissive artefact. Attribution means you have to credit the source.

The README handles the first of these directly: if you would like to license the list for commercial use, it asks you to reach out through DuckDuckGo's contact page. That is the path for a company that wants this data in a product, and it is a licence negotiation, not a form.

The point is worth stating plainly because it surprises people: this repository is often mistaken for a freely usable block list because the data is public and free to download. Downloading is not the same as being licensed to redistribute commercially, and the distinction is decided by the LICENSE file rather than by the price.

How this differs from a block list and from a tracker database

A block list is a set of domains to stop. Tracker Radar is a set of domains with attributes, and the README's refusal to call itself a block list is the whole point of the design.

The difference shows in what you can do after you load it. Because each record has a parent entity, you can write a policy that blocks one company's domains across all its brands rather than a list maintained domain by domain. Because it has prevalence, you can prioritise by how widely a domain is embedded. Because it records fingerprinting and cookie use, you can separate the requests that identify the user from the ones that merely serve an asset. Performance is there for the case where a third party is slow enough to be worth blocking on its own merits.

Against other third-party databases, the honest comparison is that this one is published on a dated schedule with a documented model and a permissive-enough licence for non-commercial research, which is not what commercial intelligence products offer. What it does not offer is documented methodology in the repository itself, so for a product decision you would be relying on a public blog post and the collector's code rather than on a vendor contract.

The trade is coverage against certainty: this data is broad and free of charge, and it carries the licensing and the sampling questions that come with that.

Editorial conclusion

Adopt Tracker Radar if you are building research tooling, a browser extension or a non-commercial privacy feature and you want per-domain context rather than a boolean block list, since prevalence, parent entity and fingerprinting flags are what the data actually offers. Do not adopt it to ship the list inside a commercial product or a block list sold as such: the data is licensed CC BY-NC-SA 4.0, and the README directs commercial licensing requests to DuckDuckGo's contact page. Verify first which domains you need are present under domains/ and whether their metadata is populated, since coverage is a measurement artefact rather than a guarantee, then read docs/DATA_MODEL.md before parsing the format. Releases are dated snapshots such as 2026.09.21, so pin a snapshot rather than tracking main, and keep the collector and detector repositories in view if you intend to regenerate anything yourself.

Frequently asked questions

Official sources

1. duckduckgo/tracker-radar on GitHub
2. Issues
3. README
4. Releases