这是很上一年和小伙伴的一次脑筋风暴，有关弃用率怎么算，本来清闲时鼓捣，无法半途有事中断，不过将来也还有机会，拿出来耍，不喜勿喷。

界说

常见界说：

弃用率适用于观测用户是不是在由一些类网页构成的操作流程半途退出或放弃。

举几个比如，注册一个新账户或完结一次购物流程，或许假定用户要注册新账户，必须要在5个页面上填写相关信息，则经过观测注册进程中的5个页面中的用户百分比的数据，就能得出弃用率。

怎么核算–比如

bussiness_data可观测性实践--drop_off_rates
bussiness_data可观测性实践--drop_off_rates
很显然，上图页面4的弃用率是最大的，为21%；要清楚了解是什么导致页面4 的弃用率如此高。

现实难题

第一个难题 给产品

在1-2-3-4-n等级的状况下，有m条business route，depth不定，常见的用户想法是，获取business_routes、journey，这种思想模型是个大坑。

第二个难题 给产品和技术

然而，business_route/journey有两个不可逾越的大山：

  1. 十分难以获取或许拆解
  2. 常变动且根因难以确定

怎么主动巡检弃用率

假定要完结主动巡检弃用率的功能，该怎么完结？

graph TD
auto_drop-off_rate_cruiser--> bussiness_routes/journey
bussiness_routes/journey --> auto_top_down_calculator
bussiness_routes/journey--> manul_setup
auto_top_down_calculator --> top_down_disgraded_algo
manul_setup --> to_be_continued1
top_down_disgraded_algo --> to_be_continued2

单独以网站拜访途径进行考虑，基本会整理成以下图，

graph TD
view_path--> path_group1
view_path--> path_group2
view_path--> path_group3
view_path-->  path_group4
path_group1-->  path_group2
path_group2-->  path_group3
path_group3-->  path_group4

实际上杂乱模型可能是这样，不论是经过page_view_count仍是经过经过viewId检查。

graph TD
viewId_total--> path_group1
viewId_total--> path_group2
viewId_total--> path_groupN
path_groupN-->  path_groupN.1
viewId_total--> path_groupN.1
viewId_total--> path_groupN.2
viewId_total--> path_groupN.3
viewId_total-->  path_groupN.4
path_groupN.1-->  path_groupN.2
path_groupN.2-->  path_groupN.3
path_groupN.3-->  path_groupN.4
path_groupN.1-->  path_groupN
path_groupN.1--> viewId_total
path_groupN.2--> viewId_total
path_groupN.3--> viewId_total
 path_groupN.4--> viewId_total
path_groupN.2-->  path_groupN.1
path_groupN.3-->  path_groupN.2
path_groupN.4-->  path_groupN.3

但实际和上面核算的逻辑相同，仍是经过view_count来算,经过核算viewID_children_percent的列表,页面层级在这里咱们只看一层：

top_down_disgraded_algo

脱离business_routes/journey,怎么界说一个通用的top_down_disgraded_algo? 假定存在以下场景。

graph TD
business_Data_total--> path_1
business_Data_total--> path_2
business_Data_total--> path_3
business_Data_total--> path_N

也便是一个网站有多个页面构成，也便是存在以及一级路由、二级路由、。。。N级路由，网站的拜访状况可能是一张杂乱的图，不同的

graph TD
business_routes--> path_1
business_routes--> path_2
business_routes--> path_N
path_N-->  path_N.1
business_routes--> path_N.1
business_routes--> path_N.2
business_routes--> path_N.3
business_routes-->  path_N.4
path_N.1-->  path_N.2
path_N.2-->  path_N.3
path_N.3-->  path_N.4
path_N.1-->  path_N
path_N.1--> business_routes
path_N.2--> business_routes
path_N.3--> business_routes
 path_N.4--> business_routes
path_N.2-->  path_N.1
path_N.3-->  path_N.2
path_N.4-->  path_N.3

每个层级存在循环引证，每个路由可能是初次拜访或许跳转到其他等级路由，这张交错的网让本就杂乱且不断增加的逻辑更加杂乱。这里咱们简化一下

graph TD
business_Data_path--> path_N
path_N-->  path_N.1
business_Data_path--> path_N.1
business_Data_path--> path_N.2
business_Data_path--> path_N.3
business_Data_path-->  path_N.4
path_N.1-->  path_N.2
path_N.2-->  path_N.3
path_N.3-->  path_N.4
path_N.1-->  path_N
path_N.1--> business_Data_path
path_N.2--> business_Data_path
path_N.3--> business_Data_path
 path_N.4--> business_Data_path
path_N.2-->  path_N.1
path_N.3-->  path_N.2
path_N.4-->  path_N.3

上图仍是不够简化，一起也有覆盖不到的业务交叉的场景，咱们跳出这个怪圈，

转化思路

转化一下思想模型，跳出business route/journey这个圈子。 这里，我拍脑袋将一个公司网站5级系统:

  • 1st_path_group，
  • 2nd_path_group，
  • 3rd_path_group,
  • 4th_path_group,
  • 5th_path_group，

姑且以为:

  1. 能获取5级view/user数据
  2. 5级能代表涵盖一切business_routes
  3. 不足5级主动补位
  4. 只关注drop_off_rates

这样一看，是不是忽然整个世界都明晰了？这和漏斗模型很类似，但又完全不同。

graph TD
1st_path_group --> 2nd_path_group
2nd_path_group --> 3rd_path_group
3rd_path_group --> 4th_path_group
4th_path_group --> 5th_path_group

这里有一个陷阱，拍脑袋出来的5层结构无法覆盖用户途径较长的状况。

模仿数据1:用户数量和成功完结每一页操作过程的用户数量之比。

页面 成功率
children1 89%
children2 80%
children3 73%
children4 52%
children5 49%

模仿数据2:到达页面也成功完结页面操作的百分比之差

页面 成功率
children1 11%
children2 9%
children3 7%
children4 21%
children5 3%

待定

  1. 在drop_off_rate_list中，找到top，这一步已经十分难得了。
  2. 相关剖析，top_drop_off_rate可以归因到哪里。

bussines value（用户、流量）

从业务增长或许用户流量的视点来看，drop_off_rate的含义都很大，无法当时只做了一部分，就没有持续再做。

本文正在参加「金石计划」