更新时间：2024年6月1号
什么是ECID
ECID（Experience Cloud ID），全称Adobe Experience Cloud Identity，是Adobe为每位访客生成的唯一身份标识。
早期它曾被称为：
- MCID（Marketing Cloud ID）
- MID（Marketing Cloud Visitor ID）
- MCVID（Marketing Cloud Visitor ID）
目前官方统一使用 ECID（Experience Cloud ID） 这一名称。
ECID的作用是在整个Adobe Experience Cloud中统一识别同一位访客，使不同产品能够共享同一个用户身份，借助ECID，Adobe 可以将来自不同产品、不同渠道甚至多个网站的数据关联到同一个访客，实现统一身份识别和跨产品数据整合。
ECID的技术原理
ECID本身并不会存储任何个人身份信息（PII），也不是邮箱、手机号等信息的哈希值。
ECID 的生成依赖于 Identity Service，并结合以下信息完成身份识别：
- Experience Cloud Organization ID（组织 ID）
- 第一方 AMCV Cookie
- Demdex ID（如果浏览器允许第三方 Cookie）
- 浏览器环境及 Identity Service 的身份同步机制
整个流程如下：
- 浏览器首次访问部署了 Identity Service 的网站。
- Identity Service 检查是否存在 AMCV Cookie。
- 如果不存在，则向 Adobe Identity Service 请求一个新的 ECID。
- 返回的 ECID 被写入第一方 AMCV Cookie。
- 后续访问均直接读取该 Cookie，而无需重新生成 ECID。
因此，对于同一个浏览器，只要 AMCV Cookie 没有被删除，ECID 就会保持稳定。
Demdex ID与ECID的关系
Demdex ID 是 Adobe Identity Service 使用的浏览器标识。
它存储在demdex.net域名下（当浏览器允许第三方 Cookie 时）。
首次访问部署了 Adobe Identity Service 的网站时，浏览器会尝试读取或创建 Demdex ID。
如果多个网站使用同一个 Organization ID，浏览器允许第三方 Cookie，Demdex ID 相同
Adobe Identity Service 可以为这些网站分配相同的 ECID，从而实现跨网站身份识别。
不过，随着 Safari、Firefox 以及 Chrome 对第三方 Cookie 的限制越来越严格，Demdex ID 的作用已经受到一定影响，因此 Adobe 目前更加依赖第一方 Cookie 和 Identity Service 来维护访客身份。
ECID可以实现什么
ECID 的核心能力包括：
- 为每位访客生成唯一身份标识
- 在 Experience Cloud 产品之间共享访客身份
- 支持多个 Adobe 产品之间的数据关联
- 支持跨域身份传递（需正确配置 Identity Service）
- 为 Adobe Target、Analytics、AEP 等产品提供统一身份基础
ECID 不能实现什么
ECID不具备、也不会涉及以下能力：
- 存储、传输或执行计算机病毒
- 访问或存储任何个人身份信息（PII）
- 控制或修改用户的计算机硬件或软件
- 影响系统稳定性或页面性能
- 在未部署ID Service的网站上跟踪用户
部署Adobe Experience Cloud ID Service
安装Experience Cloud ID扩展
在Adobe Launch的Extensions里搜索并安装Experience Cloud ID，然后在点击配置，对这个插件做配置：
- Marketing Cloud Organization ID：填写 Experience Cloud Organization ID，格式如1FD6776A524453CC0A490D44%40AdobeOrg，Adobe Launch 中通常会自动读取，无需手动输入。
- Exclude specific paths：用于排除指定页面。 如果当前URL与配置规则匹配，则不会加载 Identity Service。
- Opt In: 用于与 CMP（Cookie Banner）配合，实现隐私合规，里面具体设置解析如下：
| 字段 | 解析 |
| Enable Opt In? | 是否需要用户同意后才允许追踪 |
| Is Opt In Storage Enabled? | 授权信息是否存储到Cookie里。 |
| Previous Permissions | 预设授权状态（通常为默认不跟踪） |
| Pre Opt In Approvals? | 预先就同意跟踪，一般不会设置。 |
| Enable IAB? | 是否启用IAB TCF，与CMP集成 |
这些设置是与意见征求模块相关，延伸阅读：在Adobe Launch上集成TrustArc：完整Cookie Banner配置指南
ECID的生效与验证
Experience Cloud ID 扩展属于少数无需配置 Rule 即可自动运行的扩展。
页面首次加载时，Identity Service 会自动执行初始化流程，并在获取ECID后写入第一方Cookie，cookie 的名称是以 AMCV_作为开头，如
可以找到AMCVS和AMCV两个cookie，表示Experience Cloud ID生效，ECID是存储在AMCV中。
- AMCVS Cookie 名称遵循语法 AMCVS_<组织ID>@AdobeOrg ，AMCVS Cookie的全称类似于下面的样子：AMCVS_1FD6776A524453CC0A490D44%40AdobeOrg，用作指示会话已初始化的标记。它的值始终为 1 ，并会在会话结束时失效。
- AMCV Cookie的名称应遵循语法 AMCV_<组织ID>@AdobeOrg，AMCVS Cookie的全称类似于下面的样子：AMCV_1FD6776A524453CC0A490D44%40AdobeOrg，包含有ECID和区域ID等信息，这些 ID 将以键值对形式进行存储。mid:user ID 包含访客的 Experience Cloud ID。aamlh:region ID 包含网站访客的区域 ID。如下面就是AMCV Cookie：
870038026%7CMCIDTS%7C18459%7CMCMID%7C49012491348529783830291047408573728389%7CMCAAMLH-1595387605%7C11%7CMCAAMB-1595387605%7CRKhpRz8krg2tLO6pguXWp5olkAcUniQYPHaMWWgdJ3xzPWQmdj0y%7CMCOPTOUT-1594790006s%7CNONE%7CvVersion%7C5.0.0
其中的7CMCMID%7C49012491348529783830291047408573728389就表示的是MID/ECID了。
测试没问题，可以发布。
将ECID设置为eVar（常见坑点）
有时为了方便报表分析，需要将 ECID 保存到某个 eVar，eVar的周期可以设置为永不过期或hits。
客户端部署
错误做法（客户端部署）
直接使用 Experience Cloud ID Service 内置数据元素 ECID 设置 eVar:
能导致报表中出现Unspecified:
原因：ECID 尚未返回时，命中已经发送，导致变量为空。
正确做法（客户端部署）
可以考虑通过动态变量的方式，Adobe Analytics发送的数据默认就有ECID：
这里的mid，其实就是ECID。
通过动态变量，将mid设置为eVar：
这样，这个eVar就不会出现显示的是Unspecified:
服务端部署
如果你是用服务端部署，官方虽然提供了getIdentity方法去获取ECID，但可能会出现，对于新用户，ECID还没返回，但Web SDK已经将数据发送出去，从而导致Unspecified。正确的做法是用处理规则，如果是服务端部署，a.x.identitymap.ecid.0.id就是ECID：
这种方式更加稳定，不受首次身份返回时机影响。
