共计 2771 个字符，预计需要花费 7 分钟才能阅读完成。
你是否遇到过上面的场景？
场景 1：
新接管了一个我的项目，想理解一下以后的用户应用习惯和反馈，却没有一个全面、权威的数据撑持来帮忙你深刻理解，只能从用户口中理解到一些零散的信息；
场景 2:
在探讨产品计划时，产品、开发在一起畅所欲言，每个人都感觉本人代表用户，到底谁代表用户？
场景 3:
零碎通过多年的迭代，各种热门性能和僵尸性能混在一起，变得非常臃肿，你想精简一下零碎性能和代码，却因为不理解哪些性能还在应用、哪些曾经废除，而不敢“四平八稳”；
场景 4:
用户报了一个线上的 BUG，本人操作复现不进去，想晓得用户过后的操作门路；
为什么咱们理解用户行为数据会那么麻烦？
上述场景都是因为咱们对用户的操作行为理解不全面导致的。尽管，咱们对本人研发的零碎的用户行为会有或多或少的理解，这些理解可能来自业务数据的多少，可能来自于与用户的交换、用户的反馈，也可能来自于一些埋点数据平台。然而，这些理解都是碎片化的、零散的、不够全面的。咱们只能基于这些在本人的心中构建出一个应用次数、操作行为的全景图，但这个全景图是含糊的，没有具体数据撑持的，是四分五裂的。
目前理解用户行为，最无效的形式就是通过埋点数据平台，如 AEM、九色鹿等。这些埋点数据平台的产品逻辑都有以下特点：
● 工具的汇合。提供了大量工具，然而工具都是独立的，工具之间的剖析数据不能关联着看。
● 产品是被动的，用户需被动。只有当用户被动发现一个问题，去查问，它可能提供数据撑持。如果素来没有想到过那个问题，那它就不会被留神到。
● 非凡逻辑依赖于上报时代码解决和查问时拼简单查问条件。对于大部分零碎，都会有非凡的逻辑。如咱们把页面门路满足 /:showID/:videoID 规定的看做是一个页面，须要统计这个页面的 PV，就须要在上报阶段通过代码解决。这就减少了用户应用的累赘。如下图所示，用户会破费比拟大的精力在上报阶段和查问数据阶段。
ABF 体验核心的产品思路和特点
一、结构化
下面提到产研同学会在心中构建一个性能应用次数、操作行为的全景图，ABF 体验核心的指标就是将这个全景图具像化的展现进去，能既全面的看整体数据，也能逐渐深刻看到细节，让含糊的感觉变成实在的数字，不再有“盲区”。想要实现既全面又具体看数据，既能上卷又能下钻看数据，就必须以某种“构造”作为根底。那么这个“构造”是什么呢？
既然咱们要看的是一个软件产品的应用数据，那这个构造就是软件产品的组成单位：性能。咱们能够把软件产品的性能档次树定义进去，将埋点数据与性能树做联结剖析，能够实现既全面又具体看数据的指标。其余的体验平台，仅仅是各种工具的汇合，这里将各个工具产生的剖析数据通过性能黏合在了一起，它们不再是人心涣散，这样就具备了结构化。
“性能”在这里是一个比拟宽泛的概念，分为上面几种：
○ 基本功能：一次表单的填写、一次视频的上传；○ 分类性能：对具体性能进行的分组。如上图的项目管理，它蕴含增、删、改、查能够看做 4 个基本功能。分类性能能够有有限档次。须要留神的是，页面是分类性能。○ 我的项目根性能：个别对应一个工程项目。○ 我的项目分类性能：对我的项目进行了分类。二、被动
传统的埋点数据都是等用户被动查问，ABF 体验核心尝试一种“推”的产品状态，更被动的将体验数据交融在我的项目零碎中，以推的形式让产研更不便的看到体验数据。
三、应用简略
针对在埋点上报阶段和数据查问阶段都须要付出很多精力，这里将复杂度进行了转移。
如上图所示，将各我的项目中非凡的逻辑转移到一个线上的性能定义平台和数据计算阶段，埋点阶段用户无需再进行额定的编码，数据查问阶段无需在搜索枯肠拼简单的查问条件。
ABF 体验核心的外围产品能力
一、结构化数据查问
能够从纵向和横向进行用户行为的探查。
纵向探查
纵向是在不同档次理解、比照用户行为。如下图，能够在各个系统层面，比照各个系统的应用状况。
逐渐往下钻，能够看到更具体的各个性能的应用状况。
横向探查
横向是在从不同维度去剖析数据。能够从用户、时间跨度、操作链路、页面、事件等不同维度在不同的性能档次探查用户行为。如上面的一些需要：
● 查看某一具体用户在不同零碎的应用散布状况。
● 查看某一性能的根本指标趋势。
● 查看某一性能的耗时最多的用户。
● 查看某一性能理论罕用的操作门路。
二、简单规定的性能定义和辨认
性能模型
下面从业务的不同档次对性能进行了分类，从数据处理技术角度，性能分为基本功能和汇总性能。
● 基本功能：同下面的基本功能。指的是为实现某单项工作，在页面内的一系列操作，个别具备链路个性。如一次表单的填写：点击新增 -> 填写各表单项 -> 保留，一次查问操作：输出各查问条件 -> 点查问按钮。
● 汇总性能：除基本功能的下层性能都是汇总性能，为了从不同档次看用户行为数据。
基本功能辨认
用户的操作是任意的，是纷繁复杂的，大部分状况没有齐全的固定程序。如一般的查问性能，图中 4 种状况，咱们都认为是一次查问性能的实现。
这须要有弱小的用户行为辨认能力，将纷繁复杂的用户操作与基本功能进行匹配。
ABF 体验核心提供了弱小的规定语法来对基本功能进行形容。
程序
例：1->2。
反复
例：1->2?->3。? 示意 1、3 两头可有 2、也可无 2。其余量词 +：1 次以上、*: 0 次或屡次、{n}：那次
分支
例：1->(2|3)->4。两头两个节点能够是 2 或 3
组合
例：1->2|3->4{2,}->5|6->(7|8)?->9?
汇总性能
汇总性能是通过其子的数据自下而上聚合而来。
三、跨零碎链路定义和辨认
在经营中后盾零碎中，很多工作依赖于多个零碎的性能来实现。体验核心提供了跨零碎性能的定义和辨认，定义规定和基本功能基本一致。
四、一键生成性能构造
对于比拟宏大的零碎，性能的录入是一件比拟费时的事件。这里提供了将我的项目代码里的路由配置一键同步为性能定义平台的性能。
五、嵌入到我的项目零碎的挂件
如“被动”章节提到的，体验核心提供了能够嵌入到零碎的挂件。与零碎交融，更不便看体验数据，能“推”动产研对体验的关注。
之后性能平台和体验数据中心的性能都将逐渐迁徙到这个挂件中，与零碎深度交融，不便操作。
页面概览
挂件会展现页面的拜访次数、人数、人均拜访次数，可切换日期、工夫模式（近 1、7、30 天），能够查看指定用户。
点击热点
切换 PV、UV、人均，能够查看页面元素的点击状况，可切换日期、工夫模式（近 1、7、30 天），能够查看指定用户。
下钻探查
点击页面拜访数据或者事件数据，能够下钻探查。
● 看 UV 的详情。
● 看事件的详情。
● 看用户的一整天的拜访轨迹。
用户轨迹
可查看指定用户的操作轨迹。
总结
不同与传统的体验数据平台，ABF 体验核心提供了结构化的体验数据探查能力，让产研能既整体又部分的理解用户在零碎中的行为，并通过更被动的数据推送策略，让产研更关注体验数据，为晋升用户体验提供数据撑持。
体验黑科技，让你比用户更理解用户。
