在第一个步骤中，我们可以运用多种方式收集用户数据，比如做用户调研，比如收集商品购买订单等等，但在大数据时代，我们聊点高级的，即埋点（我这里说的埋点是概念上的埋点哈，并不是埋点这种技术）。埋点是说，在对商品推荐有价值的行为节点，建立数据的采集和记录机制，在相应的行为发生时进行事件汇报和记录，这样可以记录每一个有价值的行为，完全不需要做什么抽样调查。在这里，我们把用户与购物相关的有价值动作用一个对象”行为“记录下来，每一条行为记录当中，都包含有用户id，行为发生时间，行为类型，前向或者后向节点，行为具体内容等，具体可以这样设计：
- 唯一记录id
- 用户（名称/id等）
- 发生时间
- 行为类型（比如点击/加购物车/收藏/购买/分享等）
- 事件内容（比如手机-小米-小米Mix尊享版）
- 前向节点（比如分享页/活动页）
这里复习一下，其实在设计用户数据结构时，用了面向对象的设计方法，并不是记录每次用户的下单过程，而是将用户的每个关键动作都抽象为”行为“这一相对普适的结构，这样不仅具备良好的结构性能，在后续数据分析时也会有更高的自由度和规范性。
由于有了更加高性能和更加稳定的动作采集、汇报、记录机制和技术，以及高性能的规模化数据存储结构，使得像上述对数据的实时规模化记录成为可能。也正是有这些技术，推动了大数据的落地。所谓大数据，并不是指数据多，而是指数据全，我们不在像以前那样，做数据抽样调查，纠结于抽样方法和样本数量，因为我们现在获取的是全部所有数据，基于全量做研究，得出的结论将更为可靠，且节省了抽样成本，这才是大数据的关键。
既然提到这个关键，多说两点。
第一是注意幸存者偏差，在数据收集机制的设计时，要考虑收集数据的片面性对结果的影响。这里比较典型的例子是关于统计从战斗中飞回来的战斗机弹孔位置来决定如何做改良的例子。专家的错误在于，他即使查看了所有幸存飞行员所驾驶飞机的数据，得出的结论也是基于成功飞回来的样本，而忽略了那些在战场已经坠毁的战斗机数据。这些数据反而才是最关键的，回来的战斗机，虽然机身那些位置有弹孔，但反而他们回来了，正说明这些位置中弹不会导致致命。
二是注意收集正确的数据，举个例子，你期望每天早上，在合适的时间，通过你的app给用户推荐一条早安帖，你机智地想到，周末用户可能会起得晚一些，我周末应该晚点再推消息，避免打扰到用户。你用算法构建了合理推送时间与周内/周末的关系，并依此完成推送时间决策。在周一到周五，8点推，周六和周日，10点推。但有一次，劳动节放假了，那天是周一，你8点推送了一条消息，把用户吵醒了。熟睡中被手机APP推送消息吵醒，想想这是多么恐怖的一件事情，用户一怒之下，卸载了你的APP，血崩。你看，用户起床时间的真正影响因素是节假日而非周一到周日。以人类的聪明才智，这个点很容易想到，但一是体现在产品设计中并不容易（我印象中IOS的闹钟都只能设置为周一到周五生效或者周末生效，用小米手机发现MIUI有优化，可以自动联网同步工作日和节假日数据，从而设置仅工作日/仅节假日闹钟，这也是被MIUI圈粉的一个小细节），二是我们今天聊的是DMP，在算法模型做处理时，如果你在前端并没有设计要收集节假日和工作日数据，而只收集了星期数据，那机器再怎么学习，算法再怎么优化，也无法得出效的结论。这里的本质错误是没有搞清楚真正影响因素。
当然我们本来就是做数据研究，可能在一开始就是不明白，用户起床时间到底与什么因素有关，为了尽量在后续能够做全面有效的分析，在不了解的情况下，数据采集应该尽量做到维度的全面覆盖。这时又会有另一个问题，现在还没发达到我们可以记录用户的每个行为的程度，就算有，在数据处理和分析阶段也会需要无限的计算资源才能够满足需求，怎么搞？
合理的解法是，在做系统设计之前，基于历史经验和人工模拟的实验，来进行影响因素的排除过滤和筛选，比如，我们大概率判断，国内用户的起床时间和当天国外的天气没关系，反而可能和今天堵不堵车有关系，如果不知道，也可以简单设计实验来做基本验证。基于这些经验和预实验，能够极度简化模型参数，既不浪费系统性能，同时也保证了起始数据收集维度的正确性。
所以你看，我们该相信经验，还是数据？我说我们该相信数据，但经验和数据不矛盾，相反，经验给大数据/人工智能提供了一条快速收敛的捷径，这些宝贵的经验让模型在一开始能有更好的初始学习条件。
所以你再看，产品经理的价值体现在哪里？更多情况下，可能并不是参与DMP系统技术架构的设计，那些交给技术同学就可以了，产品经理在这里做了什么事，他基于经验和前期的模拟实验，更好地设计了DMP系统输入，指导了在数据收集阶段该收集哪些数据，这个价值远大于做具体系统架构设计，这才是真正的”设计性“体现，这才是真正的architect！
可以关注我的公众号获取推送。
image
网友评论