使用服务器 GTM 进行无 Cookieless GA4 跟踪

在不断变化的数字环境中，用户追踪和数据隐私方法正在经历重大转变。 网络浏览器正在逐步淘汰第三方 cookies，并且严格的数据隐私法也在不断出台，传统的用户追踪方式正在迅速失去意义。 

对于依赖数据驱动的洞见信息的企业和营销人员来说，不单单是需要适应这些变化，而是绝对必须接受这些变化。 

适应最新追踪挑战的方法之一是转向无 cookie 追踪。 虽然最新版本的 Google Analytics 有很多缺点和不足，但它仍然是最受欢迎的分析平台。 借此，本文将讨论如何使用服务器 Google Tag Manager 设置无 cookie 的 Google Analytics 4 追踪。 

什么是无 cookie 追踪？将链接复制到此节

当网站想记住一些关于您的信息时（比如您的购物车里有什么，或者您登陆网站前点击了什么广告），它们通常会使用一些被称为 "cookies "的小份数据。

但现在，许多网站都不再使用这些 cookie 来追踪用户的活动。 取而代之的是，他们正在使用新的方法，这些方法不依赖于储存在用户浏览器上的数据。 这种不使用 cookie 进行追踪的新方法被称为 "无 cookie 追踪"。

当追踪不依赖 cookie 时，它会使用第一方用户数据。 收集并安全处理这些信息的最佳方法是使用服务器端跟踪。  通过这种方法，您可以跟踪、存储、丰富、转换、严格控制第一方用户数据流。 

这不仅有助于摆脱 Cookie，使追踪更加准确，还使其更加合规，并对用户数据有更大的控制权。 

无 cookie 追踪的好处将链接复制到此节

无 Cookie 追踪能帮助用户适应最近的、与追踪隐私和限制有关的变化。 这里是一些示例。 

1. 法规。欧洲和其他一些国家的数据保护监管机构限制在未经用户同意的情况下使用 cookie。 拒绝 cookie 的用户比例因国家、年龄和 cookie 横幅要求而异。 但总的来说，大约 50% 的人群拒绝市场营销和分析 cookie。
2. 第 3 方 cookie 的衰落。 Safari 和 Firefox 已经限制了第 3 方 cookie ，Brave 不支持第 3 方 cookie， Chrome 计划在 2024 年开始逐步淘汰 cookie。 广告网络使用第三方 cookie 来确定用户在登陆网站前点击了哪些广告，以及登陆网站后的转化情况。 除此之外，分析平台还使用第三方 cookie 来追踪已访问过网站的用户，并显示用户的完整访问旅程。 如果没有 cookie，就很难对新用户和老用户进行适当的转化归因和区分。
3. 完全的追踪限制。Apple 引领了对隐私追踪的限制。 所有的 iOS 应用程序都被要求在追踪用户之前征询用户的许可。 除此之外，iOS 用户可以随时收回给应用程序的许可，禁止它们追踪用户的活动。 另一个崛起的趋势是使用 AdBlocker。 启用广告拦截器后，营销和分析工具不会收到任何有关用户的信息。

背景将链接复制到此节

Google Analytics 4 采用机器学习，对未同意使用分析 cookies 的用户的行为进行建模。 他们利用那些允许分析 Cookie 的、类似的用户的行为来模拟不同意分析 Cookie 的用户的行为。 

要符合机器学习的要求，GA4 属性应满足以下特定条件：

• 所有页面均开启同意模式
• 标签应在同意对话框出现之前触发
• Google 标签在任何情况下都会加载，而不仅仅是在用户同意的情况下
• 每天 1,000 个事件带有 analytics_storage='denied' ，至少维持 7 天。
• 每天有 1,000 名用户在过去 28 天中至少有 7 天发送了 analytics_storage='granted'事件

如果您的 GA4 属性不符合机器学习的条件，或者如果您发现机器学习无法提供准确的结果，您可以选择在用户退出分析 cookies 时依赖第一方数据，并实施无 Cookiel 的 GA4 追踪。 

为使 GA4 正常运作并识别到再次访问的用户，您必须向 GA4 提供以下信息：

• Client ID (cid)
• Session ID (sid)
• Session Count (sct)
• First Visit (_fv)
• User Engagement (seg)

要在用户未同意的情况下设置无 cookie 的 GA4 追踪，我们会使用这些工具：

1. 服务器 Google Tag Manager
2. 服务器 GA4
3. 区分用户同意情况，方法是使用 GA4 gsc 参数。
4. 连接  Google Service Account 到 stape 上
5. 将数据写入 Firestore
6. 从 Firestore 解读数据
7. Stape user ID power-up

在 sGTM 中设置无 Cookie GA4 追踪将链接复制到此节

为了确定是否获得同意，我使用了 gcs 参数。 默认的 GA4 同意配置会向 sGTM 发送请求，但请求中缺少一些信息。 所有的 GA4 请求写入到 Firestore。 

为了确定未同意的用户是否在 GA4 中有活跃的会话，我们将对比上次访问与当前访问的时间戳差异。 如果差异超过 30 分钟，我们将更新 Firestore 中的会话参数。 

Firestore 将使用 UserID 作为文档名称，并在这些文档中保存用户会话的详细信息。 这是组织 Firestore 的直接方法，还有许多其他方法可以维护 Firebase 中完整的用户体验的数据。

1. 同意使用分析 cookie 的用户。将链接复制到此节

1.1 使用默认 GA4 服务器端设置。

1.2 如果有需要，将数据写入 Firestore。 为此，我使用 Firestore Writer 标签。 请在如何使用 Firestore Writer 标签中获得详细的指南。 我使用 UserID 集合。 我为每个 user ID 创建一个新的文档，将 cid 当作文档名。 

1.3 GA4 服务器端标签拥有标准的配置，每次 GA4 客户端被调用以及用户同意使用分析 Cookie 时都会触发。 

2. 未同意使用分析 cookie 的用户将链接复制到此节

2.1 现存的、拥有活跃会话的用户将链接复制到此节

2.1.1 如果未同意使用分析 cookie，我使用 Stape User ID power-up ，添加 user ID 到 sGTM 请求标题。 

2.1.2 借助 Firestore Writer 标签 的帮助，我将数据写入 Firestore 然后将 Stape User ID 用作文档名称。

2.1.3 要确认会话是否活跃，我使用 Firestore Reader 变量来提取与该用户上次访问 Firebase 相关联的时间戳。 之后，查看用户上一个会话时间戳与当前时间戳之间的差值。 如果时间戳差值小于 30 分钟，那么用户存在会话。

2.1.4 参数按照以下方式更新：

• cid 以及 client_id 是 Stape UserID 的值
• ga_session_number - 是 Firestore 中 ga_session__number 的值
• ga_session_id - 是 Firestore 中 ga_session_id 的值
• x-ga-mp2-seg（参与会话）设置为1
• x-ga-system_properties.fv（首次访问），x-ga-system_properties.ss（会话开始），移除 x-ga-system_properties.nsi（新会话 ID）  。

2.1.5 发送已修改数据到 GA4。 为了在向 GA4 发送数据之前更新数据，我使用了转换功能。 

2.2 现存的、无活跃会话的用户将链接复制到此节

2.2.1 如果未同意使用分析 cookie，我使用 Stape User ID power-up ，添加 user ID 到 sGTM 请求标题。 

2.2.2 借助 Firestore Writer 标签，再次根据 Stape User ID 在 Firestore 中写入用户数据。  

2.2.3 为了检查会话是否处于活跃状态，我使用 Firestore Reader 变量来提取 Firebase 中与该用户相关联的时间戳。 之后，查看用户上一个会话时间戳与当前时间戳之间的差值。 如果时间戳差值小于 30 分钟，那么新的会话已开启。 

2.2.4 参数按照以下方式更新：

• cid 以及 client_id 是 Stape UserID 的值。
• ga_session_id 是来自 Firestore 的 ga_session_id 值，之前设置为以秒为单位的时间戳。
• ga_session_number 是 Firestore 中的 ga_session_number 数字加 1。
• x-ga-system_properties.ss（会话开启）设置为 1。
• x-ga-mp2-seg （参与会话）设置为1。
• 移除 x-ga-system_properties.fv。

2.2.5 发送已修改数据到 GA4。 为了在向 GA4 发送数据之前更新数据，我使用了转换功能。 每次 GA4 客户端被调用以及用户未同意且会话之间的时间差超过 30 分钟时，标签就会触发。 

2.3 新用户将链接复制到此节

2.3.1. 如果分析 cookie 不被用户允许，则使用 Stape 的 User ID power-up 来生成一个 user ID。

2.3.2. 确认是否有具备相同 UserID 的用户存在于 Firestore。 如果找不到具有相同 user ID 的用户，使用一个 Firestore Writer 标签 在数据库中创建一个带会话详细信息的用户。

2.3.3 参数按照以下方式更新：

• cid 以及 client_id 是 Stape UserID 的值。
• ga_session_id 是 Firebase 的 ga_session_id。
• ga_session_number 是您在 Firestore 中拥有的 ga_session_number 数字。
• x-ga-system_properties.ss（会话开启）设置为 1。
• x-ga-mp2-seg（参与会话）设置为1
• x-ga-system_properties.fv（首次访问）设置为 1。

2.3.4 发送已修改数据到 GA4。 

总结将链接复制到此节

通过服务器 Google Tag Manager 实施无 cookie 的 Google Analytics 4 追踪迈出了重要的一步，帮助用户适应不断变化的线上数据隐私和用户偏好情况。 随着数字世界的不断发展，在不依赖 cookie 的情况下收集有价值的见解变得非常重要。 

在利用服务器端追踪以及 Google Tag Manager 的强大功能之后，企业可以在利用 GA4 带来的重要数据驱动洞见信息的同时保障数据隐私。 这种方法不仅能确保企业遵守新出现的法规，还能培养用户对其网络隐私的信任。 在我们穿梭于无 cookie 的未来旅程中，采用服务器端追踪和 GA4 等创新解决方案可以帮助企业在数字领域保持竞争力，确保相关性。