Adobe Experience Cloud Identity ID简称为ECID，以前叫MCID，MID和MCVID。
Adobe Experience Cloud Identity ID提供了一个通用的永久性ID，用于在 Experience Cloud 的所有解决方案中标识访客。它可以取代各种服务（如 Analytics、Audience Manager、Target）以及其他 Experience Cloud解决方案或功能的ID生成代码。
从技术上讲，ECID是依赖组织ID、Experience Cloud AMCV Cookie 和 Demdex Cookie，通过数学方法从组织ID 和Demdex ID 计算而来的唯一的永久性标识符，而不是任何个人身份数据（例如电子邮件地址，电话或CRM ID）的哈希。只要这些 ID 保持不变，为特定用户生成正确的 ECID 就只是一个数学问题。
由于Demdex ID是存储在一个单独域名，所以对所有用户而言Demdex ID是一样的，Demdex ID是有在用户首次访问时获取，之后是7天同步更新。
如果相同的组织 ID 和 Demdex ID去DCS查询，你每次会获得相同的 ECID 值，也就是你用同一个组织跟踪不同的网站，同个浏览器访问网站，ECID是一样。
但由于苹果ITP，机制在Safari有很大影响。
ECID可以实现的：
- 为网站访客设置和存储唯一 ID (ECID)。
- 保留此唯一ID，以便ID 服务可以收集数据并与其他 Experience Cloud 解决方案共享数据。
- 跨域跟踪用户。但是，这要求你拥有其他域并在这些域上部署ID服务代码。
ECID不能实现的：
- 存储、传输或执行计算机病毒。
- 访问或存储个人身份信息 (PII)，如你的电子邮件地址。
- 控制计算机硬件或软件。
- 使计算机不稳定或导致性能问题。
- 在未使用 ID 服务的网站上跟踪用户。
ECID原理
https://experienceleague.adobe.com/docs/id-service/using/intro/id-request.html?lang=zh-Hans
布署Adobe Experience Cloud ID
安装Experience Cloud ID Service插件
首先点击“插件”然后搜索Experience Cloud ID，就可以看到对应的插件Experience Cloud ID Service，然后在点击配置，对这个插件做配置：
Marketing Cloud Organization ID：体验云组织ID，就是组织ID，由24个字符的字母数字字符串，后跟@AdobeOrg，例如1FD6776A524453CC0A490D44%40AdobeOrg
Exclude specific paths：排除特定路径，如果URL与任何指定路径匹配，则不会加载Experience Cloud ID。
Opt In: 选择加入服务,可选配置，选择加入服务是ECID的一项扩展，旨在让你控制 Experience Cloud 解决方案是否可以在用户同意前为访客在网页上创建 Cookie，如果是，具体是哪些解决方案。你还可以通过选择加入服务设置协议以与大型设计中同意管理平台 (CMP) 和现有系统集成，以满足GDPR的要求。里面具体设置解析如下：
| 字段 | 解析 |
| Enable Opt In? 启用选择加入？ | 是否需要访客的同意才跟踪， · No的话表示默认跟踪； · Yes的话表示用户同意后才跟踪； · Determined at runtime using function，使用功能在运行时确定，如用户第一次访问的时候弹出的Cookie授权信息，用户同意后，才可以跟踪。 如果要符合GDPR，需要选最后一个。 |
| Is Opt In Storage Enabled? 选择启用存储功能吗？ | 如果启用就存储在第一方Cookie中，你可以自定义这个Cookie。如果未启用则保留在同意管理平台CMP或其他Cookie中。
|
| Previous Permissions? 权限？ | 将先前的同意传递到“选择加入”库。选择一个包含同意的数据元素。元素类型必须是对象或JSON字符串。覆盖批准前的选择。 例： “ {”aa“：true，”aam“：true，” ecid“：true}” |
| Pre Opt In Approvals? 预先加入批准？ | 当访客未设置首选项时，定义批准或拒绝哪些类别。从加载页面开始，就对所选解决方案假定为同意。元素类型必须是对象或JSON字符串（例如： {aam：true} ）。 |
| Enable IAB? 启用IAB？ | 启用后，Adobe Opt In会与页面上的现有IAB集成。根据同意管理平台 CMP 和 IAB TCF 中的同意标准启用/禁用 ECID 和 DIL 库。 这是实现GDPR的方式。 |
Variables、变量、将名称/值对设置为Experience Cloud ID实例属性。
设置好后：
测试发布
Experience Cloud ID Service是为数不多不用配置规则就能自动发送数据的插件之一，这个插件在首次访问网站的首页加载时自动向身份服务发出请求，获得 ID后，它将存储在以“ AMCV_”开头的第一方Cookie中。
详见配置发布到Staging环境中去，然后打开Adobe Experience Platform Debugger，然后刷新看Experience Cloud ID这里：
可以看到Pathname中的值是/id， 表明 ECID 已从 demdex.net 申请了一个 ID 。
再到浏览器开发者工具看cookie：
可以找到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了。
这里的MID/ECID就类似GA的Client ID。
测试没问题，可以发布。
将ECID设置为eVar
有时候会需要将ECID设置为eVar，eVar的周期可以设置为永不过期或hits。
客户端部署
错误的设置案例
一般想到的是直接使用Experience Cloud ID Service的内置数据元素ECID，将其设置eVar:
这个数据元素确实是获取ECID，但在报告中可能会出现Unspecified:
Unspecified表示变量未定义，或是不可用，在这里就是没获取到值。
如果你用Experience Cloud ID Service的内置数据元素ECID去设置ECID，那么就可能出现Unspecified。
正确的设置案例
可以考虑通过动态变量的方式，Adobe Analytics发送的数据默认就有ECID：
这里的mid，其实就是ECID。
通过动态变量，将mid设置为eVar：
这样，这个eVar就不会出现显示的是Unspecified:
服务端部署
如果你是用服务端部署，官方虽然提供了getIdentity方法去获取ECID，但可能会出现，对于新用户，ECID还没返回，但Web SDK已经将数据发送出去，从而导致Unspecified。正确的做法是用处理规则，如果是服务端部署，a.x.identitymap.ecid.0.id就是ECID：
延伸阅读：Adobe Analytics中将ECID设置为eVar（客户端&服务端）
