GA4 默认 IP 匿名化的合规局限与服务端 GTM 替换配置教程
GA4 IP anonymization: when and how to go beyond defaults
GA4 虽默认在提取地理信息后丢弃 IP，但在欧洲严格隐私监管或敏感行业中，未授权时向 Google 发送原始 IP 请求仍存在合规风险。Stape 提供了通过服务端 GTM 结合 GEO Headers 插件的配置方案，可依据 Consent Mode v2 授权状态，在数据进入 GA4 前将未同意追踪用户的真实 IP 彻底替换为虚拟地理 IP。
针对高标准合规场景，提供了在用户拒绝授权时利用服务端 GTM 彻底替换真实 IP 的具体配置路径。
核心要点
GA4 默认会自动匿名化 IP 地址，但如果面对更严苛的隐私合规要求，仅靠这一点可能还不够。
部分企业为了满足更高的隐私与安全标准，需要在将数据发送至 GA4 之前直接替换掉 IP 地址。
服务端跟踪（Server-side tracking）赋予了企业更高的数据收集控制权，让你能在请求发送至分析平台前先对其进行修改。
借助 Stape 提供的免费解决方案，可以在 GA4 接收数据前彻底替换 IP 地址。
本文适合希望深入了解 GA4 IP 匿名化机制及其局限性的营销人员、数据分析师和埋点专家。若企业面临更严苛的隐私要求，本文将帮助你判断何时需要额外的 IP 保护措施，并指导如何通过服务端跟踪落地实施。
与 Universal Analytics 不同，GA4 无需单独配置 anonymize_ip 参数，一切都是自动完成的。
GA4 会在收集数据时利用 IP 地址推导地理位置信息，随后便直接丢弃该 IP，既不记录也不存储。因此，你无需在 GA4 设置中手动开启 IP 匿名化。
在 sGTM 预览模式中可以看到实际效果：无需做任何额外操作，_uip（用户 IP）参数就会被直接移除。
IP 匿名化不仅有助于减少 GA4 处理的个人身份信息，同时还能获取大致的地理位置信息。
内置的 IP 匿名化机制虽然旨在助力遵从数据隐私法规，但并不能保证网站方就此合规。实际落地是否合规，还取决于具体的数据收集流程、收集了哪些数据、数据处理的合法依据、用户授权同意机制的执行情况，以及如何与第三方共享数据。
自 2024 年 3 月起，在欧洲经济区（EEA）、英国和瑞士使用特定 Google 广告与衡量功能的广告主，必须提供特定的用户授权同意信号才能继续使用相关功能（即 Consent Mode v2）。
在这一背景下，搞清楚 Consent Mode v2 的运作机制至关重要。
当用户同意使用分析类 Cookie 时，GA4 会按照你的既有配置正常收集数据。
若用户拒绝授权分析，在开启高级同意模式（Advanced Consent Mode）的情况下，Google 代码仍会继续向 Google 发送无 Cookie 的 Ping 请求以辅助数据建模（当受限于隐私规则、授权选择、浏览器限制或缺少标识符而无法获取完整数据时，Google 会借此估算用户行为）。这些请求虽然不包含分析类 Cookie，但仍可能附带处理请求所必需的技术信息（例如 IP 地址）；Google 会在处理该请求时用到此 IP 地址，但不会将其记录或存储在 GA4 中。
对许多网站来说，这种机制已经足够，也契合 Google 以隐私为先的衡量策略。然而，对于内部政策或法规解读要求更为严苛的企业和机构而言，这种做法依然不够充分。
在某些隐私法规框架下，经过部分匿名化处理的用户 IP 地址仍可能被认定为个人身份信息（PII）。例如在 GDPR 规定下，即便对 IP 地址进行了部分掩码，结合具体场景它仍可能算作个人数据。因此，哪怕 IP 地址被截断，只要它能与其他信息结合并据此区分或识别出特定用户，就依然可能被视作个人数据。
如果用户明确拒绝授权收集和处理数据，这一点就尤为关键。因为 Google 在接收到 IP 地址进行处理后，才会执行匿名化操作并存储或生成报告。
因此，许多企业可能必须确保：一旦未获得用户授权，就必须在数据发送给 Google Analytics 之前将原始 IP 地址移除或替换掉。
在以下几类常见场景中，企业通常需要对 IP 进行额外的匿名化处理：
自身隐私政策要求在与第三方共享数据前完成匿名化；
合作的企业级客户提出了更高的安全与隐私合规要求；
业务涉及敏感领域或高风险用户旅程（例如医疗健康、医疗科技、心理咨询、医药、金融服务、银行、保险、政府及教育类网站）。这类机构往往更倾向于采用完全不让分析平台获取原始 IP 地址的数据架构；
在对数据分析合规监管格外严苛的国家开展业务，例如德国、奥地利、法国、荷兰及其他欧洲经济区（EEA）国家。
注意：
为确定在将数据发送至 GA4 之前是否必须配置 IP 地址替换，请咨询贵司的法务团队。上文列举的场景仅代表我们客户中最常见的情况。
服务端跟踪（Server-side tracking）提供了一层额外的控制手段，能帮助你更好地满足数据合规要求。通过服务端部署，你可以拦截并修改传入的请求，将 IP 地址等敏感信息替换掉，最终只将合规数据推送到 GA4 等平台。
下面我们将演示如何在数据发送至 GA4 之前替换原始 IP 地址。
准备工作
即便使用的是 Stape 免费套餐，也完全可以配置 IP 地址匿名化；文中用到的方案均可在 Stape 管理后台或 GTM 服务端容器中直接使用。
开始前，请确保已准备好以下内容：
提示：
借助 Stape 提供的免费工具 Setup Wizard，可自动为多个平台配置 GTM 代码、触发器、变量、客户端等各项资产。
已配置好用户授权管理平台（CMP）（本文以 Iubenda 为例，你也可以使用任何符合自身需求的 CMP）；
第 1 步：启用 Stape 的 GEO Headers 增强插件
GEO Headers 增强插件会提供用来替换用户原始 IP 的目标 IP 地址。它会根据传入 HTTP 请求中访客的真实 IP，解析并填充地理位置请求头。
该插件免费版即可使用。配置步骤：登录 Stape 账号 → 点击你的容器 → 进入 Power-ups 标签页 → 找到 GEO Headers 并点击旁边的 Use → 开启开关 → 点击 Save changes 保存。
第 2 步：创建变量，判断应向 GA4 发送哪个 IP
在这一步中，你需要设定触发条件，决定 Google Analytics 是接收用户的真实 IP 地址，还是接收由 GEO Headers 增强插件生成的 IP 地址。具体逻辑如下：
如果用户同意了分析 Cookie——GA4 会在存储数据或生成报告前，按自身的 IP 处理规则来处理该 IP；
如果用户拒绝授权 analytics_storage——系统会先用插件生成的 IP 替换掉真实 IP，然后再发送给 GA4。
首先，在服务端 GTM 容器中添加变量。进入你的服务端 GTM 容器 → 打开 Templates（模板）部分 → 点击 Search Gallery（搜索社区模板库）→ 搜索 Advanced Lookup Table → 点击 Add to workspace（添加到工作区）。
进入 sGTM 的 Variables（变量）页面 → 点击 New（新建）→ 在变量配置中选择 Advanced Lookup Table。
在该变量中添加一行，设置如下条件：
若 GCS 参数为 G101 或 G111（即已同意 analytics_storage），则返回 x-real-ip 的值。
我们把具体操作拆解为以下几个步骤：
1. GCS 参数变量
GCS 参数即 Google Consent State（谷歌意见征求状态），Google Consent Mode 正是用它向 GA4 等谷歌服务同步用户的授权选择。
你需要建一个变量，用来读取发往 sGTM 容器的请求中的 GCS 参数值。该变量的配置如下：
Variable Type（变量类型）：Event Data（事件数据）
Key Path（键路径）：gcs
2. X-Real-IP 值
X-Real-IP 是一种常见的 HTTP 请求头，代理、负载均衡器、CDN 以及服务器通常用它将客户端的真实 IP 地址透传给后端服务器。
你可以确认一下传入请求中是否带有该参数。方法是：同时在网页端和服务端 GTM 容器中启动预览，触发某个事件，然后切换到“Request”标签页 → 打开“Incoming HTTP Request”。
在传入请求中能看到你的 IP 地址；记录下包含真实 IP 的参数名，稍后建变量时需要用到。
该变量的配置如下：
Variable Type（变量类型）：Request Header（请求头）
Name（名称）：x-real-ip（以我们的配置为例）
到这里，配置此条件所需的准备工作就完成了。在 Advanced Lookup Table 变量中呈现的效果如下：
此外，还需要为该变量添加一条默认条件：
对于其他所有 gcs 值，均返回 X-GEO-Ipaddress 提供的值。
操作方法是：在 Advanced Lookup Table 变量中勾选 Set Default Value（设置默认值），并新建如下变量：
Variable Type（变量类型）：Request Header（请求头）
Name（名称）：X-GEO-Ipaddress
配置完成后的 Advanced Lookup Table 变量如下所示：
第三步：将匿名化 IP 传递给 Google Analytics 4
接下来，需要将上一步创建的变量添加到服务端 GTM 容器的 GA4 基础代码中，这样收集数据时上述规则才能生效。
操作路径为：进入 Tags（代码）页面 → 找到 GA4 代码 → 打开代码中的 Event Parameters（事件参数）部分 → 在“添加/修改参数”中填入 ip_override，对应的值选择上一步配置好的 Advanced Lookup Table 变量。
保存更改。
你可以通过网页端和服务端 GTM 的预览功能来验证配置是否生效。为了更方便地排查问题，建议安装 Stape GTM Helper Chrome 扩展程序。
为什么 Stape GTM Helper 会对这次配置验证大有帮助？原因主要有两点：
该扩展允许你在服务端 GTM 预览模式下查看当前的用户同意（consent）状态。默认情况下，GTM 并不提供这项功能。
请求数据（其中包含 IP 地址）以更结构化的方式列出，便于在调试时快速查看。
我们已针对 Shopify 网站完成了配置，因此该扩展还允许我们排查结账页面的事件问题（通常情况下，受环境限制，GTM 预览模式无法做到这一点）。
现在开始验证配置。在安装 Google Analytics 4 并完成上述 IP 替换逻辑后，务必确认数据流是否正常传输。
1. 在网页端和服务端 GTM 容器中同时启动预览。
2. 在授权横幅（consent banner）中进行操作，将同意状态设为拒绝（reject/deny），随后进行某些操作以触发任意代码。
3. 进入服务端 GTM 调试窗口 → 切换至 Request 标签页 → 在 Outgoing HTTP Requests from Server 区域中，找到包含 Google Analytics 的请求（即发送至 GA4 的请求）。
4. 检查 _uip 参数。如果配置无误，它必须与你的真实 IP 地址不同。
这里的 _uip 会与 Stape GEO Headers 增强功能在传入请求（Incoming request）中提供的值类似，但由于 GA4 默认启用了 IP 匿名化，该值会被略微修改，这完全正常。
这篇文章对你有帮助吗？
来源：Stape Server-Side Tracking Blog · stape.io