数据埋点是什么？设置埋点的意义是什么？
工作之后经常听到数据埋点这个词，但不明白埋点是什么。一下答案参考知乎大神的答案
知乎原文：https://www.zhihu.com/question/36411025
第一个答案
作者：大头鱼
链接：https://zhuanlan.zhihu.com/p/25195217
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
所谓埋点就是在应用中特定的流程收集一些信息，用来跟踪应用使用的状况，后续用来进一步优化产品或是提供运营的数据支撑，包括访问数（Visits），访客数（Visitor），停留时长（Time On Site），页面浏览数（Page Views）和跳出率（Bounce Rate）。这样的信息收集可以大致分为两种：页面统计（track this virtual page view），统计操作行为（track this button by an event）。
数据埋点的方式
现在埋点的主流有两种方式：
- 第一种：自己公司研发在产品中注入代码统计，并搭建起相应的后台查询。
- 第二种：第三方统计工具，如友盟、神策、Talkingdata、GrowingIO等。
如果是产品早期，通常会使用第二种方式来采集数据，并直接使用第三方分析工具进行基本的分析。而对于那些对数据安全比较重视，业务又相对复杂的公司则通常是使用第一种方式采集数据，并搭建相应的数据产品实现其数据应用或是分析的诉求。
关键指标
我们先看看无论是APP，H5还是小程序都会关注的指标，了解这些指标的计算方法的细微差异以及复杂性，换个角度来思考埋点的意义。【源自：精通Web Analytics 2.0】
- 访问与访客
访问次数（Visits）与访问人数（Vistors）是几乎所有应用都需要统计的指标，这也是最基础的指标。
对于应用的统计来说，经常看到的DAU，MAU，UV等指标都是指统计访客（Vistors）。访问（Visits）是指会话层，用户打开应用花一段时间浏览又离开，从指标定义（访问次数）来说这被称之为统计会话（Session）数。
一次会话（Session 或 Visit）是打开应用的第一个请求（打开应用）和最后一个请求决定的。如果用户打开应用然后放下手机或是离开电脑，并在接下来30分钟内没有任何动作，此次会话自动结束，通常也算作一次访问或会话期（30分钟是早起网页版应用约定俗成的会话数定义，目前用户停留在应用的时长变长，30分钟的限定也可能随之不同，总之是能代表一次用户访问的时长）。
在计算访问人数（Vistors）时，埋点上报的数据是尽可能接近真实访客的人数。对于有需要统计独立访客这个指标的场景，这里还是需要强调一下，访问人数（Vistors）并不是真实独立的人，因此收集数据时必须知道访问人数虽然能够很好的反映使用应用的真实访问者的数量，但不等于使用应用的真实人数。（原因是，重复安装的应用，或是手机参数被修改都会使得独立访客的指标收到影响。计算访问人数的埋点都是依赖Cookie，用户打开应用，应用都会在此人的终端创建一个独立Cookie, Cookie会被保留，但还是难免会被用户手动清理或是Cookie被禁用导致同一用户使用应用Cookie不一致，所以独立访客只能高度接近于使用应用的真实人数。）
- 停留时长
停留时长用来衡量用户在应用的某一个页面或是一次访问（会话）所停留的时间。
页面停留时长，表示在每个页面所花费的时间；例如：首页就是进入首页（10：00）到离开首页进入下一个页面(10:01)的时长，首页停留时长计算为1分钟。页面A是2分钟。停留时长的数据并不都是一定采集得到的，比如页面B进入时间（10：03），离开出现异常或是退出时间没有记录，这时候计算就是0 （所以指标计算时需要了解埋点的状况，剔除这样的无效数据）。
应用的停留时长，表示一次访问（会话）所停留的时间，计算起来就是所有页面的访问时长，同样是上一个流程，应用的停留时长就是4分钟。
- 跳出率
跳出率的计算方法现在在各个公司还是很多种，最经常被使用的是：用户只访问了一个页面所占的会话比例（原因是：假设这种场景，用户来了访问了一个页面就离开了，想想用户使用的心里画面应该是：打开应用，心想什么鬼，然后关闭应用甚至卸载了。这个场景多可怕，这也是为什么跳出率指标被如此关注）
跳出率可以分解到两个层次：一是整个应用的跳出率，二是重点的着陆页的跳出率，甚至是搜索关键词的跳出率。跳出率的指标可操作性非常强，通过统计跳出率可以直接发现页面的问题发现关键词的问题。
- 退出率
退出率是针对页面的，这个指标的目标很简单，就是在针对某个页面有多少用户离开了应用，主要用户反映用户从应用离开的情况。哪些页面需要被改进最快的方式被发掘。（注意：退出率高不一定是坏事。例如：预测流程的最终节点的退出率就应该是高的）
- 转化率
我们在产品上投入这么多，不就是为了衡量产出么？所以对于电商类应用，还有比转化率更值得关注的指标吗？转化率的计算方法是某种产出除以独立访客或是访问量，对于电商产品来说，就是提交订单用户数除以独立访客。
转化率的计算看起来想到那简单，但却是埋点中最贴近业务的数据收集。这也是最体现埋点技巧的指标，需要结合业务特点制定计算方法。提交订单量/访客数是最基本的转化率，转化率还可以分层次，指定用户路径的，如：完成某条路径的提交订单数/访客数。
试着找一条路径，想想转化率的数据怎么得来的吧，埋点都收集了什么样的数据吧？
- 参与度
参与度并不是一个指标，而是一系列的指标的统称，例如访问深度，访问频次，针对电商的下单次数，针对内容服务商的播放次数，及用户行为序列这些都可以是衡量参与度的指标。之所以把参与度列为一个指标，是希望大家明白把指标结合业务，产生化学反应，活学活用去发现事物的本质。
埋点的内容
看完关键的这些指标后，其实埋点大致分为两部分，一部分是统计应用页面访问情况，即页面统计，随页面访问动作发生时进行上报；另外一部分是统计应用内的操作行为，在页面中操作时进行上报（例如：组件曝光时，组件点击时，上滑，下滑时）。
为了统计到所需要的指标，应用中的所有页面，事件都被唯一标记，用户的信息，设备的信息，时间参数以及符合业务需要的参数具体内容被附加上报，就是埋点。
关于埋点的数据的注意事项
- 不要过分追求完美
关于埋点数据有一点至关重要，埋点是为了更好地使用数据，不要试图得到精准的数据要得到的是高质量的埋点数据，前面讨论跳出率就是这个例子，得到能得到的数据，用不完美的数据来达成下一步的行动，追求的是高质量而不是精确。这是很多数据产品容易入坑的地，要经常提醒自己。
第二个答案
链接：https://www.zhihu.com/question/36411025/answer/468092622
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
数据生产-数据采集-数据处理-数据分析和挖掘-数据驱动/用户反馈-产品优化/迭代。
埋点：数据分析的第一步
大数据，从庞杂的数据背后挖掘、分析用户的行为习惯和喜好，找出更符合用户“口味”的产品和服务，并结合用户需求有针对性地调整和优化自身，正是大数据的价值。而这信息的汇集、分析就绕不开“埋点”.
小科普：“埋点”
埋点就是在有需要的位置采集相应的信息，就如同公路上的摄像头，可以采集到车辆的属性，比如：颜色、车牌号，车型等信息，还可以采集到车辆的行为，比如：有没有闯红灯，有没有压线，车速多少，司机有没有在驾驶中接听电话等，如果摄像头分布是理想状态，那么通过叠加不同位置的摄像头所采集的信息，完全可以还原出某一辆车的路径、目的地，甚至推测出司机的开车习惯、是否是老司机等信息。
那么，每一个埋点就像摄像头，采集用户行为数据，将数据进行多维度的交叉分析，可真实还原出用户使用场景，挖掘用户需求，从而提升用户全生命周期的最大价值。
4种埋点“姿势”
为了将海量数据采集得更加精准，为后续营造“纯净”的数据分析环境，埋点技术应运而生。数据基础夯实与否，取决于数据的采集方式。埋点方式多种多样，按照埋点位置不同，可以分为前端（客户端）埋点与后端（服务器端）埋点，其中前端埋点包括：代码埋点、全埋点、可视化埋点。
全埋点：通过SDK，收集页面所有控件操作数据，通过“统计数据筛”，配置待处理的数据的特征。
优势：一切操作皆埋点，简单、快捷，无需埋点统计数据按需处理
劣势：数据上传消耗流量大，数据维度单一（仅点击、加载、刷新）；影响用户使用体验——用户使用过程中容易出现卡顿，严重影响用户体验；噪点多，数据准确性不高，容易产生干扰；不能自定义埋点收集信息.
如同卫星拍摄，无需逐一安装摄像头，但数据量巨大，且容易遗漏，不易挖掘关键信息，因此全埋点的方式，适合以下场景：
举例·应用场景
主要应用于简单页面，比如：短期活动中的落地页/专题页中，需要快速衡量点击分布等效果。
JS可视化埋点：嵌入SDK，可视化圈选定义事件
为了方便产品和运营同学可以直接在页面上进行简单圈选，以追踪用户的行为(定义事件)，
仅采集click(点击)操作，节省开发时间，诸葛io已于近期支持JS可视化埋点。
优势：界面化配置，无需开发，埋点更新便捷，生效快
劣势：埋点自定义属性支持较差；重构或者页面变化时需要重新配置；
如同卫星航拍，无需安装摄像头，数据量小，支持局部区域的信息获取 ，因此JS可视化埋点更适用于以下场景：
举例·应用场景
1、短平快的数据采集方式：活动/H5等简单页面，业务人员可直接圈选，操作无门槛，减少技术人员的介入（从此世界和平），此种数据采集方式，方便业务人员尽快掌握页面中关键节点的转化情况，但是对用户行为数据的应用较浅，无法支持更深度的分析；
2、若页面临时调整，可灵活的追加埋点，可作为代码埋点的补充，以便及时增加采集数据
代码埋点：嵌入SDK，定义事件并添加事件代码，按需采集，业务信息更完善，对数据的分析更聚焦，因此代码埋点是一种以业务价值为出发的行为分析。
优势：数据收集全面且准确，便于后续深度分析（埋点准确性顺序：代码埋点＞可视化埋点＞全埋点），SDK较小，对应用本身的使用体验没有影响
劣势：需要研发人员配合，有一定的工作量
举例·应用场景
1、如果你不希望在采集数据的同时，降低用户体验
2、如果你不希望采集到海量无用数据
3、如果你希望采集的数据：颗粒度更细，维度更多，数据分析的准确性更高
那么，从业务增长的长远价值考虑，请选择代码埋点
服务端埋点：可支持其他业务数据采集和整合，如CRM等用户数据，通过接口调用，将数据结构化，由于直接从服务器端采集，数据准确性更高，适用于自身具备采集能力的客户，或可与客户端采集相结合采集。
举例·应用场景
1、通过调用API接口，将CRM等数据与用户行为数据进行整合，全量、多角度分析用户；
2、若企业已有自身的埋点体系，那么可直接通过服务端采集将用户行为数据上传到诸葛io平台，进行数据分析，无需维护两套埋点系统；
3、打通历史数据（埋点前的数据）与新数据（埋点后），提高数据准确性。如在接入客户端采集之后的客户，导入原有历史数据后，此前的已有的用户访问平台，不会被标记为新用户，减少数据误差。
怎么埋？
埋点听起来“不明觉厉”，其实非常的简单，就如同“在公路上安装摄像头”。
1、梳理产品用户行为，确定事件布点
埋点方案≈摄像头安装的分布方案
经常有童鞋咨询诸葛君：究竟获取哪些数据来进行数据分析？回答这个问题，先要明确目的，厘清逻辑。
诸葛io数据分析的对象和基础是用户行为，选择记录和分析哪些用户行为，直接影响到分析工作的价值产出，诸葛君建议：选择与产品目标和当下首要问题最为密切相关的用户行为，作为事件。以电商为例，将流程中的每个用户行为定义为一类事件，从中获得事件布点的逻辑。
2、记录事件，了解分析用户行为
确定摄像头要记录的信息，是违章拍照还是测速？
对需要记录和分析的用户行为进行梳理，并完成事件布点表后，接下来，需要在研发工程师的协助下，根据您应用的平台类型（iOS、Android、JS）完成SDK的接入，每个事件的布点，将变成一段非常简短的程序代码——当用户做相应的行为时，您的应用会运行这段代码，向诸葛io记录相应事件。在布点完成、产品发版后，用户开始使用新版的应用时，使用行为的数据就会自动传递到诸葛io，以便您进行下面的分析。
这一步，诸葛io的CS团队将为企业提供支持，协助技术团队顺利完成数据采集的第一步。
3、通过identify记录用户身份
在诸葛io中记录了用户的行为，即：用户做了什么？ 在对用户分析的过程中，还有一类信息是很有用的，即：用户是谁（TA的id、名字）以及具备什么特点（TA的年龄、类型……）？您可以通过诸葛io平台的identify过程，将用户的身份及特点传递给诸葛io，利用identify的信息进行精细化分析：
细分用户群：用户属性的一个很重要的作用就是将用户分群。您可以根据identify的属性定义筛选条件，进行用户群的细分，比如用「性别=女」的条件将所有的妹子筛选出来，然后分析妹子们的行为特点和转化率……
基于属性的对比：细分的重要目的之一就是对比，您可以基于「性别」细分，然后对比「妹子们」和「汉子们」的行为、转化、留存等的区别；
基于属性的人群画像：您可以基于用户属性，对产品的任意用户群进行「画像分析」——该用户群的男女比例、地区分布、年龄层次、用户类型……
最理想的埋点方式？
回到一开始的问题：何种埋点方式最理想呢？
正如同硬币有两面，任何单一的埋点方式都存在优点与缺点，企图通过简单粗暴的几行代码/一次部署、甚至牺牲用户体验的埋点方式，都不是企业所期望的。要满足精细化、精准化的数据分析需求，可根据实际需要的分析场景，选择一种或多种组合的采集方式，毕竟采集全量数据不是目的，实现有效的数据分析，从数据中找到关键决策信息实现增长才是重中之重。
因此，数据采集只是数据分析的第一步，数据分析的目的是洞察用户行为，挖掘用户价值，进而促进业务增长，故最理想的埋点方案是根据根据不同的业务和场景以及行业特性和自身实际需求，将埋点通过优劣互补方式进行组合，比如：
1、代码埋点+全埋点：在需要对落地页进行整体点击分析时，细节位置逐一埋点的工作量相对较大，且在频繁优化调整落地页时，更新埋点的工作量更加不容小觑，但复杂的页面存在着全埋点不能采集的死角，因此，可将代码埋点作为辅助，将用户核心行为进行采集，从而实现精准的可交叉的用户行为分析；
2、代码埋点+服务端埋点：以电商平台为例， 用户在支付环节，由于中途会跳转到第三方支付平台，是否支付成功需要通过服务器中的交易数据来验证，此时可通过代码埋点和服务端埋点相结合的方式，提升数据的准确性；
3、代码埋点+可视化埋点：因代码埋点的工作量大，可通过核心事件代码埋点，可视化埋点用于追加和补充的方式采集数据。
