名词解释
- 用户行为：用户在使用产品时每一次决策都是该用户的一次行为。
- 用户行为轨迹：将该用户的所有行为根据时间关系串联起来就是用户完整的行为轨迹
- 用户行为习惯：统计到一定用户数量的行为轨迹之后进行统计归类，就可以得到该产品的用户群体的行为习惯。
- 最优目标路径：达到产品目的的最短路径。比如是一个电商网站，我们希望用户以最短的路径完成下单，这个称之为最优目标路径(没听过？没错就是我编的)。
现有的统计短板
就我司来讲，目前对于用户行为方面的统计只能统计到点击次数。但是用户行为的分析，仅仅从点击次数来看是远远不够的。也是不足以支持产品及交互同学对于产品的解读。
- 点击量：点击次数只能反映热度。并且这个热度还不能真正反映是不是普遍用户的操作。数据太过单一。维度也太单一。
- 热力图：通过图像的方式更容易直接的看出页面的点击分布。这个比统计就更进一步了。已经可以看出。整个页面受点击的一个基本情况了。
- 百度Hunter：录制一部分用户的行为，点击记录用户的行为，还原用户行为操作。将鼠标移动和点击的位置点集记录下来，然后通过截图，真实反映当时用户的行为，数据基础太大，目前还不知道内部核心算法是怎么做赛选的
用户行为分析点
- 用户流向分析：用户从哪个节点进来，是从哪个节点跳出的，跳出率如何？是否完成产品期望目的
- 关键节点分析：产品的关键节点的行为走向，以及关键节点点击次数，点击关键节点的决策时间
- 用户行为习惯分析：了解产品的用户行为习惯，改进界面设计及用户交互，改进产品流程贴近用户习惯
- 多维度数据分析：从轨迹所在按钮，所在页面等维度去分析，从行为习惯及分布人群分析，从决策时间去分析，多维度得到立体答案。
用户行为如何改进产品
- 了解用户习惯：了解产品的用户行为习惯，改进界面设计及用户交互，改进产品流程贴近用户习惯
- 提供丰富数据：提供产品所想要的有关用户行为的数据，并能针对特殊需求开发相应统计图表
- 辅助产品改进：能够为产品经理在改进产品时提供依据，同时能验证产品改进后的设想
我对用户行为系统的期望
不仅能满足上面描述的基本需求，还能够提供个性化的定制数据统计，基本服务能满足大部分用户，但是海量的数据量还是需要图标更为直观的表现，但由于各个产品侧重点不同，不能普遍的提供一个统计给所有的产品，所以期望能在统计时给出差异化的统计图标，以便能更为细致的观测自己产品用户行为的统计情况。
也就是说我对我的用户行为系统的设计分为两部分，基础部分能提供通用数据，覆盖绝大部分的产品，基础数据能够达到上面提出的要求，但基础数据可能不是非常直观，且数据量巨大，所以提供个性化的统计图表辅助用户行为系统的直观展示，个性化的统计图表因为是定制，所以需要遇到需求实时开发。
用户行为特点
就目前收集到的数据来看，用户行为具有以下特点：
- 差异化性：用户与用户之间的行为差异
- 流动性：同一用户的行为操作不定
- 传播性：用户之间的相互影响
以上的这些特点让用户行为的数据神离貌合，为什么说神离在前？因为数据展示时的差异性太大了，
用户行为系统现状
- 用户差异巨大导致数据的多样性，数据的多样性使得很难展示出用户行为的习惯。
- 表现形式糟糕，由于产品基础全无，导致拿到差异性大的数据时没有办法合理展示数据。
- 目前统计的仅仅是行为差距，并没有真正的表现一个用户，或者一类用户的行为习惯。
- 前方迷雾重重，我已不知所措。
系统优化
前端
这个系统中，前端所成单的主要功能是展示，所以业务逻辑相对较轻，优化主要是在展示方面。之前的主要性能问题在于渲染，问题出在需要渲染的数据量实在太大。原来各个部分之间的耦合很高，难于拆分。功能之间不够独立。由于前期架子搭的太过潦草。导致后期重复代码非常多。
- 结构调整在于拆分出三个文件夹
common（公共模块，如header）、page（以页面维度划分模块）、utils（工具函数）。- 拆分出
header，并构建出页面的基本数据，日期及页面ID。- 拆分出
tab，控制页面之间的跳转。- 拆分统计页面。分为基础数据及个性化定制图标。业务线不同，关注点不同。可以迅速定制扩展不同业务线所关心的表。
- 拆分出
table这个真的是不容易，以为表单的需求实在怪异，所以这次的table组件没有做到通用性。但是对于目前的业务是够了。- 增加
table的功能。具有简单的赛选功能。作用突出。
这次前端的重构，并没有将前端架构的非常高端。因为业务实在简单。加上业务的不稳定行。所以目前并不应该花太多时间在重构上。这次的重构仅仅是梳理结构，让结构更加有条理。并有一定的茁壮性。
后端
在学习了一段时间的node之后，对node有了一个整体的认识，所以这次重构主要是将后端的结构化。并且按照真正后端的MVC模式进行架构。加上自动化测试，可以加强对整体性能的提升。目前展示端性能已无瓶颈。结构相当清晰。加上日志记录，让整个系统有一定的稳定性。但是由于对node的认知还不够深刻。还需要持续的学习改进。下面是文件目录结构。
.
├── bin // 可执行脚本，启动文件
├── node_modules // node 模块存放文件夹
├── common // 公共方法文件夹
├── coverage // 自动化测试覆盖
├── getData // 获取数据方法
├── logs // 日志记录文件夹
├── middlewares // 中间件存放文件夹
├── routes // 路由分发。controller
├── models // 数据层，与数据库交互的 DAO 层
├── views // 视图层，通过 controller 获取数据后渲染
├── service // service 层，介于controlle 与 DAO 层之间，主要用于处理数据
├── test // 测试存放文件夹
├── app.js // 工作进程
├── Makefile // Makefile 文件，目前是用于跑自动化测试
├── build.sh // 发布文件
├── healthcheck.html // 发布用于对机器进行监控，判断是否能对外提供服务
├── package.json // 包描述文件，项目依赖配置等
├── pom.xml // 发布用于前后端关联文件
└── README.md // 项目描述文件
- 整体基于
express，梳理app.js中的所有功能，引入一些自己业务特有的中间件，根据请求将不同的业务在这里分流。- 编写简单的中间件用于处理请求中的公共部分。
- 新增
common，将公共模块放独立，并将公共方法也放在common/util中，减少重复代码。- 新增日志模块，记录日志，增强定位问题的能力及系统的稳定性及安全性。
- 新增
MVC模式，将业务分层，解耦，并以功能划分模块，让结构更清晰- 接口均采用
restful方式，优化路径请求。- 新增测试文件，增强系统的安全性，提高测试覆盖面，让系统更安全。
- 优化数据结构及查库处理，增加索引功能，提高查库速度。
- 分离自动化测试库及线上库，独立自动化测试环境。
- 开启多进程模式提高服务器内核利用率及网络吞吐量。
- 拆分获取数据的逻辑，让基础信息和定制信息分开，具有一定的扩展性，能迅速根据业务线的不同来开发不同的统计列表。
- 增加自动重启守护进程，让系统更稳定。
优化之后除了统计接口，需要查多个库进行数据整合，网络请求在百毫秒级别，其他的请求均在百毫秒一下。
100并发持续3秒向服务器发起请求，QPS从60提高至550，这个应该是开了多核的缘故，而且我的电脑是八核。所以提高非常明显。
机构非常清晰。目前对项目比较满意。各种体会也是只有从项目中才能体会。
成品展示
希望在远方
尽管目前我的能力有限，已经不知道优化点在哪里了。但是我依旧对未来怀抱希望。我希望这个系统能随我一起进步。一起做更多的事。一起穿梭风雨。
- 产品优化：展示优化，数据丰富性的优化。
- 使用优化：目前已经做到了基本轻松上下线。而且在打点的时候成本较低。但是依旧有个问题。打点逻辑稍微有点复杂。还需要用户标识当前行为属于哪种行为。这个可以想办法优化。
- 技术优化：目前已经基本上能做到服务器稳定且承受一定的压力，数据量大的情况下，目前是前端做的分页。长远来看不是一个好的选择。这种解决情况是因为因为当时的主要性能瓶颈在渲染，而且数据库结构的建立也不是非常好。所以在取数据的时候，分页计算可能不好。在之后的扩展性方面可能还会有问题。可以再规划。在技术上的提升还有非常多的空间。因为问题一定很多。
我希望能带着希望前行