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

时间:2019-11-08 来源:www.yjgby.cn

2019年10月21日,每个人都是产品经理。我想分享

为了进行更有针对性、更科学、更客观的产品优化迭代,产品经理将进行产品嵌入,希望通过分析报告的数据获得某些趋势和特征的信号或信息。最后,这些信息将用于产品优化决策 本文对产品经理需要知道的隐性知识进行了梳理,以供大家参考和学习。

产品经理的三种正常工作条件是写文档、交流和阅读数据。 毕竟,在如此努力地编写需求文档并冒着降低需求的风险之后,我终于说服自己注意到,上线后,我在研发面前吹牛的功能在数据方面是否发生了变化。

此外,产品经理工作的本质是发现问题、分析和解决问题、编写文档或与后续项目沟通。最终目标是解决问题。如何证明这个问题得到了解决?

除了缺乏对问题的背景反馈之外,最直观的事情是负面数据减少了,正面数据增加了

除了实现用户价值和解决用户的各种问题和痛点之外,产品经理的价值还需要实现商业价值。毕竟,老板给的OKR既不会让R&D回来,也不会测试回来,唯一对结果负责的人就是产品。

该产品如何证明你可以从你日以继夜的努力中获得一些东西?

数据是让老板满意的最有效的方法。毕竟,对于一个企业来说,每天能够从10w生活到100w是一个完全不同的概念。直接商业价值,如销售收入从0.4%转换到4%,可以使企业真正生存下来。 数据来自哪里?今天,让我们来谈谈掩埋遗址的整个过程。

如前所述,如果产品经理想要查看数据,他们需要相互合作。由于他们需要数据,除了用户的行为会在数据中得到反映之外,他们还想直接看到数据之间是否有一座以上的山和一片以上的海(在最近看到张嘉佳的《云边的小卖部》鸡汤文本堆积着各种修辞之后,他们不禁会有节奏)。毕竟,他们也看不到每个用户的使用情况。 那我该怎么办?“你为什么会处于唐僧这样的境地”

我们需要在这里做全方位的研发。他们不仅需要通过飞行和敲击将键盘上的字母瞬间转换成代码,然后将草图上难看的功能概念转换成他们能触及的实用功能,还需要继续用手指编写监控用户行为的代码。

R&D可以监视用户的行为,但毕竟这些东西还在代码中。可视化效果确实有点困难。在这里,需要数据分析的学生开始发挥作用。除了要求R&D提供数据外,产品经理还需要要求学生提供数据,这些学生需要数据分析来可视化监控数据,以便他们能够直观地轻松看到自己想要的结果。

它说了这么多,那么让我们正式说出每一步~

“埋葬的原则和方法”

首先是关于埋葬点的概念,毕竟,理解该做什么的原则是非常重要的。

埋藏点是指捕捉、处理和报告目标事件的相关技术和实现过程,其主要目的是实现用户对产品行为的监控和数据收集

具体来说,在定义的事件代码中植入监控代码,一旦事件被触发,用户将报告在要报告的埋点代码中定义的字段信息;一般来说,每个用户都被指派一个产品经理来记录用户打开了哪些页面,点击了哪些按钮,以及在使用自己的产品时停留了多长时间。

根据开发方法和埋设点的位置,埋设点可分为两种类型。首先,最常见的开发方法是代码隐藏点,即手动隐藏点。顾名思义,研发人员将用于监控用户行为的代码手工嵌入到预先触发事件的代码中。

这种传统的普通方法的优缺点是非常明显的。就优势而言,您可以自定义数据收集,收集任意数量的数据,以及收集任意数量的数据。只要数据需求合理,即使是拥有最大大脑空洞的产品经理也能满足并最终统计出所需的数据。

然而,同样的缺点是显而易见的。这种手动方法将受到整个应用发布过程的限制,即iOS和安卓将在每次升级时发布,每次发布都将封装当前版本的代码。如果有任何更改,只能替换提交给主要应用程序存储的安装包。如果频率太高,负责该频道的学生将带一把40米长的弯刀给分销产品经理。

如果嵌入式代码有问题,会发生什么?

想象一下,在新功能上线后的某一天,老板突然发现了您想要的数据的新版本。这时,你需要为研发寻找一些信息,但是对方告诉你没有嵌入信息或者嵌入信息异常。听到这句话,产品肯定会觉得冷,无法工作。

如果数据不是非常重要,您只能观察并等待下一个发布周期来计算新函数的数据。 此外,该过程还将占用一定的人力,这将在以后的嵌入过程中详细讨论。

当一种操作模式有其局限性时,将会有其他更方便和有效的模式。毕竟,事情正在发展。是的,近年来,一些第三方数据平台或bat等互联网公司已经想出了可视化嵌入方法

,这通常是指通过设备连接用户行为分析工具的数据访问管理界面,并直接在交互有效的页面元素(如图片、按钮、链接等)上实现数据嵌入的嵌入方法。)在界面上交互后分配有效数量的收集代码。

这种嵌入方法大大增加了人工成本。考虑到传统的手工嵌入方法要求产品为R&D提供嵌入点,R&D需要在代码中写入监控代码,产品上线前需要经过验证。 视觉嵌入点类似于前端网页的形式,实时交互降低了人工成本和错误成本。

既然视觉嵌入这么好,为什么它还没有完全普及或者成为主要互联网公司的主流嵌入方法?问题是如果你想变得轻量级,你不能完全定制它。对于一些基本记录来说,显示页面并点击按钮可能不是问题,但是当面对一些复杂的数据需求时,这种方法是无能为力的。

例如,需要与源和各种参数区分开来的数据要求,需要与后端交互的数据要求不适合可视化嵌入方法。

因此,综上所述,虽然视觉隐埋点非常漂亮,但它只限于一些简单的纯客户端隐埋点统计,这在复杂的数据采集需求面前是不可行的,而且准确度低,这也是影响其普及的最大因素。

除了可视化埋点之外,还有一种没有埋点的方法,也称为全埋点,即尽可能提前收集所有控件的操作数据,然后通过界面配置需要在系统中分析哪些数据

与可视化埋点的半自动方式相比,全埋点不仅继承了可视化埋点的优点,而且解决了人工埋点和可视化埋点的共同缺陷,即数据回溯。

例如,如果一个产品想要查看某个按钮的数据,那么从现在开始,可视化嵌入点只能处理数据,但是在此之前没有数据。

但是,只要在代码中部署了开始打包的SDK,完整的嵌入点就可以保留整个时间轴的数据,从而实现真正的所见即所得(WYSIWYG)。通过点击控制区域,可以看到该区域的所有历史数据。

但是,所有埋点都继承了可视埋点的所有缺点,所以这种埋点方法也不能完全推广。

上述手动埋葬点、可视埋葬点和全埋葬点根据开发模式进行划分,也可以根据埋葬点的位置分为客户端埋葬点和服务器埋葬点 也就是说,以上三种嵌入方法都是在客户端实现的,而一些数据可以直接嵌入在服务器上,并且可以报告所有数据。

例如,如果您计算某个社区产品的每日用户发布记录,您不仅可以直接将统计信息隐藏在客户端,还可以直接将数据提交给服务器 客户端嵌入点和服务器端嵌入点的优缺点是什么?

客户端隐藏点的优缺点基本上与上述相同。与服务器隐藏点相比,另一个缺点是数据报告延迟和遗漏

服务器嵌入点的优点是数据报告没有延迟,数据可以实时获得。整个操作比客户端简单方便。缺点是,与不与服务器交互的用户行为相比,自然不可能计算纯客户端的数据。

此外,数据的收集将取决于网络环境,这也是为什么相同的统计目标(一般服务器和客户端)在统计数据中存在一些偏差。

这正是因为网络质量问题影响了服务器的统计数据 例如,如果用户提交了某些数据,则用户已经在客户端级别完成了该行为,但是网络质量差的服务器可能没有收集到这些数据。

以上埋设点的介绍和分类已经完成。以下是埋设点的角色和要求的划分过程。这里的主要焦点是当前主流客户端手动埋葬点流程。

嵌入式点需求流程中包含的角色如上所示,包括产品经理、研发、测试、商业智能和数据平台。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

此外对于一些参数的定义也不再随意,应包含全局通用参数即所有业务所有终端所有埋点都需要统一携带的参数。

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

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

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

「答疑」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

作者:我呀way ;欢迎来撩~

本文由