如何监控数据质量——详细指南

防止数据收集中的错误比处理其后果更容易。 您的业​​务决策是否明智取决于数据的质量。 在本文中，我们将告诉您如何在收集的所有阶段（从工作说明到完成的报告）检查数据的质量。

不幸的是，许多花费大量资源存储和处理数据的公司仍然根据直觉和他们自己的期望而不是数据做出重要决策。

为什么会这样？ 数据提供的答案与决策者的期望不一致的情况会加剧对数据的不信任。 此外，如果有人过去在数据或报告中遇到过错误，他们倾向于倾向于直觉。 这是可以理解的，因为根据不正确的数据做出的决定可能会让你倒退而不是让你前进。

想象一下，您有一个多币种项目。 您的分析师以一种货币设置了 Google Analytics，而负责上下文广告的营销人员设置了以另一种货币导入 Google Analytics 的成本。 因此，您的广告活动报告中的广告支出回报率 (ROAS) 不切实际。 如果您没有及时注意到此错误，您可能会禁用盈利活动或增加亏损活动的预算。

此外，开发人员通常很忙，实施 Web 分析对他们来说是次要任务。 在实施新功能时——例如，带有附件的单元的新设计——开发人员可能会忘记检查谷歌分析是否正在收集数据。 结果，当评估新设计的有效性时，结果发现数据收集在两周前就被破坏了。 惊喜。

想象一下，您在规范阶段犯了一个错误。 如果你找到它并立即纠正它，修复将相对便宜。 如果在实施后、构建报告时、甚至在决策时发现错误，修复它的成本将非常高。

数据收集通常包括五个关键步骤：

1. 制定业务挑战。 假设您需要评估算法在推荐块中选择商品的效率。
2. 负责数据收集的分析师或人员设计了一个要在站点上跟踪的指标系统。
3. 此人设置 Google Analytics 和 Google Tag Manager。
4. 一个发送参考条款供开发人员实施。
5. 在开发人员实施指标并设置数据收集后，分析师将使用报告。

在几乎所有这些阶段，检查您的数据都非常重要。 有必要测试技术文档、谷歌分析和谷歌标签管理器设置，当然还有在您的网站或移动应用程序中收集的数据的质量。

在进行每一步之前，我们先来看看数据测试的一些要求：

• 没有工具就无法测试。 至少，您必须在浏览器中使用开发者控制台。
• 没有抽象的预期结果。 你需要确切地知道你最终应该得到什么。 对于与网站的任何用户交互，我们总是需要收集一组特定的参数。 我们知道这些参数应该取的值。
• 需要特殊知识。 至少，您需要熟悉您使用的网络分析工具的文档、实践和市场参与者的经验。

正如我们所提到的，如果您在规范中发现错误，则更容易纠正错误。 因此，在收集数据之前很久就开始检查文档。 让我们弄清楚为什么我们需要检查您的文档。

测试文档的目的：

• 毫不费力地修复错误。 文档中的错误只是书面文本中的错误，因此您所要做的就是快速编辑。
• 防止将来需要进行可能影响站点/应用程序架构的更改。
• 保护分析师的声誉。 一份在制定过程中出现错误的文书可能会质疑起草人的能力。

规格中最常见的错误：

1. 错别字。 开发人员可以在不阅读参数的情况下复制参数名称。 这与语法或拼写错误无关，而是与参数名称或这些参数所包含的值有关。
2. 跟踪事件时忽略字段。 例如，如果表单未成功提交，则可能会忽略错误消息。
3. 字段名称无效且与增强型电子商务方案不匹配。 使用dataLayer变量实现增强型电子商务需要清晰的文档。 因此，在起草规范时最好检查所有字段两次。
4. 您没有多币种网站的货币支持。 此问题与所有与收入相关的报告有关。
5. 不考虑命中限制。 例如，假设目录页面上最多可以有 30 种不同的产品。 如果我们同时传输所有产品的浏览量信息，Google Analytics（分析）中的匹配很可能不会被传输。

检查技术文档后的下一步是检查您的 Google Analytics（分析）和 Google Tag Manager 设置。

为什么要测试 Google Analytics 和 Google Tag Manager 设置？

• 确保数据收集系统正确处理参数。 Google Analytics 和 Google Tag Manager 可以与您网站上的指标实施并行配置。 在分析完成之前，数据不会出现在 Google Analytics 中。
• 更容易测试嵌入在网站上的指标。 您只需要专注于开发人员的部分工作。 在 X 的最后阶段，您需要直接在站点上查找错误原因，而不是在平台设置中。
• 维修成本低，无需开发人员参与。

Google Analytics 中最常见的错误：

1. 未创建自定义变量。 这对于 Google Analytics 360 帐户尤其重要，它可以有多达 200 个指标和 200 个参数。 在这种情况下，很容易错过一个。
2. 指定的访问范围无效。 您将无法在 dataLayer 审核阶段或通过查看您发送的匹配来发现此错误，但是当您创建报告时，您会发现数据看起来不像预期的那样。
3. 您会得到一个现有参数的副本。 此错误不会影响正在发送的数据，但可能会在检查和构建报告时导致问题。

Google 跟踪代码管理器中最常见的错误：

1. 未添加任何参数，例如 Universal Analytics 代码或 Google Analytics 设置变量。
2. 代码中的索引与 Google Analytics 中的参数不匹配，从而产生将值传递给错误参数的风险。 例如，假设您在 GTM 中为 item rating 参数指定了 number of users 参数的索引。 在构建报告时可能会立即发现此错误，但您将无法再影响收集的数据。
3. 在 dataLayer 中指定的变量名无效。 创建 dataLayer 时，请务必指定将在 dataLayer 数组中找到变量的名称。 如果您键入或写入另一个值，则永远不会从 dataLayer 中读取此变量。
4. 未启用增强型电子商务跟踪。
5. 启动触发器配置不正确。 例如触发X的正则表达式写错或事件名称有错误。

测试的最后阶段是直接在站点上进行测试。 这个阶段需要更多的技术知识，因为您需要查看代码、检查容器的安装方式以及阅读日志。 因此，您需要精明并使用正确的工具。

为什么要测试嵌入式指标？

• 检查实施的内容是否符合规范并记录任何错误。
• 检查要发送的值是否足够。 验证参数是否正在传输要传输的值。 例如，商品类别不传递其名称。
• 向开发人员提供有关实施质量的反馈。 根据此反馈，开发人员可以对站点进行更改。

最常见的错误：

1. 并未涵盖所有场景。 例如，假设可以将一个项目添加到产品、目录、促销或母版页上的购物车中——也就是说，任何有项目链接的地方。 有这么多的入口点，你可能会错过一些东西。
2. 该任务并未在所有页面上实施。 也就是说，对于某些页面或某些分区/目录，根本不收集数据或仅收集部分数据。 为了防止这种情况，我们可以制定一份清单。 在某些情况下，我们可以对一个函数进行多达 100 次检查。
3. 并非所有参数都实现； 也就是说，dataLayer 只是部分实现。
4. 用于增强电子商务的 dataLayer 方案已损坏。 对于诸如将商品添加到购物车、在结账步骤之间移动以及单击商品等事件尤其如此。 实施增强型电子商务的最常见错误之一是Products数组中缺少方括号。
5. dataLayer 使用空字符串而不是 null 或 undefined 将参数归零。 在这种情况下，Google Analytics 报告包含空行。 如果您使用 null 或 undefined，则此选项甚至不会包含在您发送的命中中。

我们用来测试数据的工具：

• 谷歌分析调试器 Chrome 扩展
• GTM 调试器，您可以使用它在 Google 跟踪代码管理器中启用预览模式
• 开发者控制台中的dataLayer命令
• 开发者控制台中的网络选项卡
• 谷歌标签助手 Chrome 扩展

让我们仔细看看这些工具。

要开始使用，您需要在浏览器中安装此扩展并启用它。 然后打开页面 ID 并转到控制台选项卡。 您看到的信息由扩展程序提供。

此屏幕显示与命中一起传输的参数以及为这些参数传输的值：

还有一个扩展的电子商务块。 您可以在控制台中以ec的形式找到它：

此外，此处还会显示错误消息，例如超出命中大小限制。

如果您需要检查 dataLayer 的组成，最简单的方法是在控制台中键入dataLayer命令：

这是传输的所有参数。 您可以详细研究它们并验证它们。 站点上的每个操作都反映在 dataLayer 中。 假设您有七个对象。 如果单击空白字段并再次调用dataLayer命令，控制台中应该会出现第八个对象。

要访问 Google Tag Manager Debugger，请打开您的 Google Tag Manager 帐户并点击Preview按钮：

然后打开您的网站并刷新页面。 在下部窗格中，应该会出现一个面板，显示该页面上运行的所有标签。

添加到 dataLayer 的事件显示在左侧。 通过单击它们，您可以检查数据层的实时组成。

移动浏览器测试的特点：

• 在智能手机和平板电脑上，网站可以以自适应模式启动，也可以有单独的移动版网站。 如果您在桌面上运行网站的移动版本，它将与您手机上的相同版本不同。
• 通常，扩展程序不能安装在移动浏览器中。
• 为了弥补这一点，您必须在 Universal Analytics 代码或网站上的 Google Analytics 跟踪代码中启用调试模式。

移动应用测试的特点：

• 使用应用程序代码需要更多的技术知识。
• 您需要一个本地代理服务器来拦截命中。 为了跟踪设备发送的请求数量，您可以按应用程序名称或请求发送到的主机过滤请求。
• 所有匹配均以 Measurement Protocol 格式收集，需要额外处理。 收集和过滤命中后，必须将它们复制并解析为参数。 您可以使用任何方便的工具来执行此操作：Hit Builder、Google 表格中的公式或 JavaScript 或 Python 应用程序。 这一切都取决于什么对您更方便。 此外，您需要了解 Measurement Protocol 参数来识别已发送匹配中的错误。

1. 通过 USB 将您的移动设备连接到您的笔记本电脑。
2. 在您的设备上打开谷歌浏览器。
3. 在 Chrome 开发者控制台中，打开远程设备报告：

1. 通过单击对话框中的确定来确认与您的设备的连接。 然后选择您要检查的选项卡并单击Inspect 。
2. 现在您可以在标准模式下使用开发人员控制台，就像在浏览器中一样。 您将拥有所有熟悉的选项卡：控制台、网络等。

1. 要使用移动应用程序，您必须安装并运行代理服务器。 我们推荐查尔斯。
2. 安装了您的代理服务器，检查应用程序连接到哪个 IP 地址：

3. 然后拿起您的设备并使用端口 8888 通过代理服务器配置 Wi-Fi 连接。这是 Charles 默认使用的端口。

4. 之后，是时候收集热门歌曲了。 请注意，在应用程序中，命中不是发送到收集而是发送到批处理。 Batch 是一个打包的请求，可以帮助您发送多个请求。 首先，它节省了应用程序资源。 其次，如果出现网络问题，请求将存储在应用程序中，并在网络连接重新建立后立即发送一个公共池。

5. 最后，必须将收集到的数据解析（反汇编）为参数，按顺序检查，并根据规范检查。

这一步是最快和最简单的。 同时，它确保在 Google Analytics 中收集的数据是有意义的。 在您的报告中，您可以检查数百种不同的场景，并根据设备、浏览器等查看指标。如果您发现数据中有任何异常，您可以在特定设备和特定浏览器中播放脚本。

您还可以使用 Google Analytics 报告来检查传输到 dataLayer 的数据的完整性。 即根据每个场景，填充变量，里面是否有所有参数，参数是否取正确的值等等。

我们希望分享最有用的报告（在我们看来）。 您可以将它们用作数据收集清单：

• 电子商务报告：
  • 产品性能
  • 产品列表表现
  • 内部推广
• 行为 - 事件 - 热门事件
• 收购——活动——成本分析
• 自定义报告——例如，显示重复订单的报告

让我们看看这些报告在界面中是什么样的，以及这些报告中你需要首先关注哪些。

该报告中最有价值的标签是购物行为。 它分析了增强电子商务每个阶段数据收集的完整性。 也就是说，我们可以看到谷歌分析是否传输产品列表视图、点击、产品详细视图、添加/删除产品到/从购物篮，以及购买本身。

这里我们应该注意什么？ 首先，如果任何列中的值为零，这很奇怪。 其次，如果您在某个阶段的值比前一阶段的多，那么您在收集数据时可能会遇到问题。 例如，假设某件商品的唯一购买次数大于结帐次数。 这很奇怪，值得关注。

您还可以在此报告中的其他参数之间切换，这些参数也应发送到增强型电子商务。 例如，如果您选择项目类别作为主要选项，您可能会看到某些类别的项目有销售，但这些项目没有视图，没有添加到购物车等。

首先，有必要遍历传输到 Google Analytics 的所有参数，并查看每个参数的值。 通常情况下，一切是否正常都会立即清楚。 可以在自定义报告中对每个事件进行更详细的分析。

另一个可用于检查将费用数据导入 Google Analytics 的标准报告是成本分析。

我们经常看到某些来源或广告活动有费用但没有会话的报告。 这可能是由 UTM 标签中的问题或错误引起的。 或者，Google Analytics 中的过滤器可能会排除来自特定来源的会话。 这些报告需要不时检查。

我们想强调允许您跟踪重复交易的自定义报告。 设置非常简单：参数必须是交易 ID，关键维度必须是交易。

请注意，当报告中有多个交易时，这意味着有关同一订单的信息被多次发送。

如果您发现类似问题，请阅读这些有关如何解决问题的详细说明。

Google Analytics 有一个非常好的自定义警报工具，可以让您在不查看报告的情况下跟踪重要更改。 例如，如果您停止收集有关 Google Analytics 会话的信息，您会收到一封电子邮件通知。

我们建议您至少为以下四个指标设置通知：

• 会话数
• 跳出率
• 收入
• 交易数量

根据我们的经验，这是最困难和最耗时的任务——错误最常见的窄线。

为避免 dataLayer 实现出现问题，必须每周至少进行一次检查。 一般来说，频率应该取决于您在网站上实施更改的频率。 理想情况下，您需要在每次重大更改后测试 dataLayer。 手动执行此操作非常耗时，因此我们决定自动化该过程。

为了自动化测试，我们构建了一个基于云的解决方案，使我们能够：

• 检查站点上的dataLayer变量是否与参考值匹配
• 检查 Google 跟踪代码管理器代码的可用性和功能
• 检查数据是否发送到 Google Analytics 和 OWOX BI
• 在 Google BigQuery 中收集错误报告

测试自动化的优势：

• 显着提高测试速度。 根据我们的经验，您可以在几个小时内测试数千个页面。
• 获得更准确的结果，因为排除了人为因素。
• 降低测试成本，因为您需要更少的专家。
• 增加测试频率，因为您可以在每次更改站点后运行测试。

我们使用的算法的简化方案：

当您登录我们的应用程序时，您需要指定要验证的页面。 您可以通过上传 CSV 文件、指定站点地图的链接或简单地指定站点 URL 来执行此操作，在这种情况下，应用程序将自行查找站点地图。

然后为每个要测试的场景指定 dataLayer 方案很重要：页面、事件、脚本（一系列操作，例如结帐）。 然后您可以使用正则表达式来指定页面类型与 URL 匹配。

在收到所有这些信息后，我们的应用程序会按计划运行所有页面和事件，检查每个脚本，并将测试结果上传到 Google BigQuery。 基于这些数据，我们设置了电子邮件和 Slack 通知。

PS 如果您需要全面的网站审核，您可以向 OWOX BI 请求咨询服务。 注册一个演示，我们将讨论可能性。