当需要针对数据进行结果分析，但却发现所采集的数据不全，这时候该如何补救？作者结合宝石电商项目，列举了几种分析思路，谈谈在数据不全的情况下，如何进行数据分析，一起来看看。
这是一个垂类电商网站的数据分析项目，卖石头的，宝石！
客单价高，逢年过节客流大，主要靠回头客。
刚接触时，他们只采集了5个数据：
万幸，购物流程数据都被囊括进去了。
我对购物流程，做了一个漏斗图（当时用的数据分析工具，虽然有漏斗功能，但没有做好相关设置，无法使用，这里的漏斗只是表现形式），数据经过脱敏和取整处理后的示意图如下：
给刚进入数据分析领域的小伙伴解释一下：采集了页面浏览，不但可以计算出漏斗顶端的访问次数，还可以单独查看某个页面的浏览数据，也就是漏斗底部付款成功页的数据了。
PS：本文的后续数据都是经过脱敏和取整处理的。
虽然数据不多，但也能找到流失最大的地方了。即，漏斗的第一步和最后一步分别只有0.7%和0.29%，远远低于其他步骤，要最先分析。
你会先分析哪一个步骤呢？或者说，你汇报时，会先呈现哪部分呢？
我的选择是先聊最后一步，差一点就能收到钱了，更让人觉得惋惜，调整之后也更容易见效。
然后，我发现：没有采集到付款成功页数据≠没有付款成功，因为订单页面有一个选项是货到付款，这个数据没有采集，只能询问客户后台收款数据。（我们没有直接查看客户后台数据的权限，只能用的时候，去要。）
果不其然，在线收款数据是93，比付款成功页浏览次数少7，而总收款数据=在线收款数据+货到收款数据=2,200。（注：对买宝石的人而言是付款，所以网站页面上写的是付款；对卖宝石的人而言是收款，所以后台数据是收款）
客户怀疑自己的在线收款系统有问题，因为在线收款数据比付款成功页浏览次数少。
这让我意识到自己刚才的疏漏，最后一步不应该用付款成功页浏览次数，因为这个数据是刷新一下就+1，可实际并没有付款第二次，应该用付款成功页访问次数才对。
查看了付款成功页的上一个页面时，确实有7次还是付款成功页，这也就验证了多出来的那部分，的确是刷新导致的。
校准了数据后，我们调整了漏斗数据，变成了如下样子：
漏斗的最后一个步骤（只差一步就能挣钱了的地方），从结账按钮点击次数到付款成功次数的比例仍旧不足64%，但已经没有更多的数据进行分析了，只能对这部分进行更详细的数据采集才可能有结论。
目前只有一个小推测，那就是快递宝石需要特殊的保护，因此每块售出的宝石除了运费外，还有固定百分比的保险费。
这费用是点击结账按钮后才能看到的！一下子多了这么多费用，搞不清楚状况的人很可能就直接放弃了，还很容易觉得这个网站很坑；即便能搞清楚状况，发现多出来的费用过高而放弃，都是很正常的。
把这些费用放在订单页面，可以避免搞不清状况而放弃的情况，但似乎减免这部分费用才是最有效的。但一切都需要有了数据，或者页面改动之后才知道。
完成数据采集并积累足够分析的数据量需要一些时间，期间，我出于娱乐写了一个关于这件事情的数学公式，如下：
当某订单的（总价格-总优惠-宝石总成本-平均订单推广成本）＞该订单的（总运费+总保费+总税金）时，该订单直接现金流大概率为正，是否可以减免运费和保费？
当某订单的（总价格-总优惠-宝石总成本-平均订单运营成本-平均订单推广成本）＞该订单的（总运费+总保费+总税金）时，该订单直接收益大概率为正，是否可以减免运费和保费？
呈现在产品里，订单总金额超过￥1,000，免除运费或保费之一；订单总金额超过￥2,000，免除运费和保费。
突然，背后一个响起声音：“你这思路不错！我们可以尝试这样运算一下，没准行。”
事后，对接人告诉我，这人是大老板，头一次见他夸人。我同事抓住机会，吹嘘起我们公司的能力有多么强大，且被定义为数学建模能力。我陪着笑，心想：“建模个锤子！我老娘卖宝石的时候，就是这么算的，还是在京东买东西的时候，学人家满39免运费的思路。”就是类似这样的宝石：
39免运费，是不是让我暴露年龄了！现在是99免运费哈……
这个插曲使得项目进度意外加速了，但那是后话，咱们说回数据分析。
漏斗的第一步，从访问次数到注册按钮点击次数只有0.7%，这个数据其实不严谨，但很有用！
首先，已经注册的人再次访问，会被记录访问次数，但他们不需要去点击注册按钮，就可以购买宝石。因此，0.7%的分母被高估了。
其次，采集的数据是注册按钮点击，不是注册成功，注册失败的人可能不止点了一次。因此，0.7%分子也被高估了。
再次，还是因为采集是注册按钮点击，不是注册成功，能成功做到加入购物车的人被高估了。
最后，到达网站就会被记录访问次数，但≠访客真的看了网站，可能啥都没干就走了。
我们一条一条看！先趁着热乎，看最后一条。
由于这个卖宝石的电商网站只采集了5个数据：页面浏览、注册按钮点击、购物车按钮点击、提交订单点击、结账按钮点击。因此，不知道访客是否啥都没干就走了，只能退而求其次，查看根据页面浏览数据计算出的跳出率（Bounce Rate）。
当时，使用的工具跳出率的计算方法是：跳出率=只记录了着陆页访问的访问次数/总访问次数，该数据为83.5%。这一方面是采集的数据太少，访客可能在着陆页（即访问的第一个页面）上做了很多事情，只是没被记录到，我们不知道；另一方面是最多只看了着陆页这一个页面的访问次数高达83.5%，这不太好说是好是坏。
进一步分析发现：50%左右的着陆页是详情页，且基本上都不是新访客。稍一打听，发现是销售人员微信给至少购买过一单的老主顾造成的。
当着陆页是详情页时，几乎全是老访客，跳出率超过99%。着陆页不是详情页那一半左右的情况，新老访客约4:1，新访客跳出率73%，老访客跳出率48%。
先收住，现在更深入的分析，反而会让我们看不清楚哪个问题才是更重要的。我们来看第2和第3两条，它们都与漏斗第二层的7,000次注册按钮点击相关。这7,000次注册按钮点击是6,000个访客完成的，其中新老访客约14:1。
第1条，漏斗第一层的1,000,000次访问中，有约3,200人是没有点击过注册按钮，却提交订单了，TA们累计访问了约100,000次，且这些人都不是新访客。这个网站，不注册成功是不可能看到提交订单按钮的，更不可能点击到它，被记录数据。因此，可以断定0.7%的分母1,000,000次访问，至少被高估了约100,000次，即10%左右。
结合补充的一部分无需赘述的数据，我们可以总结出如下的访客行为分析图：
左半侧起始于销售人员把详情页微信给至少购买过一单的老主顾，成单率与网站本身的用户体验关系不大；右半侧访客的自主访问行为，才是数据分析的重点，是网站用户体验提升真正能改善的部分。因此，我把右半侧做了更详细的拆解，如下图所示：
从上到下对比左右两侧，我们会依次发现，当着陆页不是详情页为大前提时：
①新访客的跳出率更高，达到了73%
②未跳出的新访客进行注册的比例也仅高于5%
③加入购物车后，提交订单的比例，新访客40%，老访客22.5%，新访客更高
④提交订单后，结账比例，新访客91.67%，老访客88.9%，也是新访客更高
⑤老访客需要进行注册的人，完成后续步骤的比例更高，整体上高于新访客
⑥老访客无需进行注册的人，完成后续步骤的比例最低，整体上低于新访客，甚至把老访客这些步骤的整体完成比例拉低到了新访客之下。
我们按顺序来，解析第一个情况。拆解新访客的着陆页后，我发现主要是2个页面+1类页面，两个分别是首页和注册页，一类是活动页，你猜哪个跳出率更高？
没错，就是注册页！它作为着陆页时，跳出率接近95%。
当首页和活动页作为着陆页的时候，跳出率都不到60%，都低于新访客的平均跳出率73%，拖后腿的只有一个。
换位思考一下，刚到一个不知名陌生新网站就让你注册，你会怎么选呢？
追本溯源，我马上查看了注册页作为着陆页的流量来源，发现这个客户没有给推广链接添加追踪标记。只能通过自动采集到的推广平台服务器域名，推断出是哪些推广平台。然后，我又查看了那略高于5%的未跳出流量，是否能带来订单。的确不是0，但太少了。
所以，没过过久，引流到注册页的推广都停了。并且，客户把添加推广标记当成了第一要务，因为TA们实在受不了，不能确定某个推广到底有多少订单。
第二个情况，我们要先看如何能到达这个卖宝石网站的注册页。
主要是4种方式：
上面提到，注册按钮点击次数7,000，点击人数6,000。注册页的浏览量高达20万！注册页访问次数高达19万！注册页访客人数17万！注册率（注册按钮点击人数/注册页访客人数）还不到3.5%！我没觉得那个注册流程有这么差啊？然后，我发现了问题，没有提出直接推广注册页的数据，那可是跳出率接近95%的情况啊。
最后，我对比了一下，其它3种到达注册页的方式，注册率有什么不同。
第二种情况，从购物车跳转过来的，注册率85%出头；剩余那接近15%，下一个页面基本都是登录页他们被记录为新访客大概率是因为换了电脑、换了浏览器、清了浏览器缓存或太久没访问等缘故，被系统记录为了新访客，其实是早就注册成功过得了。
通过导航点击到注册页的，注册率接近75%。
从活动页按钮过来的，注册率最高超过90%，感觉像是因为注册领券而薅羊毛的，因为这样注册后，产生的订单并不多。
并没有更细致的数据支持，注册相关的分析了，只能设计好注册流程的埋点方案，把数据采集、积累好，再说。比注册更复杂的，购物流程中的东西，更是如此，也只能先采集、积累数据，再说了！
我的第一个数据分析项目，让我明白了一个很重要的道理。即使数据不全、不准、不是100%严谨，也能让你分析出来很多东西，并有效指导接下来的工作，甚至能让你立刻止损。
本文由 @中士哥 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。