Klaviyo Onsite 追踪的数据收集范围

Klaviyo Onsite 代码片段（从 static.klaviyo.com/onsite/js/klaviyo.js 加载）会初始化一个全局 _learnq 队列，并通过 Klaviyo 自有的名为 __kla_id 的 Cookie 识别访客身份。安装后，它将自动上报页面访问事件、捕获表单交互、触发驱动 Klaviyo 浏览放弃流程的 Active On Site 事件，并在访客登录或提交含电子邮件地址的表单时，将匿名浏览行为与已知订阅者档案关联。后续事件——查看商品、加入购物车、开始结账、完成下单——均通过同一身份基础设施触发，并继承相同的基于 Cookie 的归因逻辑。

就 GDPR 分析而言：该 Cookie 属于非必要 Cookie；由于数据与持久标识符绑定，离开页面的数据属于个人数据；而 Klaviyo 在美国设立，这使得数据传输须受 EU-US 数据隐私框架约束。上述三个条件共同将 Klaviyo Onsite 追踪明确归入 EU、UK、EEA 及巴西 LGPD 框架下"须事先获得同意"的范畴。在加利福尼亚州，同样的处理行为触发 CPRA 规定的"退出跨场景行为广告数据共享"权利——Klaviyo 向下游付费媒体目的地共享数据的行为正属于此类情形。

需要管控的三个追踪层面

一套 Klaviyo 安装并非单一追踪层面，而是三个，在进行 CMP 集成时须分别处理。

Onsite 追踪脚本

这是主要的行为追踪器——负责设置 __kla_id 并驱动 Active On Site 事件流的脚本。它是大多数团队记得要管控的层面，也是审计中监管可见度最高的一个。默认情况下应予以拦截，仅当访客接受营销类别时才予以加载。

Klaviyo Forms 与注册弹窗

Klaviyo Forms 是一个独立库，用于驱动电子邮件与短信注册弹窗、嵌入式表单以及内容解锁门控。它托管在同一域名下，但作为独立脚本加载。表单可独立于主 Onsite 追踪器触发展示和提交事件，因此仅管控 Onsite 而放任 Forms 加载，是一种常见的部分合规模式，仍然存在识别数据泄露的问题。

短信选择加入收集

短信注册在美国须满足 TCPA 规定的独立同意要求，在 EU 则须遵守特定行业规则。Klaviyo 的短信表单在收集手机号码的同时，还收集复选框确认的同意信息。此处收集的同意是针对短信消息本身的，独立于 Cookie 同意。正确配置的技术栈应同时记录两者：CMP 中记录 Cookie 同意，Klaviyo 订阅者档案中记录短信同意。

Klaviyo 原生隐私控制

Klaviyo 提供了若干原生隐私原语。与大多数营销平台一样，它们假定同意决定已存在并将被传入，而并不自行收集同意。

识别调用中的同意属性

当您调用 klaviyo.identify() 或 klaviyo.track() 时，可附加一个同意载荷，用于记录营销通信的合法依据。这是将 CMP 决定传入 Klaviyo 订阅者档案的正确原语。

档案级同意字段

订阅者档案包含专用的电子邮件同意、短信同意及同意来源字段。对这些字段的更新会传播至 Klaviyo 的分段引擎，使流程遵循已记录的状态。

隐私与同意设置面板

Klaviyo 的管理界面设有"隐私与同意"部分，用于控制部分默认行为——例如，Active On Site 事件是否会对未记录同意的访客触发。默认设置较为宽松；在 CMP 层面管控之上，收紧这些设置是一种有效的双重保障措施。

CMP 集成分步指南

可靠的架构是将所有三个 Klaviyo 追踪层面置于 CMP 管控之后，并在 Klaviyo 识别和追踪调用中使用同意属性，使平台订阅者记录与已记录的同意状态保持同步。

1. 从页头移除默认 Onsite 代码片段

Klaviyo 提供了一行代码片段，安装者通常将其粘贴至文档页头。请将其移除。用占位符 script 元素替代，其 type 属性设为 text/plain，data-category 属性标识为营销类别。当访客接受营销类别时，您的 CMP 将把 type 属性改写回 text/javascript。

2. 延迟 Klaviyo Forms 加载

Forms 库独立于 Onsite 加载。对其 script 元素应用相同的占位符模式，确保其在获得同意前不会初始化。同意授予后，Onsite 和 Forms 可同时初始化；已排队的事件将自动刷新。

3. 将短信同意与 Cookie 同意分离

短信选择加入收集通过 Klaviyo Forms 进行，但所收集的同意（短信营销的明确复选框确认）是独立于 Cookie 同意的法律凭证。CMP 弹窗记录 Cookie 决定；表单复选框记录短信决定。切勿将二者捆绑——捆绑同意在 GDPR 和 TCPA 框架下均属无效。

4. 将同意传播至 Klaviyo 档案

当已知订阅者在您的网站上接受或撤回同意时，CMP 应调用 Klaviyo API 更新档案的同意字段。Klaviyo Profiles API 支持局部更新调用，可在不覆盖档案其余内容的情况下写入电子邮件同意、短信同意及同意时间戳。大多数现代 CMP 均提供可端到端处理此流程的 Klaviyo 连接器。

5. 若同时运行 Google 标签，则接入 Consent Mode v2

大多数使用 Klaviyo 的店铺同时运行 Google Ads 和 GA4。您的 CMP 必须在任何 Google 标签触发之前，将 v2 同意信号——ad_storage、analytics_storage、ad_user_data、ad_personalization——发布至 dataLayer。Klaviyo 本身不使用这些信号，但 Google 会，而 Klaviyo 与 Google 之间的不一致将在归因报告中体现为可量化的收入差距。

常见陷阱

在 Klaviyo 部署审计中，有四种集成错误反复出现。

将 Forms 视为"仅是弹窗"

部分团队在营销类别下管控了 Onsite，却在初始渲染时放任 Forms 加载，理由是"弹窗只是一个 UI 元素"。然而 Forms 库会针对每个展示的弹窗向 Klaviyo 触发展示事件，这属于转发至美国广告技术供应商的识别性行为数据——正是 CMP 应当阻止的行为模式。

捆绑 Cookie 同意与短信同意

一个写着"我同意 Cookie 并同意接收营销短信"的单一复选框对二者均属无效。Cookie 同意必须专项针对 Cookie；短信同意必须专项针对短信。请使用独立的控件。

允许第三方付费媒体连接器对已撤回同意的档案触发

Klaviyo 可通过其集成功能向 Google Ads、Meta、TikTok 及其他广告网络推送受众。若订阅者撤回同意，受众推送需将其移除——而不仅仅是停止新增。请配置 Klaviyo 的受众同步设置，以实时响应同意状态变更，而非仅在初始同步时处理。

忽视历史数据问题

当访客首次接受同意时，您的技术栈不应将其同意前的匿名行为追溯关联至其新档案。CMP 与 Klaviyo 应就此达成一致：同意前的浏览数据不属于与当前已识别档案绑定的个人数据。部分 Klaviyo 流程默认假定存在此关联——请审查相关流程触发器。

审计清单

针对任何涉及 EU、UK、巴西或加利福尼亚州流量的 Klaviyo 部署，需回答以下六个具体问题。

• Onsite 是否等待同意后才加载？在启用严格追踪保护的隐私窗口中打开店铺，确认在弹窗被接受前没有 static.klaviyo.com 请求触发。
• Forms 是否等待同意后才加载？确认弹窗展示事件在营销类别被接受前不会触发。
• Cookie 同意与短信同意是否分离？确认 Cookie 弹窗不同时收集短信同意，且短信选择加入表单记录其自身的明确复选框确认。
• Klaviyo 档案是否反映 CMP 状态？确认 CMP 通过 Klaviyo API 将同意决定写入档案的同意字段。
• 受众同步是否遵循撤回操作？确认撤回同意会将订阅者从下游付费媒体受众中移除，而不仅仅影响后续同步。
• 同意前的浏览行为是否保持匿名？确认流程触发器不会将同意前的行为追溯关联至新识别的档案。

Klaviyo 在同意优先技术栈中的定位

Klaviyo 处于电子商务归因与直接营销通信的交汇点，这意味着它同时涉及 Cookie 同意体系（GDPR/ePrivacy、CCPA/CPRA）和营销通信体系（CAN-SPAM、TCPA、GDPR 第 6/7 条关于消息传递的规定）。正确的架构将这两者视为两个独立的同意层面——均通过单一 CMP 路由，由其掌握权威数据来源，同时通过 API 保持 Klaviyo 原生同意字段的同步。做到这一点的店铺，既能保留使 Klaviyo 具有商业价值的弃购、浏览放弃和分段功能，又能将审计风险降至默认安装的一小部分。所涉及的工程工作本身并不复杂；关键在于纪律——不允许营销团队将 Forms 视为可豁免于 Onsite 追踪器同等规则的例外。