首页 > 其他分享 >bussiness_data可观测性实践--drop_off_rates

bussiness_data可观测性实践--drop_off_rates

时间:2024-01-27 16:03:57浏览次数:19  
标签:bussiness off business -- drop path group 用率 页面

这是很去年和小伙伴的一次头脑风暴,有关弃用率如何算,本来清闲时鼓捣,无奈中途有事中断,不过将来也还有机会,拿出来耍,不喜勿喷。

定义

常见定义:

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

举几个例子,开通一个新账户或完成一次购物流程,或者假设用户要注册新账户,必须要在5个页面上填写相关信息,则通过观测注册历程中的5个页面中的用户百分比的数据,就能得出弃用率。

如何计算--例子

bussiness_data可观测性实践--drop_off_rates_产品

bussiness_data可观测性实践--drop_off_rates_产品_02

很显然,上图页面4的弃用率是最大的,为21%;要清楚了解是什么导致页面4 的弃用率如此高。

现实难题

第一个难题 给产品

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

第二个难题 给产品和技术

然而,business_route/journey有两个不可逾越的大山:

  1. 非常难以获取或者拆解
  2. 常变动且根因难以确定

如何自动巡检弃用率

假设要实现自动巡检弃用率的功能,该如何实现?


bussiness_data可观测性实践--drop_off_rates_数据_03






单独以网站访问路径进行思考,基本会整理成以下图,

bussiness_data可观测性实践--drop_off_rates_产品_04




实际上复杂模型可能是这样,不论是通过page_view_count还是通过通过viewId查看。


bussiness_data可观测性实践--drop_off_rates_4th_05





但实际和上面计算的逻辑一样,还是通过view_count来算,通过计算viewID_children_percent的列表,页面层级在这里我们只看一层:

top_down_disgraded_algo

脱离business_routes/journey,如何定义一个通用的top_down_disgraded_algo? 假设存在以下场景。

bussiness_data可观测性实践--drop_off_rates_4th_06





也就是一个网站有多个页面构成,也就是存在以及一级路由、二级路由、。。。N级路由,网站的访问情况可能是一张复杂的图,不同的



bussiness_data可观测性实践--drop_off_rates_性能优化_07








每个层级存在循环引用,每个路由可能是首次访问或者跳转到其他级别路由,这张交错的网让本就复杂且不断增加的逻辑更加复杂。这里我们简化一下

bussiness_data可观测性实践--drop_off_rates_产品_08






上图还是不够简化,同时也有覆盖不到的业务交叉的场景,我们跳出这个怪圈,

转换思路

转换一下思维模型,跳出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

这样一看,是不是突然整个世界都清晰了?这和漏斗模型很相似,但又完全不同。


bussiness_data可观测性实践--drop_off_rates_产品_09




这里有一个陷阱,拍脑袋出来的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的意义都很大,无奈当时只做了一部分,就没有继续再做。

标签:bussiness,off,business,--,drop,path,group,用率,页面
From: https://blog.51cto.com/u_12003135/9443880

相关文章

  • 可观测性系统中对用户行为如何记录的一些简单介绍
    本文仅讨论核心代码的技术实现思路,以及从代码中看出来的一些内容,涉及到的内容基本包含以下四个文件rumEventCollectionactionCollectiongetActionNameFromElementlistenActionEventstrackClickAction以下内容,方便用户了解,我做了一些整理,包括精华代码部分。监听事件获取的前提第一步......
  • 可观测性之删库跑路后的现场还原
    数据库是公司重要资产,在此类重要资产平台上,尤其是重要操作,应该保持敬畏心。数据库被删了?可怎么证明是某某某删了数据库?或者根本都不知道谁删除了数据库,又没抓现行,该怎么办?正文第一步证据先行,有录屏有真相删库动作的录制回放录制回放让团队能清楚了解和学习用户路径和行为,其中对于......
  • 可观测性之如何识别网站文件命中了缓存?
    为了告慰良心,webdeveloper搞了可视化、组件化、工程化、微前端、低代码。网站平均加载时间依然客死在2s内。讲的是如何判断网站使用的文件是缓存,有关使用的本地存储数据(ls、ss等)不在讨论范围。说清楚范围后,说一下分类,这里的文件缓存有两类,第一类是:diskcachememorycache这里的缓......
  • 可观测性之到底卡在了哪里,2023年再撒谎网慢就说不过去了
    前言互联网下行带来灵魂追问。钱花哪去了?产出在哪里?动辄自建的遮羞布逐步显现,不过自建的成本可能还不是最大的负担,掣肘的可能是把不重要的事情当成了主业来做,比如:互联网+比如数字化转型比如研发效率和devops比如可观测性本次要“安利”的新功能叫做应用Span请求耗时分布显示,建议......
  • 你好, 2023,最该问自己的7个问题
    适合打印下来放在日历上7个简单问题,快速反思2022,让2023勇往直前1.被"炒鱿鱼"收获成功需要不断分析什么有用,什么无用假如能掌控人生,要想更加成功,该放弃什么,开始什么,这两者间,什么在阻挡你?假如能掌控人生,从今天开始,我会立刻停止哪些事情?2.增加与减少享受爬山的过程,自然能登顶什么能......
  • 扪心自问,我们在真实用户旅程的投入有多匮乏?
    做事情,“科学精准”的态度在面对是否直接吃药这个问题上,很多人画了草图,认为直接吃药。根据梅奥公开的诊断流程,针对可能新冠的儿童我们应该:根据梅奥公开的诊断流程,针对成人我们应该:写作背景15年一直再看流程图,前两天看到有关国外针对新冠的路径图,正好有小伙伴问,如何做故障的根因分......
  • 多系统萎缩背后,六个行为可能暗藏杀机!别怪我没提醒~
    多系统萎缩是一种罕见的神经系统疾病,会影响人体的多个系统,包括自主神经系统、运动系统和感觉系统等。患者可能会经历肌肉僵硬、协调性下降、平衡感减弱、大小便失禁等症状。随着医疗技术的进步,多系统萎缩(MultipleSystemAtrophy,MSA)患者的生存期已经得到了延长。然而,由于这些症状......
  • 可观测性之讲解用户行为分析的推荐书单和总结
    技术文延迟了本来计划参加活动的还有一篇,应该是一篇技术翻译文,但是那篇文章太难了,看我过我以往文章的同学,应该能理解,我的文章很少有3000字数以下的,而且如果不是来自谷歌(主要因为是内容都反复被验证过,其次公开资料也不存在内容侵权),就一定会是我自己的一些想法或者吐槽,而且大多都不仅......
  • 期权一张纸-不争连纸都没有-立足当下-观测未来-33岁前端程序员年终总结
    文章基本按照时间顺序,约5千字,内容讲的是:一场意外被辞,一场说走就走的旅游,一份5年亲密陪伴,下水捞过鱼,吃了“金蝉子”,野外路过营,举办了几次技术直播,我会简单陈述一下2022,希望明年总结能有一些精彩。因为是参赛文章,所以希望您能点赞、评论、转发或者评论666离职背景程序员被忽悠,期权大......
  • 我们前端同学最该关注什么-附评分思路
    来点实际的吧说一下我的想法(吐槽),我们是否对过程太过痴迷,忘记了我们要什么?文末给出我认为的好的标准比如:大家仿佛都在看框架、工具包和开发过程中的内容,这点可能是因为工期紧张,留给前端开发的时间不够,但996已经常态化的情况下,我们是不是该审查一下我们的结果:页面是否秒开?页面报错多......