“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）这类问题，显然更加消耗时间和精力，且随着排查时间的增加，心理压力也会逐渐变大。
一个案例通常不具备代表性，但案例背后的解决思路和方法往往是相通的。
对于本质相同，只是表现形式略有差异的排查类问题，上文所给出的处理流程和技巧，希望能给读者带来灵感和启发。