ECID cookies cross subdomains despite separate consent flows

Five subdomains have separate consent journeys, yet an identity cookie appears on all of them. A recent Experience League question reports server-set AMCV and s_ecid cookies carrying the registrable parent domain despite a narrower client cookieDomain setting. That observation deserves a browser-level test in your own deployment.

Inspect the response that sets the cookie

Capture network responses for the collection CNAME on each subdomain and record every Set-Cookie Domain, Path, SameSite, expiration and source host. Compare those headers with JavaScript-created cookies. Adobe’s trackingServerSecure setting defines the secure collection endpoint; its hostname alone does not prove the cookie scope seen by the browser.

Test before and after each consent decision

Start with clean browser storage. Visit each host before its consent choice, after decline and after acceptance. Observe which cookie is sent on sibling hosts and whether ECID is reused. Adobe’s identity cookie reference helps identify the cookie roles. Include Safari and other relevant browsers because retention and network behavior may differ.

Make the architecture decision with evidence

If the actual server response conflicts with the intended boundary, take the header capture and account configuration to Adobe Support and your privacy owner. Do not promise that another CNAME or a client-side setting will isolate a server-set cookie until the experiment proves it.

Adovo’s view

Consent boundaries must exist in the browser, not only in a configuration screen. The accountable question is simple: what identity reaches the next host before that person has chosen? Design around the observed answer.