标签管理器与 CDP

1. 两层，同一思路

标签管理器决定哪些工具在页面运行。客户数据平台决定事件随后发往何处。两者都位于网站与技术栈之间，也都值得获知录制已存在。

桥接将回放链接写入您使用的任一层，使其下游系统——分析工具、数据仓库、营销自动化——均能携带链接，无需逐一单独集成。

2. 各工具实际接受什么

这六种工具的差异比其类别所暗示的更大，而且并非风格区别；每个工具都会拒绝其他工具所期望的输入。

工具	接收值的方式
Tealium	utag.link ，而非 utag_data，后者仅在页面加载时读取
Adobe Launch	通过 Client Data Layer； _satellite 没有公开的写入 API
Commanders Act	tc_vars ，如果缺失，我们 不会 创建，因为缺失意味着 TagCommander 不存在
Segment	analytics.identify ，附带 trait
RudderStack	相同形式，使用其自身的全局对象
Snowplow	全局上下文；通过回调返回，因此值会被缓冲
JENTIS	_jts.push ，带有 track: "event"；允许自定义字段名称，仅 track 和 type 为保留名称

JENTIS 是加载顺序规则的例外。 其安装代码片段会创建 window._jts = window._jts || []，使 _jts 成为队列：推送的数据能保留到库加载后，不会丢失。因此第 4 节关于顺序的说明不适用于它。队列缺失时，我们仍不会创建，原因与 Commanders Act 相同：缺失意味着未安装 JENTIS，而自行构造的 _jts 只会成为无人兑现的承诺。

值得明确指出的 Tealium 错误

写入 utag_data 看似正确，实际无效：Tealium 只在页面加载时读取该对象一次，而我们的值在此后才到达。 utag.link 才是能触达运行中 Tealium 的调用，也是我们使用的调用。

3. 它不做什么

不创建数据层

如果页面上没有 Commanders Act， tc_vars 就不存在，我们会保持如此。创建它会使页面上所有其他脚本误以为存在已配置的 TagCommander，这比不做任何操作更糟。

自身不发送任何内容

标签管理器或 CDP 根据自身配置与合同转发此值。对我们而言，这只是向本地对象写入；数据是否离开浏览器，以及交给谁，由您自己的工具决定，这也是这些接收方不出现在我们处理活动记录中的原因。

不会无限重试

每半秒一次，共尝试二十次，然后停止。十秒内还未出现的标签管理器不会再出现。

4. 关于顺序的说明

标签管理器按设计较早加载，CDP 通常较晚，MousePlayer 则根据嵌入方式位于两者之间。因此桥接采用轮询，而非只读一次。

如果可控制加载顺序，将标签管理器放在我们的代码片段前即可完全省去等待；但功能不依赖这一点，我们也不要求为我们重新安排页面。