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