Skip to main content
TimoSt1
Level 1
October 1, 2026
Question

First-party CNAME: can server-set AMCV/s_ecid be scoped per subdomain, or always registrable domain?

  • October 1, 2026
  • 1 reply
  • 25 views

Setup: one Org, five Launch properties serving five subdomains under one registrable domain (www, oem, my, … .example.com). First-party collection via CNAME smetrics.example.com. ECID v5.5.0, AppMeasurement 2.27.

Goal: each subdomain should start with no Adobe identity cookie before its own consent is given, and ideally identity should not be shared across the subdomains.

What I've confirmed:

  • The server (CNAME) sets both AMCV and s_ecid with Domain=example.com (registrable domain). These bleed to every subdomain.
  • The ECID cookieDomain config scopes only the client-side AMCV to the subdomain; it has no effect on the server-set cookies. Setting it to the literal subdomain, the Set-Cookie response still returns Domain=example.com. (Adobe docs also list cookieDomain/cookieDomainPeriods as retired.)

My open question:

  1. If I provision a per-subdomain CNAME (e.g. smetrics.oem.example.com as trackingServerSecure on the OEM property), will the collection server set the cookies on .oem.example.com, or does it always reduce to the registrable domain regardless of CNAME depth?
  2. If per-subdomain scoping isn't possible: has anyone disabled the server-side first-party ECID cookie and relied only on the client-side host-scoped AMCV? What was the impact on identity persistence and ITP?

Has anyone achieved genuine per-subdomain cookie isolation under a single Org, or is shared identity across subdomains inherent to the ECID service?

1 reply

Prasanth
Prasanth
Level 2
October 1, 2026

Hi ​@TimoSt1,

1. Will a per-subdomain CNAME scope the server-set cookie to .oem.example.com?

No. The Experience Cloud Identity Service (ECID / Demdex) Edge servers automatically resolve the incoming Host / CNAME header to its Effective Top-Level Domain Plus One (eTLD+1) (the registrable domain, e.g., .example.com).

Even if you provision smetrics.oem.example.com as your trackingServerSecure, the Edge response header will still issue:

HTTP

 

Set-Cookie: AMCV_...=...; Domain=.example.com;
Set-Cookie: s_ecid=...; Domain=.example.com;

Adobe’s identity server logic deliberately writes the cookie to the broadest valid first-party domain boundary (.example.com) to enforce cross-subdomain visitor continuity. It does not respect subdomain depth for server-set cookies.

Answers to the Secondary Questions & Architectural Options

2. Disabling Server-Side s_ecid and Relying on Client-Side Host-Scoped AMCV

If you attempt to enforce subdomain isolation by suppressing or ignoring s_ecid and relying solely on a client-set AMCV cookie scoped to the exact host (e.g., [www.oem.example.com](https://www.oem.example.com) via JS):

  • ITP Impact (Safari/WebKit): Client-set cookies (document.cookie) are restricted by Apple ITP to a 7-day (or 24-hour) maximum cap. Without a functional first-party server-set cookie (s_ecid set via CNAME HTTP headers), Safari users will experience severe identity fragmentation across return visits.

  • Consent / Compliance Risk: If s_ecid is set at .example.com on the first hit to Subdomain A, that cookie will automatically be sent in HTTP request headers when the user visits Subdomain B—before consent is granted on Subdomain B. This breaks strict per-subdomain zero-cookie consent requirements.

Since shared identity across subdomains is inherent to the legacy ECID service + CNAME architecture, here are the three viable paths to achieve genuine isolation:

Option A: Distinct First-Party CNAME Hostnames per Subdomain + Web SDK (AEP Web SDK)

If you migrate from AppMeasurement / ECID v5.5.0 to AEP Web SDK (alloy.js):

  • Web SDK handles identity via kndctr_[ORGID]_consent and kndctr_[ORGID]_identity.

  • You can configure cookieDomain at initialization explicitly per host/subdomain.

  • In Web SDK, first-party cookie domain configuration is strictly honored client-side, preventing the automatic broad root domain fallback seen in legacy ECID.

Option B: Unique Experience Cloud Org IDs per Subdomain

If you must stay on legacy AppMeasurement / ECID library:

  • The AMCV_ cookie key suffix is derived from your Experience Cloud Org ID (AMCV_HASH@AdobeOrg).

  • If each subdomain uses a separate Org ID (or a proxy/mock Org ID per property in Launch), the client will ignore AMCV cookies belonging to other Org IDs.

  • Note: s_ecid will still bleed across .example.com, but the identity library won't read or bind to the mismatched AMCV state.

Option C: Edge Proxy / Server-Side Header Rewriting (e.g., Cloudflare Workers / Akamai)

If you manage the CNAME DNS proxy layer in-house:

  1. Intercept the HTTP response headers returning from smetrics.example.com.

  2. Rewrite the Set-Cookie Domain attribute from .example.com to the explicit host (e.g., Domain=oem.example.com).

  3. This forces the browser to restrict both s_ecid and AMCV strictly to that specific subdomain boundary.

    Terms & ConditionsAccessibility statement

    Loading footer...