埋点功能就是数据分析的力量吗

在日常工作中，很多时候我们都会用到数据分析的方法，优质的数据分析能够帮我们快速的找到问题所在；产品经理在日常工作中也需要对数据分析的方法有一定的掌握，更好的提高工作效率；本文作者分享了关于数据埋点和日常数据分析，我们一起来了解一下。

数据反馈，不仅能验证我们的产品是否符合市场的预期，而且还能为我们优化产品，迭代产品提供需求，建立产品的优化飞轮。

因此，数据分析是形成整个产品工作闭环中，必不可少的一环。

去年我们团队上线了一个新的产品，上线后，由于一直招不到合适的数据产品经理，因此团队让我先暂时支持下数据产品的基础工作。

于是，在这期间，我成了半个数据产品，在支持了一段时间的数据工作后，也建立了对数据的基本认知。

所以今天，我先从埋点开始，介绍下数据埋点工作过程中要了解的要点，同时补充介绍下，在数据分析工作中，可以直接应用一些分析框架和工作方法。

一、数据埋点与事件管理

1 什么是埋点、事件、参数

埋点，是通过在程序中植入代码的方式，记录用户在软件（web、app、小程序）上的 *** 作行为的技术手段。

事件，是记录用户在软件中 *** 作行为的标签，如，用户在首页的曝光事件、按钮的点击事件等。

而在事件中，为了进一步区分事件的范围，更好地进行数据分析，会增加事件的“参数”，用来框定某个范围内的数据。如，时间参数、城市参数，就是用来筛选某个区间内事件上报数据的。

假如，我们要看到3月20日的产品首页曝光人数。

我们首先可以在首页中增加带有“时间”参数的“曝光”事件埋点。

在查询时，可通过代码在数据库中找到“首页曝光”这个事件，并在时间上选择“昨天”这个时间参数。

就可以得到昨天在首页曝光的用户数。

2 事件分类

事件是通过用户在软件中留下的痕迹，来进行统计和上报的。

因此，从用户痕迹获取的维度上来看，事件可分为：基础事件和行为事件

1）基础事件是用户的属性标签，可用来建立用户画像的；如，用户id、城市、地址、年龄、经纬度、设备、ip地址、运营商、网络等信息，都属于基础事件。

2）行为事件就是用户在软件上的行为标签；如，曝光pv/uv、点击pv/uv、停留时长等，都属于行为事件。而根据用户 *** 作的行为，行为事件又可进一步细分出以下三类：

点击事件，指用户在软件中的点击，如用户在某个按钮、某个功能的点击，都记录为一次点击事件；曝光事件，指用户打开页面的行为，如用户在某个页面上曝光一次，记录为一次曝光事件；页面事件，指用户在页面中的 *** 作，如，通过统计A用户在B页面停留时长；

3 埋点的方式

介绍完事件分类之后，我们再来看下埋点的两种主要方式：

1）私有化部署

全部功能都自己开发，在代码中写入事件和上报逻辑，并搭建起相应的查询后台，埋点后，事件上报到对应的平台即可进行可视化呈现。

私有化部署的优势是：数据安全性高；且可根据业务需要，定制埋点逻辑；

但缺点也同样明显，就是不论是埋点开发还是可视化平台的搭建，所耗费的成本都比较高；

所以，一般只有大厂或相对成熟的产品，才会选择私有化部署的方案。

埋点就是在用户使用产品时记录下用户行为数据，以便后面对用户行为进行数据分析。比如说需要页面的浏览量，就需要对用户浏览页面这一行为进行记录，然后一个页面的所有用户浏览量相加，便可以得到这个页面的浏览量了。

1）埋点是为了进行数据分析，因此最好先明确数据指标或者是分析目的，这样能够保证自己想要的数据都能找到。

2）埋点可以事件为单位进行的，每一条埋点数据或者说是用户行为数据，记录了一个事件的发生。每一条事件数据需要讲清楚“ 什么人在什么时间、地点以什么方式完成了什么事情 ”，也就是who/when/where/what/how。

举个例子，以视频播放这个事件为例，视频播放其实就是用户播放视频这个行为，那么这个事件里就包含是哪个用户在什么时间、什么模块看了什么样的视频，如果需要投递视频播放这个事件，那么包含的字段就有：用户ID/时间/在APP的位置/视频ID/视频属性。

比如像点击、浏览、曝光这些行为便可以用前端埋点，主要是发生在用户与界面的交互；如果是电商中要统计下单成功这个事件，客户端是没有办法知道订单是否成功的。如果统计的事件里有需要用到后端的数据，也是要进行后端埋点的。

埋点数据是需要存储起来的，数据就会有它对应的字段。一般一条埋点数据需要记录：

事件ID、事件名（英文名、中文解释）、事件属性（属性英文名、中文解释、属性类型）、埋点形式（前端/后端）、事件触发时机（什么时候投递这个事件）

一个事件发生时，像用户ID、设备信息这些都是每个事件可以共用的，因此可以定义一些每个事件都可以使用的公共属性，比如可以定义：

像用户信息（用户ID、设备信息、网络信息、地理位置信息）、时间信息等字段是所有事件都会用到的，因此可以把他们当做所有事件的公共属性。

事件类型分为点击事件、曝光事件、页面停留事件等，在设计事件时，可以按产品的功能模块、点击事件、曝光事件等维度进行划分。比如说现在对西瓜视频进行埋点，从功能上可以划分为视频相关的事件、视频互动（评论、点赞、分享等）相关的事件，一些较为简单页面可以直接统计点击和曝光事件。

视频相关的事件包括有视频播放、视频曝光这两大类。

西瓜视频首页视频播放过程可能会有：

因为视频播放中可能会出现各种情况，此时最好列出所有情况，尽量考虑到每种情况下播放时长应该怎样进行计算。关于视频曝光事件这块，后面如果在数据计算时，会计算曝光事件总和作为曝光量，如果是小视频推荐出视频就算曝光了，而且这块可能出现快速滑走的情况，为了防止曝光时间过短，可以设置有效曝光时间，这样计算曝光量时我们可以控制什么样的曝光用来计算曝光量。

对于简单的页面曝光，可以进行简单的罗列；如果页面点击事件比较简单的话，可以用一个点击按钮属性来区分不同的点击按钮，但是如果点击事件比较复杂，本身可能就带有比较多得事件属性，或者这个点击事件很重要时，还是建议单独写一个点击事件，便于后面的分析。

一个APP里面有很多的埋点事件，而且都是不断迭代的（其实我就想说写完太累了，哈哈哈哈），所以就大概写一点了，大概形式就差不多了，总而言之，埋点还是得根据数据的需求来，比如数据需求想分析用户关注行为，就可以把关注单拎出来做一个事件集合。

产品经理必须随时全面而准确地了解自己产品的各项数据，否则只能凭着感性在规划和设计产品，容易犯错误。因此，看哪些数据，如何统计和分析数据，如何进行数据埋点，都是产品经理必须要掌握的知识和技能。

如果你对此还不甚了解，可以通过这篇文章，快速地知道一个大概，然后待到在工作中学习和实践时，就更加容易上手了。

首先简单讲一下什么是数据埋点。数据埋点通常是指开发工程师基于业务、运营或产品经理的需要，在产品前端程序中植入相关代码，以获取用户行为等数据的一种技术手段。

对开发人员而言，埋点需求同性能需求一样都属于非功能性需求，它们与功能性需求一起组成了产品需求。

网页中最常见的埋点方式是通过JS代码来实现的。

比如为了统计用户的点击事件，那么在每个链接或按钮处，都增加一段JS代码，用户一旦点击，无论页面是否有跳转、刷新等，都悄悄地请求了服务器，也就把一大堆信息传给了服务器存下来，包括用户的IP地址、地理信息、浏览器参数、点击的对象、时间等等。

又比如为了统计曝光事件，先定义好何为有效曝光（例如完成加载、渲染并进入用户视界），然后在有效曝光发生时，执行一段JS代码，把相关信息传输到服务器。

如果是手机APP或智能设备，则不同于网页主要使用JS代码的方式，它们往往被植入SDK（Software Development Kit，即软件开发工具包）来实现数据埋点。同时，为了避免频繁连接网络上传或下载数据，通常会将数据先存储在手机本地或智能设备中，等到一定的时机，再一次性同步至服务器。

一定要记住的是，数据埋点只是数据统计和分析的一种技术手段，并非所有的数据统计都必须要有数据埋点。

比如网页事件。在通过>

数据需求也就是我们要如何去通过数据评价该模块的版本效果，以 及可以采集哪些数据去做用户特征分析。

不同的产品业务需求不同，比如运营更关注活动上线后的运营情况，产品则关注功能的使用情况等，因此需要根据各业务需求设计数据分析指标，以满足各业务对数据分析的需求。

下面是京东排行榜页面数据分析指标，可参考：

用户路径 ：京东首页→排行榜入口→排行榜页面→商品详情页→购物车→支付订单→跟踪物流→收货确认→商品评价

事件设计就是要采集用户行为数据，首先要根据业务分析需求明确采集的目标行为，进一步搞清楚应该在哪些地方埋什么样的点，最终输出的成果就是埋点需求文档。

事件设计可按照4W1H（“WHO”、“WHEN”、“WHERE”、“WHAT“、”HOW“）的原则进行事件的设计和定义。

what就要看业务行为了，举了上面两个例子，并引入了“事件”和“属性”两个概念，事件是指具体的行为，属性是指行为相关的一些信息，如商品下单这个事件：

这个要根据不同的业务需要，在埋事件的同时，增加必要的属性，以便深入分析数据。

一 埋点还是埋雷？数据埋点的五大“坑”

在接触过上百家头部客户中，诊断和参与了数百次的数据体系搭建工作。几乎80%的开发者都没有科学的埋点规划，只采集显性数据，而更深层的与事件、参数相关的隐性数据，都没有采集到。埋点规划并不难！但为什么大部分企业都做的不太好？埋点规划需要整合产品、运营、技术和业务等跨部门的需求，运营同学不太懂技术、技术同学不太懂业务、产品同学不太懂埋点。

埋点的常见的问题有那些呢？

遗漏 ：指的是埋点采集不全面，有可能重要的数据并没有采集到，会对数据分析造成比较直接的影响，出现这个问题的原因是前期数据分析需求不清晰。

 

杂乱 ：前期并没有进行事件结构化的设计，想一出是一出。通常是想到一个需求，就把这个需求提供给技术进行埋点。例如：某一个位置或者某一个功能的点击行为，就当做一个事件进行采集，看上去采集和查看很容易，但随着时间跟需求的增加，当采集了大量零散的事件之后，需要在统计工具中通过分组分析时，就会比较麻烦。

 

低效： 在事件设计的时候，会去做结构化处理。但事件设计的参数逻辑会有问题，通常都是以大的页面这种框架的思维去进行设计。举个例子：部分客户在设计时，会按照页面的思路去进行事件采集，当产品结构产生变化时，原有事件调整概率会比较大，因为之前都是按页面结构去设计，页面的调整直接影响事件采集。

 

无用 ：指的是数据虽然采集了，但分析时根本用不上，这个问题主要有2个原因导致，一是前期需求不太清晰，另一个是之前的采集需求都是由不同人提出的，由于中间人员变动，很多采集需求就不清楚了，并且也不敢下掉，因为并不清楚这个事件是否还有人使用。

 

复用： 指的是事件重复采集，或者是需求重复，这个同样是与多个人提需求有关，并没有一个人去做整合管理，或者是说，没有一个工具去帮忙我们做管理。

  如果想要避免这些坑，就需要坚守五个原则：

需求清晰 合理设计 实施规范 结果可验 规范管理

很多人想要从事产品，或者老板自己创业要亲自承担产品一职，但他们对产品这个岗位的认识却不明晰，有的以为是纯粹的画原型，有的是以为做项目管理跟踪项目进度，有的是做 竞品分析 给老板看。实际上，这些都不是 产品经理 的核心和重点。在较为成熟的企业，因为产品的壮大和人员的增多，为了便于协作和沟通，岗位会细化的很清楚，如产品经理、 交互设计 师、 UI设计 师、 用户体验 分析师、数据分析师、运营等等。但是创业型公司中产品经理往往都是身兼数职， 创业公司 追求的是效率最大化、成本最低化，根本没精力将岗位分的那么细致。下面我以一个创业者的视角或者说负责一个产品项目的产品经理角度出发，来审视整个过程，看一个产品从无到有，产品经理需要哪些事情。

做任何东西之前，首先要考虑其背后的用户需求、商业价值、技术难度。只有用户有需求，你的产品才会有人用；只有其商业价值成立，才能为企业带来利润，毕竟企业最最基本的目标就是要盈利；只有技术上的总体评估是可行的，整个项目才可被执行。现在的 互联网创业 ，大家都在追求”快“，比如2个月融资，4月用户过百万，3年后 纳斯达克 上市。但是这都是大家看到别人创业成功的表象，殊不知做任何事情的前提是，你得了解你在做什么，诚然，不排除哪些胆子大运气好随便干就成了的，但那只是个案，不值得深究。

在项目的执行过程中，我们经常陷入一种情景，就是一堆人在一块，讨论的氛围可谓是情绪高涨，A说这个地方的按钮不行，B说这个地方应该像人家APP那样做，C又说你们都不对应该是这个模块不要换成这个云云。经常参加这种讨论，会无比的耗费时间和体力，动辄好几个小时过去，但一散会，发现什么结果也没得出来。多数情况下，一定是产品定位出了问题。执行的人一定要清楚的明白产品是用来干什么的，给什么人用，才能正常的去讨论具体细节。如果热血沸腾、蹬鼻子上脸的的讨论了好久，发现没结果，发现会议的讨论跑偏了，不妨回归本质，想想我们的产品定位是什么。

产品定义： 产品定位包含两个大的内容一个是产品定义，另一个是需求定义。产品定义要分析的内容包含产品的使用人群、主要功能和产品特色。

举例，你现在要创业搞一个移动端招聘APP取，作为产品经理首先应该干什么？中国每年的就业人口非常庞大，行业也各种各样，那你就有要想，你的产品是要给什么样的人提供服务，你如果想服务所有行业的人群那是不可能的，首先一个小公司去整合这么多行业招聘信息本身就非常困难，另外并不是每个行业的人对互联网的接受程度那么高。

通过数据分析和调研，发现现在国家鼓励创业，创业的高峰期必然产生大量的人力需求，尤其是现场几乎说到创业没有哪个是跟互联网无关的，而且从事互联网的人对于APP的接受程度也很高，至少都愿意尝试。所以你把互联网这个行业的从业人群作为你产品的使用人群。

当你分析完其他招聘类APP后，你发现这些APP有很多问题，比如我就是要找北京西二旗那边的工作，但是很多APP目前都是没位置筛选；虽然可以海投，但是得到的反馈的寥寥无几；能够了解的企业信息太少；在投递建立前，作为求职者希望知道这个公司的老板是谁；现在都互联网时代，电子简历完全可以了，为什么每次招聘还需要招聘者自己打印简历，要知道打印简历对于求职者来讲并不是很方便，因为随时会改动，这对求职者非常不方便。所以你打算做这个APP，他的特色功能就是：

1、岗位支持企业所在位置分类；

2、招聘方应该时时给予求职者反馈；

3、取消纸质简历。主要功能就是招聘。

现在我们给APP取名叫做飞鸽招聘。

需求定义： 需求定义的分析包含目标用户、使用场景、用户目标三个方面。目标用户是什么类型的人会用你的产品；主要功能是指你的产品是用来干什么的，是工具是社交还是其他；你的产品相对于其他市面上的产品有什么不同的地方，这就是产品特色。

刚才明确了APP的适用人群、主要功能和产品特色。市面上的招聘APP，有的是做猎头的专门针对于希望跳槽的，你的APP的目标用户是谁？基于特色功能分析和用户痛点，分析出出产品的目标用户是那些有想在具体位置找工作的人，比如已经定居北京后沙峪的人，希望工作在望京；当你刚刚搬家到回龙观时，此时你面临着换工作，你可能会倾向于找西二旗那边的工作。

以上就是所有产品定位的内容。这些完成之后，紧接着的就是竞品分析和用户调研，一方面这是对我们的需求进行一定的验证，另一方面也是我们直接接触用户的一个机会，看用户存在什么需求。

早期需求筛选是个非常苦逼的事情，如果产品经理自己就是老板，自己心里很清除还行，如果不是很容易陷入海量的需求中拔不出来，讨论着讨论着就跑偏了，讨论完之后好像什么功能都需要，这个功能有用，必须加；那个功能太好玩了，用户肯定有趣。这话总完全凭个人主观臆断的东西，往往都是当时听起来貌似合理，但事后却经不起推敲。所以我们需要始终把握住我们的产品定位和优先级，万不可盲目的在这个地方做很多无畏的牺牲和奋斗（少做不经思考的、拍脑袋的、不经过大脑的决定）。

需求记录表：

早起需求筛选期间，会出现很多这样或者那样的需求，有些我们不能立马做出判断说做还是不错，这些点子有可能以后会成为我们产品迭代的启发点，也会给产品的发展带来更广的思路。做好管理，尊重每一个人的想法，在出现模棱两可时，记录下来，对会议的推动和进展会有很大的帮助。

市场需求文档 和 商业需求文档 ，一般在大公司会得到比较成熟的体现。小公司往往多数都是老板自己决定，老板可能不会搞这样或者那样的文档，但他自己肯定会去做基本了解，或者本身自己就很了解某个行业。这两个文档并不是多余的，也不是累赘，如果在项目启动前，能够花一定的时间去深入了解行业和用户是非常必要的。具体文档细节在这里不做阐述，网上有很多可以去借鉴的。

作为不是技术出身的人，就不再这里转笔了。尊重开发人员，和开发相处融洽一点，会对产品的推动非常有帮助。

在前文中已经给大家讲了项目启动前应该做的三大块1、需求；2、商业；3、技术。在这些准备工作整理完之后，接下来就是执行，执行过程中不像之前需要考虑的那么宏观，但需要你足够的细心和耐心。

需求产生了之后，紧接着产品人员就可以产出需求文档，需求文档对接下来交互设计（创业公司往往产品经理会担任）、UI设计起着关键性的作用，当然在需求闻文档产生的过程中，如果有专职的交互设计，在需求阶段最好和产品人员一起来探讨需求文档的细节，这对于交互设计自己理解整体的需求有帮助，也对他进行原型设计和撰写交互说明有很好的帮助。

需求文档 大致包含的内容会有如下几个方面：

背景描述 ：为什么开展这个项目？解决用户什么问题？会有多大的价值？大致就是把项目启动前做的功课进行一下总结说明，务必精简明了。

用户画像 ：对用户特征进行虚拟说明，阐明用户情况。

项目时间规划：什么时候出来原型？什么时候出来真实设计稿；什么时候进入开发？什么时候开始测试？什么时候开始提交应用商店？ 这些都需要明确出来，不然如果没有时间概念，什么事情都会拖拖拉拉，没有紧迫感。

信息结构图 ：APP的内容组织结构。下面是举例，简单的给出微信的基本结构。

任务流程图 ：对于APP中的大功能，把用户从开始到结束的整个过程梳理出来，把各种可能性考虑进来，否则之后如果开发碰到问题了问你，你还得重新考虑，更可怕的是开发不问你直接就开发了，而结果还不是你想要的。下面以一个简单的登录为例：

需求说明 ：把每个 *** 作的条件和结果说清楚，如果能够用文字说清楚的就用文字，说不清楚的最好用。可能有的人会说，这个时候还没有线框图，怎么解释啊。这个并不矛盾，早起的需求文档是用来给交互看的（再次强调，创业型公司的产品可能会兼着交互），交互设计师再根据你的功能结构和流程梳来设计线框图和高保真的原型图。

数据埋点 ：把后期需要查看的数据列成清单，比如说这个按钮的点击率，这个页面的打开率等等，这个时候需要和运营多交流，对需要做埋点的地方理清楚。这对于产品上线后的数据分析很有帮助，数据也可以辅助产品功能的迭代。

需求整理完成之后，接下来大致要进行的就是线框图、页面流程、高保真原型图和交互说明的设计和产出。高保真原型是具体情况来定，有的公司有要求，有的没有。

力求简单清晰的表达出每个页面的视觉效果，这里最好不要加入交互，也不要搞的五颜六色，最好是黑灰色。每个情形就是一个页面，把各个情况用页面分别表达出来，一方面你会更加清晰APP整体的界面数量，另外设计也会更加清楚你想要什么，否则加入了交互，设计也不知道怎么点，你还得解释半天。

比较类似之前的信息结构图，页面流程图这是用各个页面来做连接，视觉上更加清晰各个环节的衔接和跳转。

对交互的要求会更高。需要比较完整的展现各个功能之间的交互动作，另外在视觉上尽量还原真实产品的样子。（关于Axure，可以学习金乌的课程，很不错，很多人觉得讲的太罗嗦，但是你认真看下来还是很有收货的）

我个人觉得，交互说明和高保真原型有重合之处，如果做了高保真，那么多数的交互动作基本上都可以展现。但是有些地方的交互动效是软件无法搞定了，这个时候就需要你用交互说明了。

如果文字和都不要说明的就直接用纸片来模拟。不要小看这种方式。

这里做交互标记的工具推荐几个给大家：mac电脑果断是sketch了；windows下有snagit、圈点、FScapture，另外viso也可以标注。

一般情况下，交互设计师讲线框图交给设计师，设计师就可以开工了。这个过程，交互也要多和设计去沟通，毕竟UI也会有自己的专业度，她会有自己的设计见解，这很正常。

设计产出了，交互的工作也做完了，该去交给项目经理执行了，这个身份目前来看那只有很大的公司里才会有，一般情况下是由产品经理直接兼任了。这里需要提醒的是，在执行前，各种相关的规范要先建立起来。比如：

这里全是我个人的经验，做好这些，会对以后安装包的管理会有极大的帮助。我们当时把搭建了一个开发者环境，这个环境下的APK、API文件只能在局域网类使用，在这个环境下可以任意折腾和测试，不会影响到已经上线的应用。

开发者环境下打包的安装包图标和命名要和线上环境下的应用区别开。以后在续测试时就不会因为各个版本搞的手忙脚乱。

421开发版：纯开发自己使用或者产品使用，其他无关人员一般情况下不会接触到这个版本。网络环境：仅特定网络环境下使用（需要技术人员搭建环境）。

422公测版：经过产品和测试人员的详细测试后，基本没有什么BUG了，就可以拿出来给公司的人使用，也算是上线前的稳定性测试。网络环境：仅在特定环境下可以使用（需要技术搭建环境）。

423商店版：准备提交到市场的APK、API文件。在经过开发版本、公测版的全面测试后，排除一切不稳定bug，此时打包的商店版仍然需要经测试人员的最后把关，最后一定要保证的是，准备上线的APK、API文件是经过测试人员的最后把关的，否则如果开发如果做了改动不通知测试和产品人员，上线后出了问题再改就晚了。

版本好号的管理，前期就要搞清楚，否则后面产品上线后，出现bug要改进，或者添加新功能后对老版本是否有影响，这个时候版本号管理的好就会起到很大的作用，一方面你可以随时找出之前上线过的apk、API文件，另一方面面对不断修改打包的文件不至于把自己搞混。

下面是我个人的意见，如哪个大牛有好方法可以分享出来。版本号始终是唯一的，是依次迭代递进的，不要为了上线时版本号好看就去刻意干扰版本号，严禁搞多套版本号。

测试须知：

UI、交互、产品在技术人员开发阶段，要多和技术人员沟通，最好是将大功能细化成小功能模块，每次做好一部分就通知相关的人进行检查，以免累计到最后问题过多修改动作太大。UI负责盯着开发是否按照自己的设计实现的，交互负责关注交互效果是否符合你的标准，产品负责关注各个功能的实现是否正确。

测试用例：好的测试用例能够有效的推进测试的进程，好的测试用例在于尽可能的把APP的各种需要测试的情况用人话描述清楚，这点就看你的文字能力了，测试用例写出来会交给测试人员来测，这也是他们评判APP是否达标的标准。

Bug管理工具：bugtags,bugclose等等，市面上有很多，多是免费的，即使是收费也不要在意那么点钱，借助bug管理工具能够有效的提高测试人员和技术人员的协作效率。

之前给大家介绍了两个部分，项目启动前和项目执行中。项目上线后，作为产品需要关注的事情有几个方面，一是APP数据，二是用户反馈，三是需求提取。

新增用户 ：第一次启动应用的用户；

新增独立用户 ：全体应用的新增用户的总和（去重）

活跃用户 ：当天启动一次的用户即为活跃用户，含新用户和老用户；

活跃独立用户 ：当天应用的活跃用户总和（去重）

MAU ：MAU（monthly active users）月活跃用户人数。

DAU : DAU(Daily Active User)日活跃用户数量。常用于反映网站、互联网应用或网络游戏的运营情况。

用户留存率 ：在互联网行业中，用户在某段时间内开始使用应用，经过一段时间后，仍然继续使用该应用的用户，被认作是留存用户。这部分用户占当时新增用户的比例即是留存率，会按照每隔1单位时间（例日、周、月）来进行统计。

用户留存率中的40-20-10法则 ：如果你想让游戏、应用的DAU超过100万，那么日留存率应该大于40%，周留存率和月留存率分别大于20%和10%。

次日留存率 ：（当天新增的用户中，在往后的第1天还活跃的用户数）/第一天新增总用户数；

第2日留存率 ：（第一天新增用户中，在往后的第2天还有活跃的用户数）/第一天新增总用户数；

第7日留存率：（第一天新增的用户中，在往后的第7天还有活跃的用户数）/第一天新增总用户数；

第30日留存率 ：（第一天新增的用户中，在往后的第30天还有活跃的用户数）/第一天新增总用户数。

另外就是APP的埋点数据，这个功能的点击率是多少？这个功能有多少人打开，又有多少人使用了？有多少人在频繁使用这个功能？等等，这些埋点数据要时常关注。结合数据变化来反思功能设计的问题，从而优化产品。

产品上线后，用户的反馈和评论对于产品人员来讲是尤为珍贵的材料，一方面这是你的真实用户的直观感受，另一方面他们再表达直接的需求。那么，怎么样处理用户的意见就显得格外重要。用户反馈什么我们就做什么，这是肯定不行的。很多情况下用户表达的只是一种表面现象，要学会去挖掘用户背后的需求本质。多去研究世界上一些革命性的产品，多去了解人。

当看到四处飞来的意见时，我们要学会思考，而不是全盘接受、全盘照抄。

是不是我们的目标？想想我们的目标用户是谁。

使用场景是否成立？还是这只是极个别人的场景需求。

用户目标是否正确？我们的APP是不是用来满足用户这个需求的？

产品定位还正确吗？如果做了这个功能，还符合我们产品的定位吗？

如果要做这个功能，那么自身的项目资源是否能够满足？如果需要举全部资源来做这件事情，那就要慎重再慎重。

也许用户的意见是个圆形，但经过分析之后，很有可能得到需求是个三角形。

“如果我最初问消费者他们想要什么，他们应该是会告诉我，‘要一匹更快的马！’”

——这是亨利·福特的一句经典名言，如今我们在《乔布斯传》里又见到了它。

100多年前，福特公司的创始人亨利·福特先生到处跑去问客户：“您需要一个什么样的更好的交通工具？”几乎所有人的答案都是：“我要一匹更快的马”。很多人听到这个答案，于是立马跑到马场去选马配种，以满足客户的需求。但是福特先生却没有立马往马场跑，而是接着往下问。

福特：“你为什么需要一匹更快的马？”

客户：“因为可以跑得更快！”

福特：“你为什么需要跑得更快？”

客户：“因为这样我就可以更早的到达目的地。”

福特：“所以，你要一匹更快的马的真正用意是？”

客户：“用更短的时间、更快地到达目的地！”

于是，福特并没有往马场跑去，而是选择了制造汽车去满足客户的需求。

客户需求有显性需求和隐性需求两大类。我们通过市场调查得知的往往都是一些诸如“我要一匹更快的马”这类显性需求。客户的显性需求并不是客户真正的需求。企业需要根据所收集的显性需求信息进行深度挖掘和捕获，以了解客户的隐性需求是什么，进而分析出客户的真正需求是什么（例如：用更短的时间、更快地到达目的地）。这就是一个需求分析的过程。

乔布斯所言：“我们的任务是读懂还没落到纸面上的东西。”实际上就是用户隐性需求的深度挖掘。

原文： >

以上就是关于埋点功能就是数据分析的力量吗全部的内容，包括:埋点功能就是数据分析的力量吗、关于埋点文档的一点总结、数据分析与埋点，产品经理必须掌握的知识和技能等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！