时间:2023-01-19 | 标签: | 作者:Q8 | 来源:网络
小提示:您能找到这篇{详解设计埋点过程中的“who when where how what”}绝对不是偶然,我们能帮您找到潜在客户,解决您的困扰。如果您对本页介绍的详解设计埋点过程中的“who when where how what”内容感兴趣,有相关需求意向欢迎拨打我们的服务热线,或留言咨询,我们将第一时间联系您! |
上次写了一篇《》,其中提到了一点设计埋点的方法,很多朋友留言说需要设计埋点的指南,像我这种从来不拒需求的人,这两天下班闲下来之后就整理了一下埋点设计的一些知识,希望能有所帮助。 在诸多招聘 JD 中提到的数据分析能力,主要是数据利用能力,利用数据的前提是有数据,并且在真正做数据分析的时候,经常会出现数据不足的情况,需要通过设计埋点去采集,当你有数据需求的时候,连需求都不知道怎么提,这岂不是产品经理最大的悲哀。 所以我们不仅要学会利用数据,更要知道如何通过埋点来采集数据,接下来说一说如何设计埋点。 一、想清楚为什么埋1. 想验证什么?《》中,我们明确了要验证的指标(北极星指标、方向指标、负面指标和行为指标),方向指标和负面指标是我图书营销 怎么做们的项目中的关键指标(没理解的话可以先看上一篇文章),通过埋点验证这两个项目指标,这就是我们的需求。 2. 确定分析思路一个页面那么多行为,也不能都埋点啊,我的埋点原则是:没有需求就别加,既能解决问题,又不浪费资源是最好的平衡点。 在真正设计埋点之前,就要想好怎么分析这些埋点,因为只有确定好了分析思路,你才知道需要哪些埋点,数据分析的方式比较多,这里不重点拆开说,列一些我们常用的一些分析方式,如果需要拆开讲,请继续提需求。 常用的分析思路: 对比分析 通常用于对比前后变化,比如功能上线前后日活人数对比。 分布分析 通常用于分析一个行为的在某个维度的分布情况,如美团外卖APP,点外卖这个行为,一天24h的下单量分布,来确定运力(骑手)高峰期。 多维度拆解 通常用于定位问题原因,如摩拜APP12月份使用人数暴跌,通过地区、版本等不同维度拆解,发现只有东北地区的使用数据暴跌,因为12月处于冬季,大冬天的东北,你想想骑车不得冻死手啊,这就找到了原因。 漏斗分析 评估一个使用路径的流畅程度,比如电商下单流程的转化率。 路径分析 分析用户的流向和路径,比如从首页开始,有多少去了商品详情页,然后又有多少去看李佳琪直播了,接着又去了哪里。 留存分析 留存的定义有很多:活跃留存、新增留存和精准留存。精准留存较少被提及,精准留存可以更好地评估功能价值,比如进过李佳琪直播间的用户列为精准用户,那这部分用户之后的留存情况,就一定程度反映了李佳琪对这个平台的影响效果了。 粘性分析 评估一个功能对用户的粘性,比如一个月内进李佳琪直播间29天,那这个用户粘性达到了29次/月,粘性很高,就是李佳琪的忠实粉丝无疑了(OMG,买ta!!哈哈)。 这是一些常用的分析思路,除此之外还有很多,如果不是做深入数据分析的话足够用了,而且不同的分析思路之间组合使用,可以得出更多结论,这些分析思路组合使用可以指数级提升分析能力。 好,根据验证指标,明确分析思路之后,接下来就需要梳理埋点了。 3.梳理埋点怎么埋呢?很像我们阐述需求背景,无非“who when where how what”这些信息,但是一旦细究就很可怕,但这都是我们需要和开发同学明确好的,来一个个看。 who
设备区分多用于不需要登录的产品,通过设备独有的编码来标记用户。账号区分是常用的方式,通过账号id、手机号等信息来标记用户。 when
设备时间可能会因为不同时区的原因,用户之间各不相同,比如跨国业务,需要分析用户的使用时间分布,北京的白天就已是美国的深夜,通过设备时间分析会更方便,北京的8:00不是美国的8:00,但都是早晨。 服务器时间就是常说的Unix时间戳,是全球统一时间,不受时区的干扰,如果不考虑业务特殊情况,一般都是使用服务器时间。 where
常用的就是获取用户的定位权限,然后通过gps进行定位,还有就是通过设备ip判断用户位置。 how
用户是怎么完成这个行为的,像上述这些信息都算,不止于此,看业务需要,可以继续扩充。 what
what就要看业务行为了,举了上面两个例子,并引入了“事件”和“属性”两个概念,事件是指具体的行为,属性是指行为相关的一些信息,如商品下单这个事件:
这个要根据不同的业务需要,在埋事件的同时,增加必要的属性,以便深入分析数据。 想验证什么 → 明确分析思路 → 梳理埋点,就明确了我们的埋点需求,接下来就要把我们的埋点表达出来。 二、说明白怎么埋1. 前端埋?后端埋?这个问题江湖上也是议论纷纷,说哪个好的都有,我没有明确的结论,更喜欢抖加投放计费方式和开发哥哥沟通协定,技术层面他们更专业,以下是我对这种埋点方式的一些看法,仅供参考。
我建议还是和拉着前后端开发哥哥一起聊聊,让他们在技术层面会给出专业的建议,我们得到一系列专业信息之后再去做决策,这才是我们擅长的事情。 2. 埋点的技巧和注意事项a.漏斗分析要闭环 这也是《》中讲过的,不赘述了。 b.上报时机要准确 一个行为的发生要经历事件触发(前端) → 数据入库(后端) → 事件发生(前端)的过程,以电商购买这个操作为例,点击购买按钮(事件触发) → 后端验证库存等信息后返给前端结果(数据入库) → 跳转到下单页(事件发生)。 我们应该选哪个环节上报呢?高精度的埋点需求建议如下:
以上这两种方式可以保证数据结果的准确性,我们也会有一些低精度的埋点需求,比如只想大致了解一下页面各按钮和操作的使用情况,可以采用事件触发环节上报。 c.事件要尽量合并 出于维护和使用方便的考虑,能用属性解决就不要徒增事件。 还是以商品下单流程为例,我们想验证直播带货的能力,就需要区分直播间下单和普通浏览下单,有以下两种方案:
从埋点的简洁性和易用性来看,第二种方案是更好的,便于分析的同时,避免了埋点的臃肿。就像写代码一样,很多种写法都能实现需求,但是三行代码就是比三十行代码优秀! d.抽离出公共属性 在上面的“who when where how what”中,罗列了很多埋点信息,其中有些属性是很多事件中都会用到的,比如用户身份是否vip、省份,以及使用的设备型号和操作系统,这些属性我们可以抽离出来作为公共属性,不需要每个事件都单独上报这些属性,统一上报,这样做了之后,追求代码效率的开发哥哥肯定会喜欢你的。 一些不常用的属性就不要抽离出来了,比如商品退货行为中的“退货原因”这个属性,只有在退货这一个行为中有,在其他地方都是用不到的,所以在退货事件上单独上报更合适。 3. 写数据需求文档(DRD)电商APP商品详情页访问事件DRD示例: (点击放大查看) DRD所需信息:
和PRD一样,也是团队内部信息传达和留存的重要文档,需要做到完整且清晰易懂,写完DRD就等着开发哥哥给你加埋点吧! 三、验证埋点对不对看本次埋点是否正确以外,一定要验证其他相关埋点是否正确,不确定会影响哪些埋点的话可以提前和开发哥哥沟通代码影响面,因为可能会在增加埋点的时候涉及了其他埋点的代码,导致埋点上报错误。 数据分析,以及驱动业务,是当前产品经理的必备能力(90%的人都会,剩下的10%你能活的舒服吗?),利用数据的前提是有数据,所以采集数据的能力也很重要,而且想要啥数据的时候,直接可以自己去采集,岂不是很爽?哈哈。 四、最后总结一下
作者:十八线产品,微信公众号:十八线产品 本文由 @十八线产品 于,,。 题图来自 Unsplash,基于CC0协议 ![]() |
上一篇:怎么用“用户数据“驱动“增长”?
下一篇:数据导向的策划和运营:产品定位和产品设计(
小提示:您应该对本页介绍的“详解设计埋点过程中的“who when where how what””相关内容感兴趣,若您有相关需求欢迎拨打我们的服务热线或留言咨询,我们尽快与您联系沟通详解设计埋点过程中的“who when where how what”的相关事宜。
关键词:2年, 初级, 数据埋点,