【产品必备技能】关于埋点，读懂这一篇就够了

低年级的产品经理，尤其是刚入行的PM，对于埋点经常是一知半解，为什么埋点，埋点怎么埋，下面这篇文章将对埋点的相关事宜进行整合梳理，适合低年级PM入门。

数据采集是核心问题

对于任何一个系统而言，数据流都是最基本的flow，了解系统的数据流向，有助于走通系统流程，后续定位问题。

一般而言，某个系统的数据流可以划分为以下几个模块：

第一，数据采集。

第二，数据传输（数据highway）。

第三，数据存储与建模（清洗）。

第四，数据挖掘（从数据中获取insight）。

第五，数据呈现（可视化工具等）。

数据采集是数据流的源头，也是后续建模和挖掘的基点。巧妇难为无米之炊，数据采集是核心问题。

埋点的目的是为了了解和监控某个动作或者某项功能的数据表现

如何判断某个动作或者某项功能的改进是合理的？最直观的就是该功能的数据表现。当然，每个产品都有对用户心理的洞察和分析，但是对用户的理解并不是停留于逻辑和理论，而是要通过多次的小规模尝试去迭代和挖掘。 

数据从哪里来？当然是埋点了。 

比如，我之前遇到的一个case，要在所负责的频道中新增一个功能，有用户后台反馈的背书，也有专门用户调研的支撑，经过探讨，也认为符合逻辑和场景。结果上线后，发现使用率并不高，对整体频道的贡献也较小，回过头来反思，认识到最开始高估了该需求的紧要性，而低估了操作的成本。

诸如此类，很多看起来逻辑自洽的需求，其实并没有你想象的那么重要。

常见的代码埋点

埋点的技术实现方案简单可以分为：代码埋点，可视化埋点和无埋点。

代码埋点的技术思路是，在某个时间被触发时，SDK调用数据统计接口。优点是可以精准控制，缺点是代价比较大，原生APP一般使用代码埋点。

可视化埋点的技术思路是，在嵌入了 SDK 的 APP 开启可视化埋点模式，与后端联通时，SDK 会应后端的要求，定期（例如每秒）做一次截图。服务端根据截屏和可视化信息来重新进行页面渲染，并且根据控件的类型，来识别哪些控件是可以增加可埋点的，并且将之标识出来。

无埋点的技术思路是，尽可能收集所有的控件的操作数据，然后再通过界面配置选择需要分析的数据。优点是全，这是埋点的策略带来的天然优势，问题就是消耗大，可能给系统带来较大的开销。

目前原生APP常见的埋点方式是代码埋点，尤其是大型的互联网公司，有专业的埋点团队和项目经理，能跟版更新埋点方案。

埋点工作中的关键非技术问题

在实际的APP开发和迭代过程中，埋点的关键问题并不是集中在技术方案，而在于非技术问题。我们暂且称为“关键非技术问题”，在产品经理实际的工作中，埋点混乱是个大坑，因为埋点的工作就是两个方面，细和全，混乱是致命伤。通常情况下，埋点时需要具有架构思维，操作层面来讲，就是划分页面，理清信息层级，在此基础上，review上报的参数是否全面，是否具有唯一性，将自己作为数据的分析方来看埋点方案是否合理。

在此推荐event模型，该模型可以很好的分析用户行为，将用户的各种行为简化为一张宽表，将用户的行为拆分为不同的事件，事实上，event模型天然适合电商类APP，尤其是涉及到用户漏斗和转化分析。

关于event模型的更多内容，推荐神策数据的相关说明。链接在此https://www.sensorsdata.cn/manual/data_model.html。

To sum up,埋点怎么埋，第一步要划分信息层级，要在脑子里搭建起产品的框架，就和乐高积木一样，尤其是对于新手来说，一定要一个点一个点从头埋一次，该踩的坑踩过了，也就知道该怎么埋，上报哪些参数了。