用户访问操作统计分析解决方案

公司上线了诸多产品，每个产品也有很多功能，但是每个功能的使用情况及用户偏好情况等相关信息一直是缺失的，为了更好的收集用户行为及使用习惯，那么对用户使用行为的埋点就尤为重要了

结合公司今年的平台加服务的战略目标，深耕企业能源管理系统时，对重点（试点、标杆）企业的用户使用情况进行分析时都需要有用户行为埋点作为分析的支撑。

新功能发布后用户使用频率可以作为功能是否成功的重要评估依据。

背景： 

记录指标模型：记录id、用户标识（用户id）、访问内容标识（模块ID）、动作、操作时间

Counter模型：事件id、分类、动作、具体Counter数值

数据模型：

1. 前端直接对接三方平台，数据进入三方库，三方平台提供界面展示，对后端服务无影响，无统计计算压力。

2. 三方平台针对了不同平台（WEB、移动端）的接入方案（圈选埋点、代码埋点），前端接入可能相对容易一些

3. 新增统计点不需要重新上线

优点

1. 数据在第三方平台库，如果后期需要复杂的统计需求可能需要手动/接口获取数据到自己系统存储后分析

2. 无法与用户关联，导致无法与用户的其他信息进行关联

3. 数据存在第三方，存在数据安全风险，不利于对数据的多样化使用

缺点

实现难度： 前期简单，后期适中，定制化展示困难

实现周期： 前期较短，后期适中

方案一：前端三方统计平台，如：百度统计(移动统计数据获取API，Web网站统计数据获取API)、Umeng（友盟+）等平台

1. 自行存储灵活度比较高，定制化比较强

2. 数据存在自己的平台中，数据安全，数据使用灵活

优点

1. 无简单的模板展示，需开发与设计，前期落地存在一定工作量（若无界面展示要求，直接落库即可，工作量相对较小）

2. 前端接入需要侵入业务代码，比较分散，不易于管理和维护

3. 新增统计点需要重新上线

4. 需开发埋点接口、存储到单独数据库或者各自业务数据库

缺点 

实现难度：前期实现较简单，后期扩展难度适中

实现周期：前期周期短，后期逐渐迭代

方案二：存储到数据库Mysql/MongoDB、业务系统自行统计分析

1. 规范化存储，便于后期大数据同事进行各种复杂的统计计算，满足公司统计需求

2. 可以统一指标口径，方便统一维护

3. 可进行留存、漏斗、用户画像等复杂数据挖掘分析，专业度高，业界对于用户行为数据分析属于大数据一部分

优点

1. 需要根据对应的统计分析需求开发对应的界面平台展示或三方已有的画像工具

2. 涉及组件较多架构复杂开发周期较长

3. 前端接入需要侵入业务代码，比较分散，不易于管理和维护

4. 新增统计点需要重新上线

缺点

实现难度： 比较难

实现周期： 较长

方案三：存储到大数据平台，由大数据进行数据分析画像或业务获取界面展示

1. 存储到Prometheus，性能高

2. 结合Grafana平台提供简单、方便、快速的数据分析结果展示（50%）

优点

1. 需重新搭建一套Prometheus平台，彻底分离系统监控和业务监控

2. 需自行开发exporter暴露metrics，业务方需开发埋点接口

3. 后期需要复杂的统计需求也需要导出数据，存在一定的工作量

4. 前端接入需要侵入业务代码，比较分散，不易于管理和维护

5. 新增统计点需要重新上线

实现难度： 前期难度适中、后期复杂

实现周期： 前期周期短、后期适中

方案四：存储到Prometheus，利用Grafana简单展示（50%），复杂统计需求由业务方自行开发统计展示

1. 存储到ElasticSearch，性能高；且ElasticSearch额外提供了基于Query DSL的查询接口，可接入Prometheus等其它平台，也可以进行其它定制化的开发（如定制化的前端展示）

2. Kibana提供了多种维度的分析、统计图表，使用方便

3. Logstash结合FileBeat提供了同步和异步两种上传数据的方式，是否需要侵入业务代码，由开发者自行选择

优点

1. 需要重新搭建一套ELK环境，与现有日志收集的ELK隔离

2. ELK涉及的组件较多，维护量大

1) 定期删数据；适用于历史数据作用不大的场景，简单易实现

2) 对历史数据进行热备、冷备；适用于历史数据重要、不能删除的场景，但会进一步拉高成本，提升整体复杂度

3. ELK高度依赖内存，数据量较大的情况下成本较高，所以通常会采用以下两种策略：

缺点

实现难度：前期适中，后期复杂

实现周期：前期较短，后期适中

方案五：接入ELK，存储到ElasticSearch，并通过Kibana展示，也可自行开发页面

解决方案：

优选方案： 视具体情况

最终方案： 视具体情况

用户访问行为统计实现方案