ABF平台设计（四）：体验黑科技-结构化的体验数据平台

你是否遇到过下面的场景？

场景1：
新接收了一个项目，想了解一下当前的用户使用习惯和反馈，却没有一个全面、权威的数据支撑来帮助你深入了解，只能从用户口中了解到一些零散的信息；
场景2:
在讨论产品方案时，产品、开发在一起各抒己见，每个人都感觉自己代表用户，到底谁代表用户？
场景3:
系统经过多年的迭代，各种热门功能和僵尸功能混在一起，变得十分臃肿，你想精简一下系统功能和代码，却因为不了解哪些功能还在使用、哪些已经废弃，而不敢“轻举妄动”；
场景4:
用户报了一个线上的BUG，自己操作复现不出来，想知道用户当时的操作路径；

为什么我们了解用户行为数据会那么麻烦？

上述场景都是由于我们对用户的操作行为了解不全面导致的。虽然，我们对自己研发的系统的用户行为会有或多或少的了解，这些了解可能来自业务数据的多少，可能来自于与用户的交流、用户的反馈，也可能来自于一些埋点数据平台。但是，这些了解都是碎片化的、零散的、不够全面的。我们只能基于这些在自己的心中构建出一个使用次数、操作行为的全景图，但这个全景图是模糊的，没有具体数据支撑的，是支离破碎的。
目前了解用户行为，最有效的方式就是通过埋点数据平台，如AEM、九色鹿等。这些埋点数据平台的产品逻辑都有以下特点：
**● 工具的集合。**提供了大量工具，但是工具都是独立的，工具之间的分析数据不能关联着看。
**● 产品是被动的，用户需主动。**只有当用户主动发现一个问题，去查询，它能够提供数据支撑。如果从来没有想到过那个问题，那它就不会被注意到。
**● 特殊逻辑依赖于上报时代码处理和查询时拼复杂查询条件。**对于大部分系统，都会有特殊的逻辑。如我们把页面路径满足/:showID/:videoID规则的看做是一个页面，需要统计这个页面的PV，就需要在上报阶段通过代码处理。这就增加了用户使用的负担。如下图所示，用户会花费比较大的精力在上报阶段和查询数据阶段。