案例分享丨GA丢失交易数据?你需要这些技巧

“GA统计的订单数为什么与后台订单数不一致?”

对于使用GA的小伙伴,这类数据gap问题,也就是“丢单”的情况并不陌生。

今天本文将结合一个实际数据gap案例,为各位提供一些此类问题的排查思路,并在文章的最后一部分介绍:当面对没有错误日志的这类bug时,可以如何着手解决。

案例分享

案例背景

一个电商网站基于GA实现页面埋点,使用GTM管理网站上全部网页的GA代码。GA交易事件的发送时机是用户支付成功后,跳转到支付成功页,交易事件会在该页面加载时触发。

问题描述

埋点上线一周后,对比GA的“销售业绩”报表和电商后台数据库订单表,发现GA记录的数据量比后台少10%-20%。

通常普遍可接受的数据gap在5%以内(其实用户禁用浏览器cookie的比例大约也在5%左右)

另外,这个问题的特点是:没有报错日志,也就是说,没有任何线索可以具体定位导致gap产生的原因。

排查过程

笔者作为工程师,最先想到是和技术相关的原因。比如,“是不是代码有问题”,但这个猜测很快被推翻,因为代码的问题通常会造成全局性的影响。换句话说,如果代码有问题,GA的“销售业绩”报表中的数据量应该为0,而不是仅仅只丢了10%-20%。

那么,下一步就自然想到会不会是代码管理工具的问题(GTM),因为毕竟代码没有和页面直接产生联系,中间借助了GTM这个“桥梁”。

为了验证这个猜测,我们将支付成功页的代码从GTM中剥离出来,直接粘贴到页面上执行。结果是,gap仍维持在原来水平。

这个时候排查工作进入瓶颈,但在继续检查的过程中,发现上一步的交易测试环节中,电商网站的支付成功页是两个,而不是一直认为的一个。

问题就此定位,另一个被遗漏的页面没有部署GA代码。进行相应的措施后,我们基本笃定这个问题已经解决,认为gap会回到正常水平。

但经过几天的观察,发现gap依然保持在10%以上。这就意味着导致丢单的原因不止上述的一个,并且比较隐蔽。

我们重新从逻辑上,尽可能多地、系统地、大范围地梳理出可能导致丢单的原因,并逐一进行假设验证。

通过这种方式,我们很快成功地将原因定位在两边报表计数逻辑不同这一点上。

这造成GA交易代码虽然部署正确,但支付成功页上的交易代码在发起请求时,获取不到交易id的情况。

尽管在代码部署时,我们严格遵循了gtag.js的交易代码规范,但如果传值中缺少交易id,那这条代码就会被归类为普通事件代码(需要注意,没有交易id传值的事件依然是能发送成功的,只不过它会被认为是普通事件,而不是电商事件)

而普通事件记录的数据不会在“销售业绩”报表中展示,这就是电商后台订单表和GA“销售业绩”报表中存在数据gap的原因。

(gtag.js的交易代码规范)

经验总结

如何解决数据gap问题

结合上述的案例,以及过往的经验,总结了以下几个解决思路,当我们遇到数据gap的问题时,可以尝试以此作为切入点进行排查:

1、剖析本质

产生数据gap的本质原因是:两边报表的计数逻辑不同。对于排查人员来说,需要做的就是,准确找出它们的计数逻辑具体在哪里产生差异。

2、解决思路

对于排查类的问题,可以分两个步骤进行:

第一步,定位原因;

第二步,对症下药。

难点在于第一步,因为导致丢单的原因很多。当定位到原因后,后续的解决工作并不难。所以,下文将着重围绕如何定位原因展开讨论。

在进行原因排查、定位的时候,有以下几个建议:

首先,从类别上对可能导致丢单的原因进行粗粒度划分。比如,可以将原因归结为如下三大类:

第一类:技术原因;

第二类:GA账户配置原因;

第三类:非技术、非工具配置上的原因。

此后,再进一步进行细分。这一步花费时间比较多,但是很重要,能否定位到原因,很大程度上依赖于这一部分的工作。

以下是我们团队在排查时,梳理出的原因明细,以供各位参考:

技术原因:

① 代码有没有bug;

② GTM的触发器设置是否有误;

③ 结账流程中是否存在GA代码未触发或触发失败的情况;

④ 是否存在交易代码正常触发,但订单信息传值不完整的情况;

⑤ GTM容器代码是否加载失败。

GA账户设置原因:

① GA报告时区是否和后台数据库时区一致;

② 是否被数据视图的过滤器过滤掉了一部分订单。

非技术、非工具配置上的原因:

① 是否存在不需要登录网站就能下单的其他交易渠道;

② 是否存在未部署GA代码的页面。比如,支付成功页可能不止一个;

③ 支付成功页加载过程中就被关闭。比如,用户提前关闭页面或有网络波动;

④ 用户支付成功后,是否存在不返回支付成功页的场景;

⑤ 用户禁用cookie。

当然,原因可能远不止上述所罗列的内容。但不必过于纠结梳理的是否全面,因为这点并不影响下一步的工作。

如果我们在假设和验证的环节中,已经把罗列的原因全部排除之后,仍没有定位到原因,那就需要返回第一步,继续找思路罗列原因。在这个过程中,如果实在觉得无计可施,不妨求助于GA帮助中心或google support team寻找思路。

其实,这类数据gap问题可以进一步归类为没有错误日志的bug问题。它们具有一致特征,就是初期无法直接追溯其产生的原因。

那面对这种没有任何解决线索的bug,该按什么步骤进行处理?

如何解决没有日志的bug

解决这个问题其实就是一个不断排除的过程。看以下的图片更为直观:

分步骤拆解一下上图的内容:

① 首先,分析出理论上可以导致问题产生的原因有哪些,一一枚举出来。就像上文所提到的。

② 其次,对各个原因进行排序,排序标准可以是:

  • 以往的工作经验(比如,你曾经因为这个原因产生过gap,这类原因可以往前排);
  • 出现概率(比如,GTM导致丢数的可能性其实很低,这类原因应该往后排);
  • 验证快捷性(比如,两个存储容器是否有时差,这类简单查看或询问就可以排除的原因,应该往前排)。

③ 最后,对原因逐个假设、验证。

如果已经排除了所有可能,那需要重回第一步,继续梳理新的原因,循环执行排查流程,直到定位出原因。

比如说,在本文开头提到的案例中,我们为了验证交易id丢失是造成丢单的原因,调整了代码,使GA交易事件仅在交易id不为null且不为undefined时才发送,观察一段时间后,发现事件报告和“销售业绩”报表的数据量一致,都比后台少10%。

这就证明了“产生gap的原因是丢失交易id”的假设是正确的。

相比于简单粘贴即可通过搜索错误日志解决的bug,丢单排查(即没有日志的bug)这类问题,显然更加消耗时间和精力,且随着排查时间的增加,心理压力也会逐渐变大。

一个案例通常不具备代表性,但案例背后的解决思路和方法往往是相通的。

对于本质相同,只是表现形式略有差异的排查类问题,上文所给出的处理流程和技巧,希望能给读者带来灵感和启发。

发表评论

邮箱地址不会被公开。 必填项已用*标注