Segment 实际做什么

Segment SDK（从 cdn.segment.com/analytics.js 加载）初始化一个全局 analytics 对象，并使用名为 ajs_anonymous_id 的 Segment 自有 Cookie 识别访客。应用代码调用 analytics.identify()、analytics.track()、analytics.page() 和 analytics.group()，SDK 将每个调用转发到 Segment 的接收端点。然后 Segment 将事件扇出——实时或批量——到在来源上启用的任何目的地：Google Analytics、Facebook Pixel、Customer.io、Iterable、Amplitude、Mixpanel、Snowflake、BigQuery 以及数十个其他目的地。

从 GDPR 的角度来看，每次转发到下游目的地都是一项独立的处理活动。将事件发送到 Google Analytics 的法律依据，与将同一事件发送到 Customer.io 不同，也与将同一事件写入 Snowflake 数据仓库不同。记录单一「我接受营销」的同意横幅，本身不能合法地授权所有这些，除非目的地的分类与同意的分类相匹配。

Segment 原生同意原语

过去两年，Segment 在同意管理原语上投入了大量资源。截至 2026 年，平台为同意执行提供了三个有意义的接口。

Consent Management（原 Consent Stamping）

Consent Management 功能允许您将同意负载附加到 Segment 接收的每个事件。该负载记录用户已接受的处理类别——通常是 IAB TCF v2.3 字符串、GPP 字符串或自定义 Segment 分类。下游目的地可以根据每个事件的同意状态配置为转发或阻止。

带同意门控的目的地过滤器

目的地过滤器允许您编写一个小型 JavaScript 或 Lua 表达式，在每个事件转发到特定目的地之前运行。过滤器可以检查同意负载，如果相关类别尚未被授予，则短路转发。这是细粒度、按目的地同意执行的正确原语。

来源级 integrations 设置

对于粗粒度控制，来源级 integrations 对象可以按事件完全禁用目的地：analytics.track(event, properties, { integrations: { "All": false, "Segment.io": true } })。这对全有或全无的情况很有用，但不能很好地处理类别级别的粒度。

分步 CMP 集成

可靠的架构是将 CMP 的类别决策映射到 Segment 的目的地分类，将同意负载附加到每个事件，并使用目的地过滤器执行按目的地的门控。

1. 对目的地进行分类

遍历 Segment 工作区中启用的目的地列表，将每个目的地分配到一个 CMP 类别。Google Analytics、Mixpanel 和 Amplitude 等目的地通常属于分析类。Facebook Pixel、TikTok 和 Pinterest 等目的地通常属于营销类。Snowflake 或 BigQuery（您自己的数据仓库）等目的地通常属于必要或功能类——但前提是数据仓库下游处理的分析也被正确分类。将此映射记录在可审查的地方；审计辩护依赖于此。

2. 推迟 SDK 初始化直到捕获同意决定

Segment SDK 可以配置为在调用 analytics.load() 之前不发送事件。将加载调用推迟到 CMP 捕获用户决定后，这样就不会在同意前触发任何事件。或者，在事件处理程序中使用带同意状态门控的 analytics.ready() 队列模式。

3. 将同意负载附加到每个事件

配置 Consent Management 功能，将 IAB TC 字符串、GPP 字符串或您的自定义分类标记到每个接收的事件上。该标记随事件在 Segment 的管道中传播，并可供目的地过滤器使用。

4. 为类别级别执行编写目的地过滤器

对于每个目的地，编写一个过滤器，根据该目的地所需的类别检查同意负载。如果用户接受了营销但拒绝了分析，营销类别的目的地会接收事件，而分析类别的目的地会被静默丢弃。过滤器逻辑通常从 event.context.consent.categoryPreferences 或同意负载模式中的等效路径读取。

5. 传播撤销

当用户撤销同意时，需要发生两件事：SDK 停止在撤销类别下发送新事件（由来源级 integrations 切换处理），下游目的地中现有的用户配置文件需要更新或删除。Segment 的 Privacy API 支持删除请求和抑制标志；配置 CMP 在撤销时调用适当的 Privacy API 端点。

常见陷阱

四种集成错误占 Segment 部署审计发现的大多数。

将 Segment 视为单一追踪器

最常见的缺陷：将 Segment 置于单一类别（通常是分析）下门控，并假设这满足了下游的一切。事实并非如此。如果 Facebook Pixel 作为目的地启用，转发到 Facebook 的事件需要营销类别的同意，而不是分析。按目的地分类是强制性的。

忘记数据仓库目的地

许多团队将 Snowflake 或 BigQuery 作为 Segment 目的地启用，并以「它是内部基础设施」为由将数据仓库视为豁免。数据仓库本身可能是内部的，但后续处理——BI 仪表板、相似建模、客户细分——服务于营销和分析功能。数据仓库的同意分类应反映仓库数据最终流入的最宽松用途。

没有同意上下文的服务器端来源

Segment 支持服务器端来源（您的后端直接调用 Segment）。来自这些来源的事件不会自动继承浏览器端的同意状态。应用程序必须在事件发送时查找用户的同意状态并将其附加到调用中。没有这一点，服务器端事件会完全绕过 CMP。

忽略跨来源身份合并

Segment 的身份解析合并匿名和已识别的配置文件，并且可以跨网页、移动端和服务器端来源执行此操作。如果这些界面之间的同意状态不同，合并后的配置文件默认继承最宽松的解释。配置身份解析以使用合并身份中最严格的同意状态，而不是最宽松的。

审计清单

针对任何涉及 EU、UK 或加州流量的 Segment 部署，需要回答六个具体问题。

• 目的地分类是否有文档记录？ 对于每个启用的目的地，是否有书面记录说明哪个 CMP 类别对其进行门控？
• SDK 是否等待同意？ 在隐私窗口中打开页面，确认在横幅被接受之前没有 analytics.track 调用触发到 api.segment.io。
• 同意负载是否标记在每个事件上？ 在 Segment 调试器中检查一批接收的事件样本，确认同意负载存在且完整。
• 目的地过滤器是否遵守类别？ 确认在 CMP 中禁用某个类别会导致事件不被转发到该类别中的目的地。
• 服务器端来源是否携带同意？ 确认服务器端调用在发送时查找并附加用户当前的同意状态。
• Privacy API 是否在撤销时触发？ 确认 CMP 触发的撤销调用 Segment 的抑制或删除 API，而不仅仅是本地 SDK 退出。

Segment 在以同意为首的栈中的位置

CDP 在隐私架构中占据着最具杠杆效应的位置：CMP 横幅处的单一决定必须传播到数十个下游目的地，每个目的地都有自己的法律立场。正确的架构将 CMP 视为用户类别偏好的真实来源，将该真相附加到 Segment 接收的每个事件上，并使用 Segment 的目的地过滤器原语在路由层而不是在每个单独的目的地执行类别级别的门控。正确执行后，工程工作随目的地数量线性扩展——添加新目的地是一个分类决定和一条过滤规则，而不是全新的集成。执行不当时，CDP 会成为隐私倍增器，将违反同意的事件转发给一长串合作伙伴，速度比任何手动审计都快。