产品经理需要了解的埋点知识

为了更加有zhēn对性、科学、客观的对产品优化迭代,产品经理会进行产品埋点,期望X分析上报的数据来获得某种趋势、特征的信号或者说信息,最后,这些信息被用在产品优化决策上。本篇文章中,笔者对产品经理需要了解的埋点知识进行了梳理,攻大家参考和学xí。

产品经理工作的三个常态就是写文档、沟通、看数据。毕竟辛辛苦苦写完需qiú文档还冒着被砍需qiú的风险,好不容易说服了研发开发上线后,总是要关注自己在研发面前吹上天的功能在上线后数据方面是不是有变化。

另外产品经理的本质工作是发现问题、分析问题和解决问题,写文档也好,沟通跟进项目也bà,最终的目的都是为了解决问题,那怎么证明问题被解决了?

除了X反馈某个问题的声音没了以外,最直观的就是X数据降低了,正向数据升上去了。

产品经理的价值除了实现用户价值,解决用户的各种问题痛点以外,还需要实现商业价值,毕竟老板给定的OKR既不会让研发背也不会让测试背,对结果负责的只能是产品了。

那产品怎么证明自己勤勤恳恳夜以继曰的工作是有收获的呢?

数据是让老板满意最有效的方式,毕竟曰活能从10w做到100w对企业来说是完全不一样的概念,直接的商业价值比如shòumài的收入转化从0.4%做到4%就有可能让企业真正的存活下来。那数据从哪来呢?今天就好好说道说道埋点的全liú程。

前面说了产品经理想看数据那就需要多方配合,既然自己需要数据,除了用户的行为会反映在数据上以外,想要直观看到数据中间还是隔了不止一座山不止一片海(最近看了张嘉jiā的《云边的小mài部》各种huá丽辞藻堆砌基汤文不jìn被带了节奏),毕竟自己也没fǎ看到每个用户的使用情况。那又该如何是好呢?「为何处境如此的像唐僧」

这里就需要我们万能的研发了,不仅需要他们X飞舞地敲动键盘上的字母转瞬间变成代码,进而将cǎo图上不堪入目的功能概念变成触手可及的实用功能,也需要他们继续飞指间将X用户行为的代码也一同写进去。

研发能X用户的行为但毕竟这些东西都还是在代码里,可视化的效果确实有点难,这里就需要数据分析的同学进场了,产品经理除了跟研发提数据需qiú,也需要跟数据分析的同学提需qiú,把X到的数据变得可视化,易于直观的看到自己想要的结果。

上面说了这么多,那我们就正式的来说每一步吧~

「埋点原理及方式」

首先是关于埋点的概念,毕竟做啥事能明白其中的原理还是很重要的。

埋点是指对目标X进行捕获、处理和上报的相关技术及实施过程,其主要目的是实现用户对产品行为的监控与数据收集。

具体来说就是在定义的X代码中植入一段监控代码,用户一旦触发该X就会上报埋点代码中定义的需要上报的字段信息;通俗的说就是实现了给每个用户在使用自家产品时分配了一个产品经理,用来记录用户都打开了哪些页面,X了哪些按钮,停留了多长时间。

埋点可根据开发方式与埋点位置分为两类,先是开发方式最常见的一种是代码埋点,即手工埋点,顾名思义是研发将用于X用户行为的代码提前手动埋到触发该X的代码中。

这种传统且常见的方式优点和缺点都极其明显,优点方面即可以自定义进行数据采集,想采多少就采多少,想采什么数据就采什么数据,哪怕是脑洞再大的产品经理只要是提的数据需qiú合理,原则上都可以满足并最终统计到想要的数据。

但同样的缺点就显而易见了,这种手动人为的方式就会受到整个APP发版liú程的X,即不管是iOS端还是Android端每次升级都是要发版的,而每次发版都是封装好当前这版本的代码,如有变动只能更换提交到各大应用商店的安装包,如果频率过多负责渠道的同学定会提着40米的大砍dāo来找发版产品经理了。

代码埋点一旦存在问题进而会引发什么问题呢?

试想新功能上线后老板某一天突然找到你要新版本的数据,这时你找研发要埋点信息但对方告知你没有埋上或者埋点信息异常,听到这句话产品心里肯定凉半截,没fǎ交差了。

如非极其重要的数据只能眼瞅着等待下一个发版周期才能统计新功能的数据了。此外,liú程上也会占用一定的人力,这点在后面的埋点liú程中会细讲。

当一种cāo作方式有它存在的jú限性,随之就会有其他更便捷高效的方式出现,毕竟事物是发展的,没错,近几年一些第三方数据平台或诸如bat这种XX已经想出一种可视化埋点方式

——通常是指X设备连接用户行为分析工具的数据接入管理界面,对可交互且交互后有效果的页面元素(如:图片、按钮、链接等),直接在界面上进行cāo作实现数据埋点,下发采集代码生效回数的埋点方式。

这种埋点方式极大的提高了人力成本,想想传统的手工埋点方式需要产品给研发提埋点需qiú,研发需要在代码中写X听的代码,产品上线前还需要验证。可视化埋点类似于前端网页的形式,实时交互降低人力成本和出错成本。

既然可视化埋点这么好为啥并没有完全普及或者成为各大XX的主liú埋点方式呢?问题就在于既要轻量级就没fǎ完全自定义,对于一些基本的记录某个页面的展现和按钮X可能没问题,但是面对一些复杂的数据需qiú时这种方式便没辙了。

比如需要区分来源的数据需qiú,带各种参数的需qiú,需要和后端交互的数据需qiú就不太适合可视化埋点方式。

所以总结来看可视化埋点虽然很美好但仅限于一些简单的纯客户端埋点统计,在复杂的数据采集需qiú面前行不通且准确性较低,这也是影响它普及的最大因素。

除了可视化埋点还有一种无埋点方式,也叫全埋点,即事先尽可能收集所有控件的cāo作数据,然后再X界面配置哪些数据需要在系统里面进行分析。

相比于可视化埋点这种半自动化模式,全埋点不仅继承了可视化埋点的优点,同时解决了手工埋点和可视化埋点共同的一个缺点即数据回溯。

比如产品想要看某个按钮的数据,可视化埋点只能做到从此刻以后的数据,在这之前的数据是没有的。

但全埋点只要在一开始封装的SDK就部署在代码中即可以保留整个时间线的数据,做到真正的所见即所得,XX某一控件区域便能看到该区域的X所有数据。

但全埋点也继承了可视化埋点的所有缺点,所以这种的埋点方式同样也无fǎ做到全面普及。

上面说的手工埋点、可视化埋点、全埋点是指按照开发方式划分的,按照埋点位置还可以分为客户端埋点和X端埋点。即上面三种埋点方式都是在客户端实现的,而有一部分数据是可以直接XX端去埋点并上报所有数据。

比如统计某款社区产品每天的用户发帖记录,除了可以直接在客户端埋点统计,也可以直接提交至X端的数据量级。客户端埋点和X端埋点优缺点又是什么呢?

对于客户端埋点的优点和缺点基本上就是上面介绍的那些,这里相比于X端埋点存在的另一个缺点是数据上报有延迟且会存在漏报的情况。

而X端埋点的优势便是数据上报无延迟,可以实时获取到数据,且整个cāo作较客户端更简单便捷,缺点方面自然是没fǎ统计纯客户端的数据,比如不需要跟X端发生交互的用户行为。

此外数据的收X依赖网络环境,这也是为什么同样的统计目标一般X端和客户端统计的数据有些许偏差。

这里正是因为网络质量的问题影响了X端的统计。比如用户提交某个数据,在客户端层面用户已经完成了这个行为,但网络质量不jiāX端可能就没有采集到这个数据。

以上关于埋点的原理介绍和分类就已经说完了,下面开始埋点相关角sè分工及埋点需qiú的liú程,这里主要讲的是当前主liú模式的客户端手动埋点liú程。

埋点需qiúliú程中包hán的角sè如上图,包括产品经理、研发、测试、X智能和数据平台。

  • 其中PM作为埋点需qiú的发起方,跟产品功能需qiú一样全liú程跟进;
  • RD的主要工作是开发埋点功能,即在代码中添加X用户行为的代码。但在不同的Xliú程中有些RD还承担定义埋点名称和维护埋点资料的工作;
  • QA一般承担着测试埋点功能的工作,即测试某个点是否埋点正确。但有些XQA并不承接这个工作,那这个验证的工作自然就落在了PM身上。
  • 当前面liú程走完,埋点跟随产品功能一起上线后PM就会跟BI同学提出数据需qiú,由BI同学将数据可视化。
  • 至于平台这个角sè需要看X的在数据这块的重视程度,虽然埋点liú程需要以上角sè但并不意味着每家X的埋点liú程都是这样,具体来说分为规范性liú程与非规范性liú程。

「埋点liú程」

首先是非规范性liú程,比如一些创业X和小X因为X处于发展初期或X对数据的依赖性不是太强的时候一般整体的埋点liú程就会随意一些。具体liú程参见下图:

如上面这张图当X无埋点工具或数据平台时,埋点liú程则相对人工化。

如果X无BI这个岗位,一般由PM在需qiú文档中提出埋点需qiú,在技术评审时提出自己的埋点需qiú,由RD在开发中自定义埋点名称和参数(有些X是由pm定义并维护埋点资料),并将这些信息埋点代码中,并在X某一平台维护埋点资料,以便后续使用。

接着是QA测试环节,一般埋点的逻辑性较为简单,所以有些XQA并不介入埋点测试,上线前直接由PM进行埋点验收。

这种人工式的埋点liú程存在着较大的数据风险,一是埋点名称不规范不X,对于一些参数的定义也较为随意,这样就容易造成后续的埋点名称冗余且混乱,不利于后续的X管理;二是liú程中诸多环节均为口头沟通PM验收较为繁琐,某个版本漏埋点或埋点不正确的风险大大提高,对于数据的及时X带来较大隐患。

一般随着X的扩大和liú程的规范,数据平台的建立将大大的提升埋点liú程的规范性、时效性。具体参见下图:

相比于无数据平台的埋点liú程,一旦有定制化的数据平台,埋点liú程将变得完全不一样。

此时,仍是PM提出埋点需qiú但是整个liú程将收归至线上,即PM将高保真的页面记录在数据平台,并在数据平台自动生成埋点名称及任务X给对应的RD,RD将根据由平台定义好的埋点名称和参数写入对应的代码中。

此外数据平台还支持测试埋点,即PM可X数据平台在发版前安装测试包测试埋点信息是否存在和正确性,极大的降低了风险性。

后续的数据可视化也直接在数据平台查看,甚至能查看实时的数据大盘,诸如某个时间点的曰活,订单量等。

拥有定制化的数据平台在埋点名称的管理和维护方面将更加灵活且自动化,特别是对于拥有多条X线的X来说更是必不可少。

这里就不得不多提一些,对于多X多终端的X来说,数据的整理与维护工作至关重要,特别是对于现在的X发展形态来说,数据的精细化可视化是指导X规划和X决策的重要参考。

那这样在埋点liú程中埋点名称的命名规则就需要考虑X、终端、页面的唯一性和可辨识度。

此外对于一些参数的定义也不再随意,应包hán全jú通用参数即所有X所有终端所有埋点都需要X携带的参数。

比如一家教育X中年级、学科这种应该就属于全jú通用参数,这样在统计多X多终端时才能保证参数的X性;X公共参数是指某一X下多终端所有埋点携带的参数需要一致;X自定义参数即部分参数可仅属于某一X下某一模块独有的信息,可使用自定义的方式命名参数,无需考虑其他终端其他X。

当功能上线后PM需要某些数据时可根据X需要向bi或数据分析师提出数据需qiú,具体的数据呈现方式也可根据数据的重要性及查看频率决定是建立数据报表长期监控还是一次性的将数据导出以Excel等形式展示。

在提出数据需qiú方面也应以邮件的形式明确需qiú背景、所需数据时间范围、数据统计逻辑和预期给到时间等。

「答疑」

以上便是埋点的全liú程,每个X的实际情况可能会有一定出入。但PM作为数据需qiú的发起方应充分了解埋点的liú程,尽量降低各环节因不规范性带来的风险性,更好的让数据X于工作。

以下还有一些关于数据方面的常见问题:

Q:数据的全liú程有哪些环节?

A:上面的liú程中更多是埋点的Xliú程,真正的数据liú程包括数据采集、数据上报、数据存储、数据加工、数据输出等几部分。

Q:一般可以采集到哪些数据?

A:按照采集位置可分为客户端「交互行为」数据和X端「接口请qiú」数据。客户端数据包括页面的展现、控件X、停留时长等,X端数据包括请qiú状态、请qiú结果等。

Q:哪些原因会导致统计的数据不准确?

A:首先是数据源异常,其中包hán功能变动后未提出埋点需qiú、埋点需qiú不明确不完整、沟X程中需qiú方和执行方理解有偏差等;同时在代码层面可能会出现埋点位置错误、参数缺失,或者因为代码调整导致原有埋点代码丢失错位等;

其次是数据上报异常,包括上报数据格式不规范,没有按照规定格式上报或者各X的埋点数据格式不X;因网络质量不jiā和X器压力过X导致数据上报延迟;数据上报地址的错误也会导致无fǎ准确统计数据;

最后数据输出层面也会影响数据的准确性,比如数据需qiú未将统计逻辑考虑周全,需qiú方与统计方沟通理解的偏差性,数据产出延迟等。

Q:数据有问题,可以找哪些同学解决?

A:首先是与bi或数据分析同学确认数据上报和产出是否存在延迟问题,其次再确认统计方式与自己的需要的数据统计逻辑是否一致,如若不一致则由数据产出方修改SQL语句即可;当统计方式没问题时再去和rd同学确认埋点信息、参数信息在代码中是否埋上且位置准确,上报地址否准确等。

Q:在哪些环节可以避免数据问题?

A:产品、运营、研发加强并培养数据意识,更深入了解并提升数据相关能力。产品、研发、数据分析等同学在埋点liú程中保持较高的严谨性和专注度,避免在执行层面犯低级错误。全liú程中各环节各方负责人均需加强自测和验收,在需qiú上线前及时发现问题。借助工具的能力,将诸多liú程从线下人力迁移至线上liú程,减少因人力维护和输入输出导致的一些错误。

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 产品经理需要了解的埋点知识 https://www.xiongfawang.com/4185.html

常见问题

相关文章

产品经理需要了解的埋点知识-海报

分享本文封面