面向出版商的加州 CIPA 追踪合规与服务端埋点审计指南

核心要点

• 加州参议院第 690 号法案（SB 690）限制了个人原告依据 CIPA 提起的某些诉讼，但其他类型的 CIPA 诉讼仍有可能成立。

• 全面审查完整的数据流，不要只看追踪工具有哪些。要核查每个工具收集了哪些数据、数据流向何处，以及用户的许可授权如何影响数据发送。

• 尽量减少不必要的数据。只保留分析所需的事件，剔除或限制非必要的参数与标识符。

• 在整个追踪技术栈中严格保持授权状态一致。无论是浏览器端标签还是服务端系统，都必须遵循相同的许可和退出（opt-out）选项。

• 服务端追踪带来了更强的控制力，但并不等于自动合规。在将数据发送到第三方平台之前，你可以对其进行过滤并应用匿名化规则。

• 兼顾隐私合规与数据衡量需求。只要配置得当，追踪架构既能帮你留存有价值的数据，又能减少非必要的数据收集。

🤔 本文适合谁读：数字出版商、网站所有者，以及需要了解 CIPA 相关诉讼对其追踪实践有何影响、希望审查现有架构，并在不牺牲数据质量的前提下搭建合规追踪体系的市场和数据分析团队。

《加州侵犯隐私法》（CIPA）是加州在 1967 年颁布的一项州法律，最初旨在防止未经授权的窃听以及对保密通信的秘密录音。 

自 1967 年以来，CIPA 的条款不断演变，原告也开始主张该法同样适用于现代网络数据追踪。

2025 至 2026 年间掀起的一波 CIPA 相关诉讼浪潮，让出版商对网站访客数据的收集以及与第三方的共享方式更加警惕。这些诉讼认为，Cookie 和像素代码等网站追踪技术可能允许第三方在未经用户同意的情况下收集其网站活动信息，从而构成对 CIPA 的违规。

这类针对网站追踪的诉讼会给出版商带来财务风险。尽管加州 2026 年通过的 SB 690 法案自 2027 年 1 月 1 日起限制了部分针对网站追踪的诉讼（下文将详细讨论），但其他类型的隐私诉讼依然可能发生。

出版商需重点关注的 CIPA 条款

在针对网站追踪提起的诉讼中，原告最常援引 CIPA 规定的三项条款，不过各自依据的法律理论有所不同：

• 第 631 条：未经授权截获通信。 

该条款涵盖的情况包括：在未经必要许可的情况下，在保密通信传输过程中对其进行截获或非法访问。

对企业的含义：原告可能会指控网站在访客同意之前，就允许第三方服务商（例如在线客服工具、分析服务或广告像素）截获访客与网站互动的信息。

• 第 632 条：录制保密通信。

该条款涵盖在未获得法定许可的情况下，录制或窃听保密对话的行为。

对企业的含义：如果网站使用在线客服工具或会话回放（session-replay）软件等手段，在未获得必要授权的情况下记录用户的私密互动，企业就可能面临法律诉讼。

• 第 638.51 条：收集路由和寻址信息。

该条款限制在未经法院命令的情况下，使用收集来电或去电通信信息的设备。这类设备收集的是通信来源、去向等路由信息，而非通信的具体内容。

该条款之所以频频出现在针对网站追踪行为的诉讼中，是因为原告主张常规网站追踪工具的运作方式与这些设备类似。

对企业的意味：原告据此认为，收集 IP 地址、设备详情或其他连接数据的网站追踪工具，可能同样适用该条款。

加州 SB 690 法案改变了什么，又保留了什么

2026 年 9 月 30 日，加州州长加文·纽森签署了参议院第 690 号法案（SB 690），但该法案要到 2027 年 1 月 1 日才正式生效。

SB 690 限制了谁有权依据《加州刑法典》第 637.2 条，就违反前述第 638.51 条的行为提起诉讼。

带来的改变：只有加州总检察长才能针对私营主体提起这一特定类型的诉讼。个人及其他民间原告将无法再援引 CIPA 的民事救济条款发起此类网站追踪诉讼。

最重要的限制在于，SB 690 并未免除 CIPA 项下的其他诉由。这意味着民间原告仍可依据第 631 条、第 632 条或 CIPA 的其他任何条款提起诉讼。

这项修改还具有追溯力，适用于 2027 年 1 月 1 日前两年内提起、且符合条件的待决第 638.51 条相关诉讼。

实际影响在于，SB 690 并未消除审查追踪基础设施以确保合规的必要性。

另外需要注意的是，CIPA 只是相关法律版图中的一部分。其他联邦和州层面的隐私法可能对个人信息、用户同意、信息披露以及数据共享有各自的规定。对于提供视频内容的发布商而言，如果将视频观看记录与订阅用户或用户标识符绑定，还可能涉及联邦《视频隐私保护法》（VPPA）。

在审查追踪和隐私基础设施时，专业人员通常会先列出网站上安装的追踪工具。这是个不错的切入点，但若想全面把控风险，更重要的是回答以下几个问题：

✅ 每款工具收集了哪些信息？

✅ 这些信息流向了何处？

✅ 在什么条件下会被共享？

✅ 用户的同意与退出选择会如何影响数据收集和传输？

要回答这些问题，需要梳理用户旅程以及各类不同场景，例如业务流程、同意状态等。对内容发布商来说，梳理用户旅程既有助于明确哪些受众或收益衡量指标需要保留，又能减少不必要的数据暴露。

下表展示了如何通过这些问题得出可落地的实施方案。

要想全面掌握情况，需要进行一次代码追踪审计。其目的在于查明有哪些第三方服务在接收数据、传输了哪些信息，以及追踪行为是否符合网站的隐私要求和用户授权设置。

作为审计的一部分，需要重点关注可能收集或共享敏感数据的页面和组件。例如：

• 在文章页面上，检查追踪工具是否传输了完整 URL 或查询参数。

• 站内搜索框也需排查，看看搜索词是否可能包含个人信息或敏感数据。

• 新闻通讯订阅表单和付费订阅流程可能会暴露联系方式、账户标识符或交易数据。 

• 视频播放器和内嵌内容也需要检查，确认播放事件、内容元数据以及用户标识符是否会被共享给第三方。

针对上述每种场景，都要检查触发了哪些追踪事件、包含哪些数据、接收平台是哪家，以及这些行为如何随用户的授权状态而改变。 

第一步：扫描网站上的追踪工具

首先梳理网站上运行的数据分析、广告、在线客服、视频、会话回放等各类第三方服务。

初步排查时，可以使用 Stape 的 Website Tracking Checker。该工具会扫描网站的追踪配置，并针对检测到的追踪器、Cookie、追踪方式以及建议的配置优化生成一份报告。

这有助于发现网站中的追踪工具和潜在配置问题，并针对具体情况提供详细的优化指导。这份报告只是起点，接下来还需要确认在文章浏览、新闻通讯订阅和付费订阅等不同用户路径中，检测出的工具究竟有哪些在实际接收数据。

第二步：测试用户授权前后的数据行为

2.1 排查发送的网络请求。

打开无痕窗口，在不同的授权状态下测试网站：

• 在 Cookie 提示横幅上做出选择之前。

• 接受所有可选 Cookie 之后。

• 拒绝可选 Cookie 之后。

• 修改或撤回授权偏好之后。

针对每种场景，使用 Chrome 开发者工具（DevTools）进行检查。

在页面任意位置右键单击并选择检查 → 点击 Network 标签页 → 点击更多筛选器 → 勾选 3rd-party requests，将请求列表筛选为源域与当前页面不同的请求。

检查不同情形下发出的请求。对于任何可疑请求（例如在设置授权偏好前就发出的 /collect 请求），务必查明其触发原因并确认是否符合数据合规要求。具体步骤如下：

• 查看 Headers，找到请求 URL 和域名。

• 若有 Payload 标签页，打开它以检查查询参数和发送的字段。 

• 查看 Initiator，找出触发该请求的代码或脚本。

要特别留意广告、分析、在线客服或会话回放等工具，是否在用户给出相应授权或同意之前就已经在传输数据。

2.2 检查生成了哪些 Cookie。

操作方法是：打开 Application（应用）面板 → 在左侧边栏中展开 Storage（存储）→ Cookies 并选中你网站的域名 → 记下看到的 Cookie 名称及其所属域名。

与 Cookie 授权弹窗互动，观察 Cookie 发生了哪些变化：是否生成了新的 Cookie？原有的 Cookie 有没有保留？它们的作用与你的合规文档描述是否一致？

务必针对每种授权场景都重复测试一遍。

每次测试前，请务必在触发测试操作前立刻清空 Network（网络）日志。如果需要跟踪跨页面跳转的行为，请勾选 Preserve log（保留日志）。

第三步：检查数据的流向

你可以先从 Chrome 开发者工具查起。但要注意它存在局限性——无法查看到后续服务端之间（server-to-server）请求的具体内容。

用开发者工具排查时，打开 Network 面板 → 刷新页面 → 筛选 Fetch/XHR 请求或直接查看 All。仔细检查请求的 Headers（标头）、Payload（载荷）、Cookies 和 Initiator（发起程序） 标签页，重点查看请求发往的目标域名以及随请求发送的数据字段。 

如果你已经在使用 Stape 追踪数据（且订阅计划不低于 Pro 版），也可以直接查看 Logs（日志）。

浏览器开发者工具展示的是浏览器端收发的内容，而 Stape 日志能让你清楚看到服务端埋点配置接收到了什么、又向外转发了什么。两者结合才能掌握完整的数据流向。

Stape 日志包含两个标签页：

• Incoming requests（入站请求）：在这里可以查找测试期间生成的请求。它会显示容器接收到了哪些请求，以及获得了什么数据。

• Outgoing requests（出站请求）：从审计的角度来看，这个标签页更为关键。你需要特别核对目标平台、Request URL（请求 URL）以及 payload（载荷），弄清楚你把哪些参数和数据发送到了哪里。

日志功能灵活好用，非常适合用于合规授权相关的审计工作。如需了解日志功能的具体用法，请参阅我们的官方文档。

在测试完网站追踪并看清发送的数据后，很多人容易走向极端，大幅砍掉各类追踪数据。但更可取的做法是把握好分寸，避免因矫枉过正而丢失可用于后续业务优化的关键数据。 

要想拿捏好平衡，可以参考以下几个步骤：

✅ 明确哪些数据是支撑具体决策所必需的。在删掉某个事件或参数之前，先想清楚它是否有助于评估营销活动效果、优化转化归因，或是达成其他既定目标。 

✅ 降低数据粒度，而不是直接删除整个事件。即便某些参数并非必要，事件本身可能依然很有价值。例如，当读者订阅付费刊物时，发布商完全可以在不上报订阅者姓名、邮箱、账户明细等第三方平台不需要的个人信息的前提下，正常追踪订阅转化事件及其金额。 

✅ 按平台需求按需共享数据。不同平台的用途各不相同。广告平台可能需要特定信号来做归因或投放优化，而分析工具需要的则是另一套信息。切忌默认将全量数据一股脑同步给所有下游。

✅ 统一执行用户的同意与退出选择。用户的授权决定不仅要在浏览器端跟踪生效，也必须同步应用到服务端的数据采集与转发上。绝不能把服务端跟踪当成绕过用户意愿、擅自“补齐”未授权数据的后门。

需要我们协助审计网站的跟踪设置？

欢迎与我们沟通，排查潜在的隐私合规风险，探索更注重隐私保护的跟踪方案。

联系我们

服务端跟踪能让发布商更自主地控制向第三方平台共享哪些数据，以及如何共享。 

在客户端跟踪模式下，浏览器会直接把用户数据发送给网站配置的第三方平台。

而部署了服务端跟踪后，浏览器会先将数据发送至第一方服务端节点，再由该节点决定后续流向。在这个“中间层”，你可以在转发数据前完成审查、过滤和匿名化处理。

关于两者的详细对比，可参阅我们的文章《客户端与服务端跟踪解析》。选择何种方式采集用户交互行为，不仅决定了你对数据的掌控力，还会直接影响数据的质量和可靠性。

只要规则配置得当，服务端跟踪就能帮你剔除冗余的数据共享，仅保留满足特定业务目标所需的信息。对发布商而言，这些目标可能包括广告投放归因或付费订阅记录，完全没必要把读者的完整账户信息同步给所有平台。

例如，你可以为服务端节点设置规则，仅向特定平台发送特定的事件或数据字段，也能针对不同的接收方应用不同的处理逻辑。

数据采集与共享方式在法律层面到底有多重要？Smith 诉 Rack Room Shoes 案便是一个典型例证。在该案中，法院驳回了原告依据《加州侵犯隐私法》（CIPA）对服务端跟踪提起的诉讼，理由是原告指控未能充分证明存在“同步拦截”行为。

但这绝不意味着只要用了服务端跟踪就天然合规。无论采取哪种采集方式，你依然必须全面审视跟踪机制的运作流程、采集与共享的信息范畴、各家供应商的具体操作，以及适用的法律法规。

同时，你也需要认清服务端跟踪在管控能力上的局限。你配置的数据审查和过滤规则，仅对经过自身服务端节点（如自定义子域名或同源 URL）的数据生效，并不能自动约束访客浏览器中运行的其他跟踪脚本。因此，你依然要通盘考量整体跟踪架构、用户授权与披露机制、第三方供应商合作关系以及相关法律义务。

Stape 能帮你构建掌控力更强的跟踪体系，核心优势包括：

• 服务端 GTM 容器托管与数据过滤。创建服务端 GTM 容器后，需要为其提供托管运行环境。Stape 提供了所需的基础设施，用于接收事件数据并将其分发至第三方平台。

• 丰富的 GTM 实体与服务端用户同意控制。Stape 是 GTM 社区最大的模板贡献者之一。我们的团队持续开发全新的 GTM 实体，尽可能简化服务端跟踪的配置流程。同时，这些代码内置了完善的用户同意控制机制，便于您依据各项数据法规灵活设置。

• 满足多样化跟踪需求的解决方案。Stape 提供了一系列功能增强模块（Power-up），助您搭建高阶数据跟踪方案。例如，针对需要合规跟踪的客户，热门的 Anonymizer 增强模块可以在向 GA4 发送数据前，自动移除或遮蔽 IP 地址、用户 ID 等非必要数据。

不过，服务端跟踪的作用不仅在于数据控制和隐私保护，更关乎数据可靠性。它有助于减少数据丢失，提升跟踪的稳定性。例如，Stape 提供的 Custom Loader 和 Cookie Keeper 能减少浏览器限制造成的数据丢失；Click ID Restorer 可补全缺失的点击 ID 以保障归因准确；Enricher 则能结合现有用户数据丰富事件内容，等等。

想要深入了解我们的方案如何提升跟踪可靠性与数据控制力，欢迎阅读关于使用 Stape 托管 sGTM 的优势一文。

希望对发往分析与广告平台的数据拥有更强把控力？

联系我们

不同场景下的法律合规要求可能有所不同。以下列出的跟踪实践仅作为通用指引，未必能涵盖您具体面临的所有法定义务。建议咨询专业法律人士，获取贴合自身需求的合规建议。

1. 确保同意管理平台（CMP）默认处于“拒绝同意”状态。

检查 CMP 的默认同意设置（根据您的配置方式，可在 GTM 中查看，如截图所示，也可在 CMS 应用中查看）。推荐的做法是：在网站访客明确授予同意之前，将所有类别的同意状态均默认设为 denied（拒绝）。

2. 排查并修正聊天、客服及会话录屏插件的设置。

用于录制用户会话和在网页端植入聊天的工具，是隐私诉讼（尤其是 CIPA 诉讼）的重灾区。例如，一项对 2026 年 58 起联邦诉讼案件的梳理显示，会话回放服务商卷入了其中 2 起诉讼，聊天插件也涉及了 1 起。

为避免出现非法记录和共享数据的情况，请仔细核查相关设置，特别是当工具是通过自动化方式部署到网站上时。例如，若授予 Clarity 足够权限，它便能自动添加配置好的代码并发布 GTM 容器版本。

然而，这种自动化配置需要再次复核确认，因为平台可能会忽略隐私设置，导致其代码在 CMP 确立默认状态之前就已经触发运行。

因此，务必确保代码仅在获得充分同意后才执行。在代码设置中展开 Consent Settings（同意设置）一栏，并添加触发该代码所对应的同意类型。

此外，请务必在平台允许的限度内尽可能严格地脱敏敏感数据，避免相关文本直接进入平台服务器。详细指南请参阅对应工具的官方文档。

为这类代码添加一个触发器组。该代码应设置几个触发器：一个用于检查许可状态，另一个用于在事件触发后执行代码。

3. 为服务端跟踪选择合规的服务器节点。

部署服务器时，务必选择合适的位置，具体应根据受众所在的地理区域来定。 

4. 考虑对敏感数据进行额外匿名化处理。

部分工具自带数据匿名化机制。例如，GA4 会在存储 IP 地址之前自动将其匿名化。但对隐私合规要求更严苛的机构而言，这一默认行为可能还不够。 

借助 sGTM，你可以增加一道额外的隐私保护防线：在将数据发送给 GA4 之前替换访客的原始 IP 地址。如果你的网站涉及敏感信息处理（如医疗健康、金融服务、保险或其他高风险用户流程），这种方案尤其值得考虑。 

5. 发布更改前务必做好测试。

在配置正式上线前，最便捷的检查方式就是使用 GTM 的预览模式（Preview）。 

以下是判断 CMP（许可管理平台）是否配置正确的几个关键特征：

✅ Consent Update 事件应该先于容器中配置的任何其他事件（包括页面浏览和点击）触发。这能确保在执行任何跟踪代码之前，许可状态就已经完成初始化。

✅ CMP 推送的事件必须在 Consent Update 事件之后触发。

打开 CMP 事件并切换到 Consent 标签页，核对以下内容：

• Default statuses（第一列：默认状态）已设为 Denied（拒绝）。

• On-page Update 与 Current State（第二、三列：页面更新与当前状态）能如实反映你在页面许可横幅中所选的状态。

✅ 如果你在横幅中更新了许可偏好（例如拒绝特定 Cookie），Consent Update 事件应当再次触发，且事件 Consent 标签页中的对应列必须显示最新状态。

✅ 在不同许可状态下测试核心业务场景

针对网站的核心用户流程反复进行测试，并切换不同的许可状态，比如：用户做出选择前、接受所有 Cookie 后，以及拒绝或仅接受部分类别后。

建议重点排查以下场景：

• 文章浏览：打开一篇文章，检查触发了哪些页面浏览和互动事件、是否上传了完整 URL 或查询参数，以及哪些第三方平台接收到了这些数据。

• 站内搜索：在搜索栏中输入关键词，检查触发的事件及发出的网络请求。

• 邮件订阅：在测试环境中提交订阅表单，检查触发的事件，确认邮箱地址、姓名或其他联系方式是否被发送至第三方平台。

• 付费订阅：走完整套订阅流程，包括最后的转化或购买确认环节。检查回传了哪些转化与收入参数，以及事件有效载荷（payload）中是否夹带了敏感信息。

• 视频播放。播放一段视频并操作控制条，检查播放、暂停、播放完成及互动等事件是否正常发送，并核查内容元数据或用户标识符是否被共享给第三方。

✅ 确认同意状态已正确传递给服务端 GTM 容器。

操作方法是：在 Stape GTM 助手中开启同意模式服务端开关（服务端 GTM 默认不会同步该同意状态）。

接下来，打开服务端 GTM 的预览窗口，选中最新发生的事件，检查 ad_storage 和 analytics_storage 的同意状态是否与网页端 GTM 预览中显示的一致。

即便加州的 SB 690 法案对部分网站追踪诉讼进行了限制，但与 CIPA 相关的网站追踪诉讼仍然是发布商必须重视的风险。该法律虽缩窄了一类私人索赔的范围，却并未免除遵守其他隐私合规要求的必要性。

在此背景下，服务端追踪有助于推进数据合规工作，但它无法替代可靠的用户同意管理系统。相反，服务端追踪方案应当充当一层补充防护，在数据发送至第三方平台之前，用于审查、过滤和匿名化这些数据。

最终目标是构建一套既能支撑商业决策，又不会过度收集或共享信息的追踪架构。通过定期测试、践行透明的数据规范并合理配置追踪基础设施，你既能符合隐私合规要求，又能获取驱动业务所需的数据。