标签：style http color os ar 数据 问题 sp on
相信大家做产品到一定经验之后，很多时候都会依据自己的经验去设计产品，可能经验已经被过往的产品验证过了，所以在设计新产品的时候没有多加考虑。进入大数据时代后，我发现这一经验法则不再适用，很多场景下，过往的经验只会让产品变差，可以说这是因为没有与时俱进，但从务实的角度看，却是没有在根本上从用户角度出发。问大家一个问题，当你的经验与产品的数据反馈相违背的时候，你会选择相信哪个?
现在产品的发展思路中，数据基础的建设越来越受重视，这和大数据的概念和数据营销的方法离不开，这几年对数据的应用使越来越多的人开始相信“数据会说话”，拍脑袋的决策减少了很多。对于产品经理来说，原先就要做很多分析：市场分析、竞品分析、需求分析等，现在只是多加了一个“数据分析”，这些“分析”的手段虽然不一样，但目的都是相同的，因此接收起来应该没难度，只不过被包了一层“大数据”的外衣，不知道是什么东西了。概念永远只是概念，落到实处的做法才是我们真正需要关心的。就像“云计算”概念，各种“云”，弄的很玄乎，实际上是虚拟机、网络硬盘等技术的变种。
有了数据之后，如何应用又是一个问题。让数据躺在那里睡大觉是发挥不了效用的，要结合工作实际需要去针对性的分析，在《电商平台商家改价行为的数据分析实践》中我也提到，一定要带着目的去分析数据。分析的结果可能与你原来的经验相符，也有可能相反，就我自己目前遇到的几个场景，来说一下数据的威力在哪，它是如何改变过往产品经验的。
场景一：合并支付的功能
做过电子商务的朋友应该都对这个功能有了解，就是未支付的订单可以合在一起一笔支付掉，支付成功后，合并的每个订单的支付状态都会更新。最早见于淘宝，因其支付宝可以支持这样的业务功能，之后别的支付方式也逐渐开始支持这个功能，合并支付在电商网站上就逐渐都有了。合并支付有一个数量上的限制，就是一次可以合并支付多少个订单。拍脑袋的想肯定是越多越好，最好是无限制，但这个功能有一定的技术局限性，无法支持很多订单同时支付。
这个场景所遇到的就是这个问题，产品端设计时把数量阀值设为20单，从过往经验来看，用户分别去下20个订单，然后再去合并支付的可能性非常小，从用户的购物习惯来分析，要买很多东西的话尽量会下在一个订单内，就像去超市购物会一车推出来一起结算，这个从自营电商的角度看，基本上就是这样的。从平台电商的角度看，每个商家的发货、物流体系不同，一次下单可能会生成多个店铺的订单，但数量能超过20个店铺的比例应该也非常小。但就是这个阀值出了问题。
某次促销，收到很多用户反馈无法完成支付，提示订单数量不能超过20.说实话当时是很惊奇的，拉了一下数据发现，促销期间支付请求订单数超过20的有5000多次，涉及到15000多个订单，排除掉重复请求的因素，每次请求的平均订单数是30单，大大超过了我们所设定的阀值。针对这个问题，我们拉了一下平常的数据，发现支付请求订单数超过20的平均每天有600多次，假设以客单价100元来计算，每天大概影响了600*20*100=120万的销售额，看到这个数据真是汗滴滴啊，一个阀值影响了这么多钱，可能平时反馈的不多，被忽略掉了，促销的时候集中爆发了。
当然这里面肯定有原因存在，事后的原因分析这里不做详细介绍，但产品设计时没有设计好是有责任的，解决方案就两种：一种是调高这个阀值;一种是在下单支付流程上就限制住，不让用户一口气下20单以上或同时选择20单以上进行支付，具体采用哪个方案，取决于技术的支持和其他因素的综合考虑。
场景二：支付成功后取消订单
取消订单的功能相信大家都了解，在网上买过东西的人都知道，在对方发货之前是可以取消订单的。对于未支付的订单取消，因没有产生任何交易，是没有问题的，但是已经支付的订单取消，就需要考虑取消的时机了。首先发货后肯定不能取消，货物在途不好追偿;其次如果是定制类的商品，支付成功后可能商家已经开始定货了，要取消的话就需要商家确认。这里要分享的场景就是后面一种，需要商家同意才能取消的订单。
从产品角度来看，取消订单是一个很好的收集反馈的入口，可以设置有针对性的原因让用户去选择，从而收集回来改进产品。我们根据产品的诉求和一些目的，设置了7个初始化的原因，而一般在设置原因的时候，因为没法囊括所有的情况，都会设置一个“其他”的选项。而最后收集回来的数据发现7成左右都集中这个选项上，如果根据经验去看这份数据，就失去了意义。但这是很奇怪的一个现象，难道真是我们所设置的初始化原因没有戳到用户取消订单的痛点么?一个原因没有戳中也就算了，总共有7个原因，不可能都没有命中的。
通过数据分析我们发现，用户第一次提交取消订单请求的时候，“其他”选项的占比才2成都不到，而商家处理结束后，“其他”选项的占比却上升到7成，剩余的3成大部分还是因为超时未处理而取消掉的。这说明了一个问题，那就是用户修改过取消订单的原因，从数据日志记录上看也印证了有修改。也就是说我们原先设置的原因基本上还是命中了的，如果就采用最终收集的占比数据去看这个过程，那就没有任何意义了。
至于为什么会导致用户去修改原因，这里不做详细说明。最终的结论是，我们只能参考日志数据中用户第一次提交的原因数据。
通过这两个场景的举例，可以看到有些时候依据经验办事已经不靠谱了，需要透过现象，去看背后数据反馈出来的本质，产品经理要站在更高的角度去看待产品设计，脱离原来经验的束缚。但这并不是说数据是万能的，我只赞同数据可以提供很好的参考，提供决策的依据，但数据不是全部，很多时候还是要靠产品经理去判断产品的发展趋势，过往经验也能提供很好的参考。只不过经验从“遵循”变成了“参考”，数据也是“参考”，这样能让产品经理更客观的去做决策。
标签：style http color os ar 数据 问题 sp on
原文地址：http://blog.csdn.net/asqi1/article/details/39289585
