一、背景
作为开发比较关注的是线上App整体的性能数据。例如内存方面：App运行时内存分布、是否存在泄露。灵敏度方面：卡顿上报的数量、App冷启动耗时分布等。
但一段时间以来，开发侧对于线上一个比较复杂的业务流程整体的运行情况是不了解的，对此也没有一个数据认知。由于是复杂的业务流程，基于此我们希望将漏斗数据模型应用到监控复杂业务逻辑执行上，推进代码逻辑的优化。
本篇基本没有代码，主要是观点讨论。
二、漏斗数据模型
什么是漏斗模型？
漏斗数据模型在产品同学应用的比较常见。当业务流程变长的时候，用户会流失，这样把整个流程串起来看，就好像一个“漏斗”一样。例如在电商App中，从用户进入App开始，浏览商品，进入商品详情页，添加到购物车，进入购物车页面，点击购买按钮进入支付页面，购买完成。一整个流程就是一个漏斗。
产品同学会关注整体的转化率，那么作为研发同学，我们也在考虑如何将漏斗模型引入到我们的开发过程中。
三、以业务流程举例，看漏斗模型如何应用
我们是否可以做一些流程埋点，帮助我们
- 依据流程埋点创建一个大盘数据，查看某个流程的成功率/失败率。协助开发定位失败的原因是什么，失败率是否可以降低？
- 依据流程埋点查看某个流程的漏斗数据。查看这个流程是在哪一步，或者哪几步有较多的丢失？这些丢失或者说失败是否可有优化?
- 依据流程耗时埋点，我们是否可以看到关键业务的耗时数据，输出耗时占比饼状图。优化耗时较大模块？
从另外一个角度来讲
作为程序研发，我们经常要汇报当前程序的状态、个人的技术优化。当我们通过埋点统计出来数据，汇报时添加上数据的变化，才会更加可信。例如最近一年经过我的优化，我将某某业务流程的成功率从91%提高到98%，这样可信度将会更高。
1、以被叫入会流程举例看流程成功率
我们的App中包含音视频模块，核心的音视频能力是使用了某SDK，我们业务负责封装上层UI、呼叫被叫 通知、会议信息等逻辑。
漏斗流程不是常规的平铺埋点，常规的平铺埋点主要是统计业务的触发次数，漏斗模型是要把步骤链接成一条线。基于业务逻辑，我们需要整理出来：
- 业务起始点
- 业务结束点
- 如何把重要步骤埋点成线
统计出来数据不是最终目的，它是一个评价线上业务逻辑质量的一个数据指标。我们最终目的是真实的改善线上业务成功率，提高用户体验。埋点的设计和实施要考虑好后续如何搜集问题、定位问题、解决问题。
被叫入会流程总结为：
【TCP被叫】-【UI展示】- 【用户操作】-【锁定入会】-【进入会议页面】
- TCP接到被叫通知为开始
- UI展示：在我们的业务中有全屏被叫页面、有浮窗权限会优先展示被叫浮窗
- 用户操作：页面中的接听、拒绝。用户可以点击接听、拒绝按钮，同时用户也可以选择不操作直到超时。
- 锁定入会：调用服务端接口，锁定入会状态，拉取入会必要参数
- 打开页面：调用SDK接口入会，进入会议主页
2、埋点设计
被呼叫
| 字段名称 | 字段含义 | 枚举值 |
|---|---|---|
| funnel_event | 埋点事件 | beCalled |
| funnel_event_string | 统计值 | login : 启动App后登录检测被叫 tcp : 在线通知 |
| trace_id | 串联埋点用的Id |
trace_id：用于串联埋点，被呼叫时候创建这个值。
UI展示
| 字段名称 | 字段含义 | 枚举值 |
|---|---|---|
| funnel_event | 埋点事件 | beCalled |
| funnel_event_string | 统计值 | calling_page : 全屏被叫页面 calling_dialog : 顶部被叫浮窗 |
| trace_id | 串联埋点用的Id |
用户操作
| 字段名称 | 字段含义 | 枚举值 |
|---|---|---|
| funnel_event | 埋点事件 | beCalledUserAction |
| funnel_event_string | 统计值 | cacceptJoinPage：页面接听 rejectJoinButtonPage：页面拒接 ... |
| trace_id | 串联埋点用的Id |
锁定入会
| 字段名称 | 字段含义 | 枚举值 |
|---|---|---|
| funnel_event | 埋点事件 | beCalledCheckIn |
| trace_id | 串联埋点用的Id |
进入会议室页面
| 字段名称 | 字段含义 | 枚举值 |
|---|---|---|
| funnel_event | 埋点事件 | beCalledSuccess |
| funnel_event_string | 统计值 | meetingRoomPage：会议室页面接听 inWindowInit：小浮窗进入状态 |
| trace_id | 串联埋点用的Id |
3、上线后续
校验数据
第一版统计上线后，我们通常要先校验数据。虽然上线前我们也会有测试，但是依然避免不了，某些流程我们可能存在遗漏、重复上报的情况。
统计第一版数据之后，可能你会发现一个漏斗模型会变成一个倒葫芦模型，某一个节点数据量比上一个点数据量大，这明显就存在问题。要么是上一个节点遗漏统计，要么是这个节点重复统计了。
所以校验数据则非常必要，一般我们会花两个版本将数据完全校验正确。
基于漏斗发现的问题
收到TCP呼叫，无法弹出页面
新版本上线后，我们发现收到TCP呼叫到UI展示这个环节的转换率比较低。原因是当App被切换到后台，此时进程存在，TCP长连接也存在。此时收到TCP呼叫后，由于应用被用户切换到后台此时无法将呼叫页面弹出。
针对这个问题我们调整两个点：
- 收到呼叫则开始响铃+震动，而不是等待UI展示完成后，才响铃+震动，将UI展示与响铃震动拆分。
- 调整交互，增加相关权限的申请。让系统允许App在后台弹出页面
调用SDK接口入会失败，错误信息：无解码器
调用SDK接口入会，无法入会成功，错误信息为无解码器。这点为完全的SDK问题，直接反馈给SDK方处理。
已入会，无法再次入会
区分两种情况
一种是用户已入会，将App至于后台，此时系统将应用所有页面回收，进程依然存在可以正常会议中开会。用户点击桌面图标，重新打开App所有页面重建，当用户点击入会时，此时报错“已经入会，无法重新入会”。
第二种是入会之后，没有正常的结束会议导致状态丢失，如用户杀进程。而后其参加别的会议提示“已经入会，无法重新入会”。
基于以上两种情况，均需要针对性的解决。
...
总结
以上很多问题都是通过数据大盘发现的问题，优化之后也确实可以看到每个节点的转化率提高。以上很多问题可以看做是逻辑优化，也可以看做是Bug修复。但是很多问题依靠QA测试，是不见得能够发现的，尤其是QA同学可能经验不是很充分，人力不充足的情况下，通过线上埋点数据可以帮助我们发现更多问题。
同样做了很多Bug修复、逻辑优化，当我们能够拿出数据后，无疑是更有说服力的。在案例中我们经过优化将用户操作-成功入会进入会议页面的成功率从95.72%提高到99.82%
