- The
datadomecookie is a session credential set by the DataDome bot-protection service on sites that use it, recording that the current session has already been evaluated by the detection engine. - Its value is avoiding a fresh check on every request: judge once, reuse across the session — lower latency, and fewer interruptions for real visitors.
- For classification it is generally treated as strictly necessary / security rather than marketing, because its purpose is defending against automated abuse rather than building an ad profile. It still belongs in your cookie inventory and privacy notice.
- Repeated device checks usually mean the session credential is not persisting between requests — not that the visitor has been judged to be a bot.
What the datadome cookie actually is
DataDome is a real-time bot and online-fraud detection platform that works at the edge: every request entering a site or API is scored for how human — or automated — it looks before it reaches the application. That article covers the engine as a whole; this one zooms in on the piece most people actually encounter first, the cookie.
Here is the engineering problem it solves. A full detection evaluation is not free. It gathers behavioral signals, technical fingerprints and network origin, then runs them through a model. Repeating that for every click, every image request and every API call from the same visitor would be wasteful in both latency and compute.
So the engine uses a familiar pattern: judge once, then reuse the verdict. When a session passes evaluation, the server issues a session credential stored in a cookie. Subsequent requests carry it back, and the edge layer knows this session has already been checked — it can pass the request through without re-running the full evaluation. The datadome cookie is that credential.
Just as important is what it is not. It is not an identifier for building an advertising profile, not a cross-site interest tracker, and not an analytics visitor ID. What it carries is the outcome of a security decision, scoped to the site that set it.
The lifecycle: check, credential, reuse
From a visitor's point of view, the sequence generally runs like this:
- First request — the visitor arrives with no session credential. The edge layer gathers the signals available to it and scores the request.
- The verdict — if the score falls in the allow range, the request simply proceeds. If it lands in the ambiguous range, the engine inserts a device check: a brief interactive or passive verification step.
- Credential issued — once the check passes, the server sets the
datadomecookie, binding that verdict to the current session. - Reuse — later requests carry the cookie back, the edge layer recognizes an already-verified session, and the visitor is not interrupted again.
This explains a common confusion: why some visitors hit the device check over and over. In most cases the reason is not that they were judged to be a bot, but that the credential is not surviving between requests — a browser or extension clearing cookies aggressively, a private browsing mode, a VPN or proxy that switches network egress mid-session, or a corporate network whose traffic profile already resembles automation. Lose the credential and the next request looks like a first request again, so the check repeats.
If real visitors are repeatedly challenged, do not start by blaming the visitors. The more common cause sits on your side: a detection threshold set stricter than your traffic actually warrants, or a cookie scope and attribute configuration that does not match your site structure — multi-subdomain setups are a classic case. This kind of false positive is expensive, because it lands on users who already clicked through.
Privacy, consent and how to classify it
When you run a cookie compliance inventory, the datadome cookie raises a concrete question: which category does it belong to?
The prevailing industry practice is to file security cookies of this kind under strictly necessary, on the grounds that they serve site integrity and abuse prevention rather than marketing. Under most consent frameworks, strictly necessary cookies may be set without prior consent — but that conclusion depends on your jurisdiction, your specific configuration and how regulators are currently interpreting the rules. Have your own counsel confirm it rather than adopting a blog post's classification.
Whichever category it lands in, two things are certain: it must appear in your cookie inventory, and it must be disclosed in your privacy notice. "It is a security cookie" is not a reason to omit it. For the wider consent and data-compliance picture around ad landing pages, see our breakdown of GDPR and CCPA compliance.
One more thing worth noting: the contents of such cookies are typically opaque encoded strings, unreadable even to the site owner. You cannot parse a visitor's score or signal detail out of the cookie value itself — that data lives in the vendor's dashboard. For traffic-quality analysis, your source should be the dashboard and your logs, not an attempt to decode the cookie.
What advertisers should take from this
If you buy traffic, this cookie looks like a technical footnote, but it points at a structural fact that matters: your traffic may already have been filtered by at least one detection layer before it ever reaches your conversion pixel.
That has a few practical consequences:
- Numbers will not line up — the clicks your ad platform reports and the sessions your landing page records were never going to match exactly. Automation filtered at the edge is one legitimate source of that gap.
- False positives are a real cost — an over-strict threshold stops real visitors at a verification step. You paid for that click and then lost the person at the last stage.
- Two layers, two definitions — edge detection and the ad platform's own invalid-traffic judgement use different criteria, so disagreement between them is normal rather than a bug.
To connect these ideas up, two directions are worth following: what invalid traffic actually refers to, and what the scoring logic of different vendor engines has in common — see our comparison of bot detection systems. If click fraud specifically is your concern, see click fraud protection. And for the groundwork on identifying automated visits at all, start with bot traffic detection.
Frequently asked questions
What is the datadome cookie?
It is a session token set by the DataDome bot-protection service on sites that use it. It records that the current browser session has already been evaluated by the detection engine, so the visitor does not have to be re-checked on every subsequent request. It is a security and traffic-integrity mechanism, not an advertising or profiling cookie.
Is the datadome cookie a tracking cookie?
It is generally classified as strictly necessary or a security cookie rather than a marketing cookie, because its purpose is protecting the site against automated abuse rather than building an advertising profile. It is still a cookie that must appear in your cookie inventory and privacy notice, and your own counsel should confirm the classification for your jurisdiction and configuration.
Why do I keep seeing a device check?
Usually the session token is not persisting between requests: a browser or extension clearing cookies aggressively, private browsing, a VPN or proxy changing network origin mid-session, or a corporate network whose traffic profile resembles automated traffic. From the site owner side, it can also mean a detection threshold set more strictly than the traffic warrants.
Can a site owner read the score out of the cookie?
No. The value is typically an opaque encoded string. Scores and signal detail live in the vendor's dashboard and logs — and that, not the cookie, is the data source to use for traffic-quality analysis.
Personalize without the ban risk
Same landing-page URL for every visitor — in-page A/B testing, audience-aware content and invalid-traffic filtering. No cloaking, no sneaky redirects.