为了更加有针对性、科学、客观的对产品优化迭代，产品经理会进行产品埋点，期望通过分析上报的数据来获得某种趋势、特征的信号或者说信息，最后，这些信息被用在产品优化决策上。本篇文章中，笔者对产品经理需要了解的埋点知识进行了梳理，攻大家参考和学习。
产品经理工作的三个常态就是写文档、沟通、看数据。毕竟辛辛苦苦写完需求文档还冒着被砍需求的风险，好不容易说服了研发开发上线后，总是要关注自己在研发面前吹上天的功能在上线后数据方面是不是有变化。
另外产品经理的本质工作是发现问题、分析问题和解决问题，写文档也好，沟通跟进项目也罢，最终的目的都是为了解决问题，那怎么证明问题被解决了？
除了后台反馈某个问题的声音没了以外，最直观的就是负面数据降低了，正向数据升上去了。
产品经理的价值除了实现用户价值，解决用户的各种问题痛点以外，还需要实现商业价值，毕竟老板给定的OKR既不会让研发背也不会让测试背，对结果负责的只能是产品了。
那产品怎么证明自己勤勤恳恳夜以继日的工作是有收获的呢？
数据是让老板满意最有效的方式，毕竟日活能从10w做到100w对企业来说是完全不一样的概念，直接的商业价值比如售卖的收入转化从0.4%做到4%就有可能让企业真正的存活下来。那数据从哪来呢？今天就好好说道说道埋点的全流程。
前面说了产品经理想看数据那就需要多方配合，既然自己需要数据，除了用户的行为会反映在数据上以外，想要直观看到数据中间还是隔了不止一座山不止一片海（最近看了张嘉佳的《云边的小卖部》各种华丽辞藻堆砌鸡汤文不禁被带了节奏），毕竟自己也没法看到每个用户的使用情况。那又该如何是好呢？「为何处境如此的像唐僧」
这里就需要我们万能的研发了，不仅需要他们通过飞舞地敲动键盘上的字母转瞬间变成代码，进而将草图上不堪入目的功能概念变成触手可及的实用功能，也需要他们继续飞指间将监听用户行为的代码也一同写进去。
研发能监听用户的行为但毕竟这些东西都还是在代码里，可视化的效果确实有点难，这里就需要数据分析的同学进场了，产品经理除了跟研发提数据需求，也需要跟数据分析的同学提需求，把监听到的数据变得可视化，易于直观的看到自己想要的结果。
上面说了这么多，那我们就正式的来说每一步吧~
「埋点原理及方式」
首先是关于埋点的概念，毕竟做啥事能明白其中的原理还是很重要的。
埋点是指对目标事件进行捕获、处理和上报的相关技术及实施过程，其主要目的是实现用户对产品行为的监控与数据收集。
具体来说就是在定义的事件代码中植入一段监控代码，用户一旦触发该事件就会上报埋点代码中定义的需要上报的字段信息；通俗的说就是实现了给每个用户在使用自家产品时分配了一个产品经理，用来记录用户都打开了哪些页面，点击了哪些按钮，停留了多长时间。
埋点可根据开发方式与埋点位置分为两类，先是开发方式最常见的一种是代码埋点，即手工埋点，顾名思义是研发将用于监听用户行为的代码提前手动埋到触发该事件的代码中。
这种传统且常见的方式优点和缺点都极其明显，优点方面即可以自定义进行数据采集，想采多少就采多少，想采什么数据就采什么数据，哪怕是脑洞再大的产品经理只要是提的数据需求合理，原则上都可以满足并最终统计到想要的数据。
但同样的缺点就显而易见了，这种手动人为的方式就会受到整个APP发版流程的限制，即不管是iOS端还是Android端每次升级都是要发版的，而每次发版都是封装好当前这版本的代码，如有变动只能更换提交到各大应用商店的安装包，如果频率过多负责渠道的同学定会提着40米的大砍刀来找发版产品经理了。
代码埋点一旦存在问题进而会引发什么问题呢？
试想新功能上线后老板某一天突然找到你要新版本的数据，这时你找研发要埋点信息但对方告知你没有埋上或者埋点信息异常，听到这句话产品心里肯定凉半截，没法交差了。
如非极其重要的数据只能眼瞅着等待下一个发版周期才能统计新功能的数据了。此外，流程上也会占用一定的人力，这点在后面的埋点流程中会细讲。
当一种操作方式有它存在的局限性，随之就会有其他更便捷高效的方式出现，毕竟事物是发展的，没错，近几年一些第三方数据平台或诸如bat这种互联网公司已经想出一种可视化埋点方式
——通常是指通过设备连接用户行为分析工具的数据接入管理界面，对可交互且交互后有效果的页面元素（如：图片、按钮、链接等），直接在界面上进行操作实现数据埋点，下发采集代码生效回数的埋点方式。
这种埋点方式极大的提高了人力成本，想想传统的手工埋点方式需要产品给研发提埋点需求，研发需要在代码中写入监听的代码，产品上线前还需要验证。可视化埋点类似于前端网页的形式，实时交互降低人力成本和出错成本。
既然可视化埋点这么好为啥并没有完全普及或者成为各大互联网公司的主流埋点方式呢？问题就在于既要轻量级就没法完全自定义，对于一些基本的记录某个页面的展现和按钮点击可能没问题，但是面对一些复杂的数据需求时这种方式便没辙了。
比如需要区分来源的数据需求，带各种参数的需求，需要和后端交互的数据需求就不太适合可视化埋点方式。
所以总结来看可视化埋点虽然很美好但仅限于一些简单的纯客户端埋点统计，在复杂的数据采集需求面前行不通且准确性较低，这也是影响它普及的最大因素。
除了可视化埋点还有一种无埋点方式，也叫全埋点，即事先尽可能收集所有控件的操作数据，然后再通过界面配置哪些数据需要在系统里面进行分析。
相比于可视化埋点这种半自动化模式，全埋点不仅继承了可视化埋点的优点，同时解决了手工埋点和可视化埋点共同的一个缺点即数据回溯。
比如产品想要看某个按钮的数据，可视化埋点只能做到从此刻以后的数据，在这之前的数据是没有的。
但全埋点只要在一开始封装的SDK就部署在代码中即可以保留整个时间线的数据，做到真正的所见即所得，通过点击某一控件区域便能看到该区域的历史所有数据。
但全埋点也继承了可视化埋点的所有缺点，所以这种的埋点方式同样也无法做到全面普及。
上面说的手工埋点、可视化埋点、全埋点是指按照开发方式划分的，按照埋点位置还可以分为客户端埋点和服务端埋点。即上面三种埋点方式都是在客户端实现的，而有一部分数据是可以直接通过服务端去埋点并上报所有数据。
比如统计某款社区产品每天的用户发帖记录，除了可以直接在客户端埋点统计，也可以直接提交至服务端的数据量级。客户端埋点和服务端埋点优缺点又是什么呢？
对于客户端埋点的优点和缺点基本上就是上面介绍的那些，这里相比于服务端埋点存在的另一个缺点是数据上报有延迟且会存在漏报的情况。
而服务端埋点的优势便是数据上报无延迟，可以实时获取到数据，且整个操作较客户端更简单便捷，缺点方面自然是没法统计纯客户端的数据，比如不需要跟服务端发生交互的用户行为。
此外数据的收集会依赖网络环境，这也是为什么同样的统计目标一般服务端和客户端统计的数据有些许偏差。
这里正是因为网络质量的问题影响了服务端的统计。比如用户提交某个数据，在客户端层面用户已经完成了这个行为，但网络质量不佳服务端可能就没有采集到这个数据。
以上关于埋点的原理介绍和分类就已经说完了，下面开始埋点相关角色分工及埋点需求的流程，这里主要讲的是当前主流模式的客户端手动埋点流程。
埋点需求流程中包含的角色如上图，包括产品经理、研发、测试、商务智能和数据平台。
其中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作为数据需求的发起方应充分了解埋点的流程，尽量降低各环节因不规范性带来的风险性，更好的让数据服务于工作。
以下还有一些关于数据方面的常见问题：
A：上面的流程中更多是埋点的业务流程，真正的数据流程包括数据采集、数据上报、数据存储、数据加工、数据输出等几部分。
Q：一般可以采集到哪些数据？
A：按照采集位置可分为客户端「交互行为」数据和服务端「接口请求」数据。客户端数据包括页面的展现、控件点击、停留时长等，服务端数据包括请求状态、请求结果等。
Q：哪些原因会导致统计的数据不准确？
A：首先是数据源异常，其中包含功能变动后未提出埋点需求、埋点需求不明确不完整、沟通过程中需求方和执行方理解有偏差等；同时在代码层面可能会出现埋点位置错误、参数缺失，或者因为代码调整导致原有埋点代码丢失错位等；
其次是数据上报异常，包括上报数据格式不规范，没有按照规定格式上报或者各业务的埋点数据格式不统一；因网络质量不佳和服务器压力过大会导致数据上报延迟；数据上报地址的错误也会导致无法准确统计数据；
最后数据输出层面也会影响数据的准确性，比如数据需求未将统计逻辑考虑周全，需求方与统计方沟通理解的偏差性，数据产出延迟等。
Q：数据有问题，可以找哪些同学解决？
A：首先是与bi或数据分析同学确认数据上报和产出是否存在延迟问题，其次再确认统计方式与自己的需要的数据统计逻辑是否一致，如若不一致则由数据产出方修改SQL语句即可；当统计方式没问题时再去和rd同学确认埋点信息、参数信息在代码中是否埋上且位置准确，上报地址否准确等。
Q：在哪些环节可以避免数据问题？
A：产品、运营、研发加强并培养数据意识，更深入了解并提升数据相关能力。产品、研发、数据分析等同学在埋点流程中保持较高的严谨性和专注度，避免在执行层面犯低级错误。全流程中各环节各方负责人均需加强自测和验收，在需求上线前及时发现问题。借助工具的能力，将诸多流程从线下人力迁移至线上流程，减少因人力维护和输入输出导致的一些错误。
