基于友盟的用户分析模块的设计

基于友盟的用户分析模块的设计

移动应用开发中基本都要用到用户分析,大部分的应用选择的友盟统计,我们也不例外(其实不是没有内部的统计,是实在是人手不足,做的没人家好用啊).这篇文章题主就来分享下自己是如何封装的统计模块.

为什么要做用户分析

用户统计分析移动应用开发商统计和分析流量来源, 内容使用, 用户属性和行为数据, 以便开发商利用数据进行产品,运营,推广策略的决策.

而我们针对性地进行应用内的数据统计,了解用户的产品使用细节及行为特征,可以更好的对寻找到产品改进的突破点,评估产品优化的效果.

用户分析是什么

空

如何做用户分析

我们先后用了公司内部统计系统A,内部统计系统B,最后还是用了友盟了.具体的使用,大伙可以看 友盟开发文档

用户分析有哪些痛点

然后友盟的用户统计分析用起来也不是那个爽快,这里笔者就只介绍自己在使用过程中的一些的痛点.

产品说我想知道事件A的来源是哪

你设计的页面P起初没有设计来源这个参数,产品说知道来源可以更好的分析用户行为. 你觉得有道理, 便在页面P的入口加了source的参数. 看似很轻松的就解决了这个需求. 突然你发现页面P是从页面A跳进来的, 页面A是从页面B或者页面C跳进来的,产品需你统计的是B和C,这时你不得不在BC上也加上source参数.

开发1不想破坏自己漂亮的代码

开发1是个极端的小伙,设计的类都尽可能可能要去少耦合. 他写了一个页面, 上面有A按钮,和条件B, 触发后都是走的C业务.从C的角度看,它们不知道是谁触发了他.从AB的角度来看,也不知道自己触发后是干嘛.

如何去解决它

待完善

---

业务需求

业务需求经过抽象后,基本可以分为两层

ui层

• 点击

业务层

• 开始
• 完成
• 失败(默认带失败原因)

我们的一个上报信息就由模块名 + 页面名 + 事件名字 + 事件类型 +事件子类型 + 上报的数据组成

设计思路

• 两套接口
• 需要继承一个类

接口一: 抽象工厂模式

接口二: 建造者模式

不足

• 存在了循环依赖,消除的方法也有,但是考虑到这是一个独立的模块,就没去弄了.

工作流

• 提需求
• 开发加代码(加新的,删旧的,暂时友盟不删)
• 测试按照流程走一遍
• 导出txt,归档
• 和旧版本对比,生成上报友盟的txt(自动化)
• 验证有没有漏报
• 上传到友盟
• 去友盟验证

未来

• 给所有UI事件加埋点,指定关心的事件上报