Data Store 实用用例：如何满足您的跟踪需求

Data Store 是面向服务端 Google Tag Manager 用户的内置 NoSQL 数据库。它快速、可靠且易于使用——无需配置外部数据库，即可存储和检索任何类型的 JSON 数据。

虽然它最初的设计初衷是简化服务端容器内的数据管理，但许多企业已经以多种极富创意的方式应用 Data Store。若要全面了解此功能、其各项能力以及如何充分利用它，请参阅我们关于 Data Store 的详细指南。在本文中，让我们来看看利用 Data Store 的一些最常见且最有趣的方式，以及您如何也能从中获益。

许多用户选择 Data Store 作为 Firestore 的替代方案。他们用它来存储从客户数据到购买记录的所有内容（例如保存客户购买过的所有商品）。这样做的理由各有不同——例如，Data Store 直接内置于 Stape 平台中，因此无需任何外部配置。您无需离开 Stape 账户，即可立即在 sGTM 容器内开始保存和读取数据。

有些用户甚至在购买 Stape 订阅后，不使用增强功能、sGTM 托管或 Store 之外的任何服务。对他们来说，单是 Store 功能本身就物有所值！

其主要优势在于架构更加精简：团队无需额外配置数据库、管理凭据和维护附加集成，而是可以直接使用已作为 Stape 托管 sGTM 架构一部分的存储层。

另一个热门用例是检测重复交易。重复转化可能会虚增分析数据，并在 Google Ads 或 Google Analytics 等平台中导致错误的归因。通过将交易 ID 存储在 Data Store 中，您可以轻松检查转化是否已被处理。该配置对于通过 API 上传转化的服务端跟踪非常实用。

相同的方法可用于任何需要去重的流程，包括事件 ID、订单 ID、线索 ID、Webhook ID 或其他唯一的业务标识符。

其优势所在：

• 指标准确：每笔交易仅被统计一次。
• 归因更优：防止将错误的贡献分配给多个渠道。
• 预算更明智：有助于基于干净、可信的数据分配广告预算。

Webhook 可在 Web 应用之间实时自动传输数据。我们的一些客户使用 Data Store 为 Webhook 添加额外数据。这种方法可确保您的跟踪事件始终包含完整的上下文信息。其工作流程如下：

1. 1.
   当用户执行在线操作（例如提交表单）时，您可以将其 Cookie 或标识符保存在 Store 中，并以其电子邮件等作为键。
2. 2.
   随后，当收到 Webhook 事件时，您在 Store 中查询相同的键，检索用户数据，并将包含 Cookie 和标识符的完整数据集发送至 Google Ads 或 Meta Conversions API 等平台。

Stape 的 Enricher 增强功能已经支持使用先前收集的用户数据来扩充事件数据。然而，与 Data Store 结合使用时，您还可以使用纯后端数据来丰富事件。

将 Data Store 用于数据扩充的另一个用途是添加不应或无法在浏览器中公开的信息，例如 CRM 状态、客户层级、内部商品分类、库存状态、账户归属、利润率数据或履约结果。发送至分析或广告平台的扩充后事件携带着客户端跟踪本身无法提供的业务上下文。

跨网域跟踪往往会失效，因为 Cookie 无法在不同网域之间共享。

借助 Data Store，您可以将 Cookie 或标识符保存在共享键（例如 User ID）下，并在同一用户访问另一个网域时将其还原。这样，您的用户数据就能保持一致，分析工具也能跨不同网站准确归因转化。

实际运作方式：

1. 1.
   当用户访问您的第一个网域时，您将关键跟踪数据（Cookie、会话 ID、用户标识符）存储在 Data Store 中。
2. 2.
   当同一用户在另一个网域上继续其浏览旅程时，系统会使用共享标识符从 Data Store 中检索已存储的数据。
3. 3.
   这些还原的数据有助于保持访问与转化之间的关联，确保您的分析和广告平台能够识别出这是同一位用户。

同样的模式还可以扩展到网站之外。当客户从网站转移到 CRM、呼叫中心或其他线下流程时，您可以保留归因上下文，并在后端事件或 Webhook 到达时恢复相关的标识符。

大多数广告主使用 ROAS（广告支出回报率）来衡量效果，但 ROAS 并未计入商品成本。广告支出利润率（POAS）是一项更为精确的指标，它关注的是实际利润，而不仅仅是收入。

Stape 已提供专用的 POAS Data Feed 增强功能，可让您安全地存储和检索利润数据，并在向 Google Ads 或 Analytics 报告转化时用其替代收入。而 Data Store 进一步增强了此功能，支持更高级的 POAS 计算。

例如，利润可能取决于 SKU、市场、折扣、运费、支付手续费、佣金、退货或客户群体。这些数据可以在服务端进行存储，并在将转化数据发送到您的分析或广告平台之前，用于计算出更精确的利润值。

• 在确保敏感财务数据私密性的同时，实施基于利润的出价。
• 实时上传转化数据，无需公开内部机密数据。
• 更真实地了解哪些广告真正带来了利润，而不仅仅是销量。

Click ID 通常存储在浏览器 Cookie 中，但 Cookie 可能会过期、被拦截、无法供后端系统使用，或在后续转化中无法传递归因数据。Data Store 提供了另一个持久化存储这些标识符的场所。

例如，您可以将 Click ID 存储在稳定的键下，如 User ID、会话 ID、线索 ID 或订单 ID。稍后发生转化时，可以使用该键检索 Click ID 并将其添加到转化事件中。这种方法仍需要一个稳定的标识符将原始点击与后续事件关联起来。但它能够让归因数据在基于浏览器的存储不再可用时依然得以留存。

最后，几乎在任何需要临时或长期存储数据并供日后使用的场景中，Data Store 都能发挥作用。它比 Cookie 或本地存储更可靠、更具扩展性。您只需一个键即可写入和检索数据，例如用户电子邮件、ID 或会话令牌。

• 创建文档和集合以保存多个文件。
• 使用条件进行搜索和筛选。 
• 为文档设置 TTL（生存时间），以便在不再需要时自动过期。 
• 检索并使用存储中的数据来丰富您的服务端 GTM 事件流（例如用户属性、自定义参数、令牌）。 
• 使用 API 通过端点以编程方式访问存储。

当映射关系庞大、更新频繁或涉及操作敏感性时，标准的 GTM 查找表可能会变得难以管理。Data Store 可以代为保存这些数据集。

例如，您可以存储商品规则、广告系列分类、区域设置、租户映射或其他配置值。之后，您可以直接通过 Stape 控制面板、CSV 导入或 API 进行更新，而无需在每次值发生更改时重新发布 sGTM 容器。

同样的方法还可用于根据品牌、地区、租户、商家、事件类型或意见征求状态等因素，动态选择目标平台、账户、端点或凭据。

当用户身份明确后，Data Store 可以帮助将其匿名活动与其身份及先前的操作关联起来。这也让新客户与老客户的跟踪变得更加可靠。

例如，访客在登录或提交表单之前可能会浏览您的网站。您可以存储其匿名浏览器或会话标识符与客户标识符之间的对应关系。一旦该用户身份明确，后续事件便可利用这种对应关系检索经批准的身份属性，并在先前匿名的会话之间保持连续性。

意见征求信息通常在浏览器中可用，但当事件来自 CRM、Webhook、线下系统或其他后端来源时则往往缺失。Data Store 可以保留用户的意见征求状态以及来源、时间戳或政策版本等元数据。

当后续后端事件到达时，可以在决定允许哪些目标平台和参数之前检索已存储的意见征求状态。这有助于对非浏览器事件应用一致的意见征求规则。

在某些情况下，标准日志不会保留排查跟踪问题所需的请求载荷或特定字段。Data Store 可以将选定的请求数据临时保存在专用集合中以供调试。

应谨慎使用此方法：应用精细的触发器、较短的 TTL、数据最小化以及 PII 过滤。存储每个请求可能会带来不必要的隐私风险，并迅速消耗数据库写入配额。

Data Store 已从一个简单的功能演变为一个强大的工具，可支持广泛的跟踪和数据用例。借助它，您可以设置跨网域跟踪、解决重复交易问题、构建轻量级 CDP，或仅仅存储数据以供备用。

由于它直接内置于 Stape 平台中，因此无需配置或维护外部数据库。您可以直接在服务端 GTM 容器内开始保存和检索数据。Data Store 可以替代 Firestore 等工具，同时将所有内容整合在统一平台下。