Skip to main content

What Is demdex.net? The Adobe Cookies in Your Audit

If you have run a cookie audit, a CMP scan or a privacy report on your own site, demdex.net is one of the domains that turns up without an obvious owner. It is Adobe.

Specifically, it belongs to the Adobe Experience Cloud ID Service (ECID) — the component that assigns and syncs a visitor identifier across Adobe products. It appears whenever Adobe Analytics is installed, even if you do not use Adobe Audience Manager.


1. The cookies you will see

CookieDomainTypeWhat it does
demdex.demdex.netThird-partyCore ECID visitor identifier
dextp.demdex.netThird-partyRecords the last time an ID sync ran with a given partner
dst.demdex.netThird-partySignals an error state in the ID sync process
AMCV_*Your domainFirst-partyThe Experience Cloud ID as stored on your own site
AMCVS_*Your domainFirst-partySession flag for the ECID service
s_viYour domainFirst-partyAdobe Analytics visitor ID
s_fidYour domainFirst-partyFallback visitor ID, used when s_vi cannot be set
s_ccYour domainFirst-partyChecks whether cookies are enabled

dextp and dst only appear once Audience Manager is in play. The demdex cookie itself is part of the base ECID infrastructure and shows up regardless.


2. Where the requests actually go

Adobe Analytics contacts four external domains on a standard install:

DomainRole
assets.adobedtm.comAdobe tag manager (Akamai CDN)
dpm.demdex.netECID sync endpoint
sc.omtrdc.netAnalytics collection
d1.sc.omtrdc.netAnalytics collection

One detail worth knowing before it appears in a vendor assessment: when we measured these endpoints, dpm.demdex.net resolved to AWS Dublin — inside the EU. The common shorthand that "Adobe is a US company, therefore the data leaves the EU" does not survive a DNS lookup.

That does not settle the transfer question. Schrems II turns on legal access regimes rather than server geography, so the assessment depends on Adobe's corporate structure and the safeguards in your contract, not on where the packet lands. It is a question for your counsel — but the geography argument is not the one to build it on.


Under the ePrivacy Directive, Article 5(3), consent is required before storing or accessing information on a visitor's device. The rule applies to the act of storage, regardless of whether the stored value is personal data.

Every cookie in the table above is storage on the device. That means:

  • They must fire after an affirmative consent signal, not before.
  • Legitimate interest is not available here. ePrivacy does not offer the route GDPR does for some processing.
  • Third-party cookies on .demdex.net will usually need their own entry in your CMP, since they are set on a domain you do not control.

A frequent audit finding is that the ECID call fires on page load while the CMP is still initialising. The result is a cookie set before consent — which is a finding, not a configuration preference.


4. Your numbers are probably already affected

Independent of consent, Safari and Firefox block third-party cookies by default. The .demdex.net cookies are third-party by definition, so ID syncing silently degrades for a large share of visitors before your banner is involved at all.

The visible symptom is usually attribution: returning visitors counted as new, and channel credit drifting toward direct. If your Adobe reports have stopped reconciling with revenue, this is one of the places to look.


5. How to check your own site

  1. Open your site in a private window with DevTools on the Network tab.
  2. Filter for demdex.
  3. Reload, and watch when the call to dpm.demdex.net fires — specifically whether it happens before you interact with the consent banner.
  4. Switch to Application → Cookies and check both your own domain and .demdex.net against the table in section 1.
  5. Repeat with the banner rejected. Any cookie still present at that point is the finding worth writing down.

Step 5 is the one that matters. Steps 1 to 4 tell you what is installed; step 5 tells you whether your consent gate actually works.