Mf175-用户注册功能-埋点敏捷方案

在不了解埋点系统的情况下，花了五六个小时 帮一位PM朋友做的方案。记录下来。以备后续参考

Mf178-用户注册功能-埋点敏捷方案

版本号	时间	撰写人	描述
V1.0	20190515-10:50:00	冰灵	初稿
V2.0	20190515-14:10:00	冰灵	与架构师WB进行沟通讨论了1.5h 最终对讨论结果进行整理

1. 需求背景

PM希望实现： 目前注册这块，有三个环节，每个环节有好几个输入框，他想知道 用户在向下操作的过程中不断流失的情况。

 

 

 

2. 埋点方案

基于考虑公司人力支持及成本的考虑，并没有必要实现一个大型的埋点系统，故提出一个快速敏捷方案

实现前端监控的步骤为：前端埋点和上报 -->数据处理 --> 数据分析

3. 埋点方案详情

3.1前端埋点和上报

每次输入框输入结束 可通过 JS的事件触发，去调后台记录一条信息到数据库

3.1.1触发时机：

①　是光标落下去的时候发送事件，还是填完了光标转移的时候发送事件，哪个更好呀？？

因为目标就是为了知道有多少人输入到哪个框就不想填了还是填完以后发送事件更合适

②　目前设定的是 输入框结束，但是其实 觉得不是太确定，因为感觉用户在页面操作会有各种操作。不知道这个是否合理。你说的对，用户是会有各种操作比如可以先点最下面的框，最后输入最上面的

但是正常人都是从上往下的对吧。异常情况可以考虑但不用太过关注是不是

调研用户情况 小于1% 故当前无须特别处理

 

③　讨论过程

WB:如果你想知道用户是具体填写到哪一个输入框的时候退出的，那就得再每一次他切换焦点的时候都去上报整个表单的内容才可以

WB:如果是说先记录下来，到最后他提交表单的时候统一去上报的话，如果他不填写完这个表单就退出了，你是没有办法知道他到底放弃在哪一个输入框

WB:还有要注意的一点就是每一次一定要把整个0表单的内容全都报上去，因为用户有可能不先填写第一条，而是先填写后面的

WB:每次上报整个表达的内容就可以知道这个用户在填写的时候的填写顺序

WB:在表单提交的时候，肯定还会有一次事件的上报，这一次就要小心一点，因为表单提交完，页面会立刻跳转，上报要在这个跳转之前做，不然这个上报请求是发不出去的

BL:这个方案的兼容性是非常好的，主要是 在想这种业务场景占比特别小。如果说我们为了兼容这个要做出比较多的操作的吧，收益是不划算的，所以有可能会做一些平衡和取舍。

WB:是的，所以这个事情我只是提一个比较通用的方案，具体的情况可能还要根据PM的需求以及实际你们想要花费的代价，来做一个权衡

 

3.1.2记录内容

这条记录的数据包括至少以下信息：

UserId  用户IP等（能标识一个未注册用户的唯一标识） IP+UA+pvid+ 一次注册操作的唯一标识 + 页面标识（基本信息，支付宝信息）+输入框标识（如 手机号，图形验证码等。。。）+datetime 日期时间

 

备注：

①　UA:user agent 通过http头部信息取

②　PVID

因为一个用户可能多次打开这个页面，需要有一个pvid，每次打开的时候，随机生成一个串就可以了，保证两次打开，这个串不同。如果这三个页面是一个流程，那也可以就 在第一个页面生成pvid，然后传递下去。（如果这三个页面是一个流程，那也可以像你说的，在第一个页面生成pvid，然后传递下去，这样做的前提是，一定不能跳过第一个页面直接进入第二个页面。一般用户也没法直接进行到第二个页面吧，理论上是这样，如果真的可以直接进入第二个页面，会对最终的数据产生干扰。）

 

③　技术实现

实际生产数据

User-Agent:

Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36

其中IP+UA 可以兼并，不需要解析它用ip和ua组合取个摘要 可采用MD5

 

3.1.3上报频繁问题：

如果担心时间上报很频繁的话，客户端可以做计时的处理

比如他两次上报的间隔，如果不超过一秒钟，那就第二次就不要报，因为在一秒钟的时间，正常人是没有办法在输入框里填写一个有效的内容的

这策略可能还要根据你实际的用户量做一个权衡。

用户量调查：存量 10几万用户  增量 ：每天几百个注册  故现阶段不作代码处理

 

3.2数据处理

3.2.1 定期后台批处理

以用户的一次注册行为 作为统计 根据统计场景 根据具体业务需要去重 统计各个输入框的总数，如果有时间需要，可以分析出一个用户的一次注册行为在每个框的耗时并记录到一张表

 

3.2.2 数据库or 文件 选型：

后端的话比较简单，用一个接口接受数据就可以了，可以看一下用户量，如果不大存在数据库也是可以的。

 

3.2.3 定期清理的替代方案：

如果长期统计需要关注 累积业务数据会越来越多。表设计可以设计为一张table_xx表和 table_xx_history表，其中table_xx 放业务数据，table_xx_history 放已作过数据分析的业务数据。

 

3.3数据分析

根据各个输入框的总数的递减可以手工绘制趋势图  分析 用户的各个框的流失情况。

根据 耗时记录信息，可以知道每个用户的具体时间长短。

 

 

3.4备注

1. 统计信息以【一个用户一次注册操作】为分析对象。
2. 记录的数据 根据需要进行更多的增加调整。
3. JS触发调后台记录，要考虑好触发时机。