过去的六七年我一直在企业服务领域创业，使用过不少分析工具：GA、M、H等等，功能很强大，但是总感觉少了点什么
网站运营关键指标
我们看到了PVUV这样的概览性指标，但是它们没法指导我们做的更好网站运营指标
在通过这些粗糙的数据得到用户做了什么后，还要看到他们是怎么做的，明白他们为什么做
我们需要实时、全量的用户行为数据，通过对用户行为整体流程的分析，找到转化的关键节点以及用户流失的核心原因，以此帮助我们对症下药，找到可执行的指标，落实为优化行动
今天，我想分享的就是我们在这方面的一些探索与解决方案
一.用户行为分析的巨大需求 纯从数据组成的角度来说，一个完善的闭环数据源主要是分成三大块：第一块是用户行为数据，第二块是服务端日志数据，第三块是交易T数据
其中，除了交易数据会经常被存储在离线数据库中，通过ETL来获取分析以外，行为数据和日志数据很多时候都是近似的，完备的用户行为数据基本能覆盖绝大多数的服务端日志数据，同时里面包含着很多日志数据里面所缺乏的信息
从技术发展角度来说，最近几年发展最快的可以说是前端，每个月都会有很多新的东西出现，整体趋势是往单页应用发展，追求用户体验
同时，还有移动端应用，也产生着大量的行为数据，这些都不会跟服务端有过多交互
所以，从应用提供商来说，我们需要知道屏幕前的人是怎么使用我们的产品的，洞悉用户行为背后的价值
GIO目前有近千家客户在使用，我总结了一下客户经常问我们的分析需求，大致可以分成三个场景： 第一个场景是：我做了一次活动，我写了一篇文章，我想知道到底效果如何，有没有给我带来足够的流量，也就是市场营销效果衡量
我们有些客户，每年有上百万的市场预算在SEM上，但是却完全不知道这些钱花出去到底带来了多少回报
第二个场景是用户激活流程是否合理，辛辛苦苦导入了流量，这些流量有没有转化为用户，注册流里面每一步转化了多少，流逝了多少，没有转化的去了哪里
再在这个基础上，我们应该怎么优化，优化后的效果是怎样的，这周的转化率比起上周是否有进步，差别是怎么引起的等等
第三个场景是这些注册的用户，有没有留下来成为一个忠诚用户甚至付费用户
留下来的用户，是因为什么留下来的
是否存在一个魔法数字，可以去极大的提 高用户留存，比如：LI发现在第一周增加个社交关系的用户留存度很高；F发现在第一周增加个好友的用户留存度很高；T发现在第一周有个的用户留存度很高；D发现在第一周安装两个以上操作系统的用户留存度很高
这些都是在留存分析中发现的魔法数字
二.复杂而易错的传统分析方法 归根结底，所有的分析最终都是为了商业服务，而商业是为人服务的
所以，用户行为分析就是我们需要建立一套基于用户行为的分析体系，在了解用户“谁”做了“什么”，“怎么”做的之外，进而明白是“为什么”做，对症下药，转化成为优化行动
分析是一个长时间优化的过程，需要我们持续监控数据的变化
而数据指标除了行为数据指标外还有一类，我们称之为虚荣指标，比如PV、UV之类流量概览性数据，这些指标看到了也就看到了，没法指导我们做的更好
用户行为数据指标则是另外一类，比如我们上面介绍的用户获取、用户激活、用户留存之类，了解这些行为后面都会对应到一个优化流程，所以也叫做AM，可执行指标，这也是用户行为数据的魅力
那么接下来，我们要开始跟踪用户行为了，一般可以分成以下七个步骤： .确定分析场景或目标确定一个场景，或者一个目标
比如，我们发现很多用户访问了注册页面，但是最终完成注册的很少，那么我们的目标就是提高注册转化率，了解为什么用户没有完成注册，是哪一个步骤挡住用户了
.思考需要了解哪些数据思考哪些数据我们需要了解，帮助我们实现这个目标
比如对于之前的目标，我们需要拆解从进入注册页面到完成注册的每一个步骤的数据，每一次输入的数据，同时，完成或者未成为这些步骤的人的特征数据
.确定谁来负责收集数据
谁负责收集这些数据，一般是我们工程师出马
.什么时候评估和分析
收集上来的数据如何分析，什么时候来评估采集到的数据
.如何给出优化解决方案
发现问题后，怎么来出解决方案
比如，是否在设计上改进，或者是否是工程上的
.谁负责实现解决方案
确定方案的实施责任人
.如何评估解决方案的效果
下一轮数据采集和分析，回到第一步继续迭代
知易行难，这整个流程里，第步到第步是关键
目前传统的服务商比如GA、M、友盟所采用的方式我称之为C模式
通过在客户端埋下确定的点，采集相关数据到云端，最终在云端做呈现
比如图中这个示例，相信很多人应该都有写过类似的代码
C模式对于非探索式分析来说，是一个非常行之有效的方法
然而，同时对参与整个流程的人也提出了非常高的要求： 缺点：依赖经验导向C模式非常依赖人的经验和直觉
不是说经验和直觉不好，而是有时我们自己也不知道到底什么是好的，经验反而会成为一个先入为主的负担，我们需要用数据来测试来证明
缺点：沟通成本高另外，一个有效的分析结果，依赖于数据的完整性和完备性
跟不少企业沟通后，不少的吐槽都是“连日志格式都统一不了”，更别提后续分析了
这不是具体人的问题，更多是协作沟通的问题
参与人越多，产品经理、分析师、工程师、运营等等，每个人的专业领域又各不相同，出现误解太正常了
曾经跟我们的CEOS交流过，他在LI带领数据分析部门的时候，LI专门组建了一个多达人的埋点团队，每天开会，就是为了统一埋点的格式和位置，经常一开就是几个星期
缺点：大量时间数据清洗和数据分析代码侵入另外，由于需求的多变性，埋点分成多次加入，缺乏统筹设计和统一管理，结果自然是无比肮脏
所以我们数据工程师还有个很大的工作是数据清洗，手动跑ETL出报表
根据统计，绝大多数分析工作，百分之七十到八十的时间是在做数据清洗和手动ETL，只有百分之二十左右在做真正有业务价值的事情
另外一方面，作为一个有洁癖的工程师，最恨的就是大量的分析代码侵入了我的业务代码，删不敢删，改不敢改，日积月累，最终代码库整个就混乱了
缺点：数据漏采错踩以上都还是好的，最最让人抓狂的是，上线了，发现数据采集错了或者漏了，修正后，又得重新跑一遍流程，一个星期两个星期有过去了
这也是为啥，数据分析工作是如此耗时一般以月计的原因，非常低效
三.无需埋点的数据分析原理 在经历了无数个痛苦的夜晚以后，我们决定要换个思路思考了，希望能最大限度的降低人为的错误，我们称之为R模式
区别于C模式，R模式是用机器来替代人的经验，自动地采集用户在网站或者应用里的全量行为数据
因为自动化，我们从分析流程的源头开始就控制了数据的格式
所有数据，从业务角度出发，划分为种维度：W，行为背后的人，具有哪些属性；W，什么时候触发的这个行为；W，城市地区浏览器甚至GPS等；W，也就是内容；H，是怎样完成的
基于对信息的解构，保证了数据从源头就是干净的，再在此基础上面，我们完全可以把ETL自动化，需要什么数据可以随时回溯
回到之前流程的第步到第步，我们已经把参与人从多方减少到基本就一方了，无论是产品经理、分析师还是运营人员，都可以使用可视化工具来查询和分析数据，真正做到所见即所得
不仅是PC，还支持OS、A和H，可以进行跨屏的用户分析
作为一家用户行为分析工具提供商，GIO要做的并不只是用于内部，还需要适应外部成千上万的网站和应用，所以在实现过程中我们做了很多探索： 自动用户行为采集 目前我们所接触的GUI程序，无论是WA、OSA还是AA，都是基于两个原则，树形结构和事件驱动模型
无论是W上的DOM结点结构，还是A上的UI控件结构，都是构建好的一颗完整的树形结构渲染在页面或者屏幕上
所以通过对树结构的监控和检测，我们就可以非常方便地知道哪些结点发生了变化，何时发生了变化，发生了什么变化
同时，当用户做了某个操作，比如鼠标点击、屏幕触控，都会触发一个事件，绑定了该事件的回调函数就会被触发开始执行
基于此两点认识，在SDK里面如何实现无埋点就比较清楚了
只要能在结点变化或者事件发生的时候触发我们定义的函数，那么我就知道事件发生的多重信息
数据可视化 如何把采集到的数据和业务目标匹配在一起
我们的解决方案就是我们的可视化工具
刚才已经提到任何一个原子数据，都被拆解成了种不同分类的维度
所以，当我们在可视化工具里面做匹配时，也就是对于不同维度信息的匹配
比如一个链接的点击，会匹配到内容或者跳转地址也就是W，点击行为也就是H
还有其在页面的定位信息，比如在树形结构中的层次位置，是否带一些、或者，都是用来做数据匹配的信息
我们开发了一套智能匹配系统，通过对用户真实行为的学习，建立了一套规则引擎，用于元素匹配
也正因为采集到的是全量数据，整个匹配系统有如基因进化一般，既有对过去历史的记忆，也有顺应新结构的演进变化
BI商业分析 我们在系统设计过程中，整个DP过程中，数据进过处理后，会根据优先级不同，首先通过SS实时的处理已定义数据，然后每过一段时间对匹配到的数据做离线预聚合，多维分析非常灵活
用户行为数据采集的目的是通过了解用户过去做的行为，用来预测未来发生的事情，无需埋点，随时回溯数据，让产品经理一个人就可以搞定用户行为分析的全部流程
GIO希望能提供一个简单、迅速和规模化的数据分析产品，能极大地简化分析流程，提交效率，直达业务
而这一切的基础，就是我们从第一天开始就一直在研发的无埋点智能全量数据采集，基于此优化产品体验，实现精细化运营，用数据驱动用户和营收的增长
