埋点还是埋雷？ 十年数据分析经验，教你如何结构化埋点！

在接触过上百家头部App客户中，诊断和参与了数百次的App数据体系搭建工作。几乎80%的App都没有科学的埋点规划，只采集显性数据，而更深层的与事件、参数相关的隐性数据，都没有采集到。埋点规划并不难！但为什么大部分企业都做的不太好？

埋点规划需要整合产品、运营、技术和业务等跨部门的需求，运营同学不太懂技术、技术同学不太懂业务、产品同学不太懂埋点，这问题该如何解？

在友盟+《战疫求生，开发者的危与机》直播公开课上，友盟+业务专家张跃梳理出一套完整的埋点干货笔记。带你避开埋点的深坑，梳理结构化的埋点方案。

在埋点前，先带你避开埋点的深坑

第一坑：遗漏

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

第二坑：杂乱

指的是数据采集比较零散，可以理解为前期并没有进行事件结构化的设计，通常是想到一个需求，就把这个需求提供给技术进行埋点。

这种称之为“扁平化”的埋点方式，例如：某一个位置或者某一个功能的点击行为，就当做一个事件进行采集，看上去采集和查看很容易，但随着时间跟需求的增加，当采集了大量零散的事件之后，需要在统计工具中通过分组分析时，就会比较麻烦。

第三坑：低效

不同于杂乱，杂乱是任何行为数据都会直接当事件去进行采集，没有利用参数去进行结构化的设计。低效指的是在事件设计的时候，会去做结构化处理。但事件设计的参数逻辑会有问题，通常都是以大的页面这种框架的思维去进行设计。

举个例子：部分客户在设计时，会按照页面的思路去进行事件采集，页面上有推荐位，还有很多功能按钮的点击，那么就会把这个页面所有的点击行为都归到一个事件，并且点击具体的按钮和内容都当做参数传回来。

但这里埋着两个雷区：

在分析数据时，例如想了解整个用户浏览内容的情况，或者是想了解某个功能（搜索引擎）整体使用情况，按照如上设计，内容和功能的采集都分布在每一个事件中了，这样后面再归类、分析就非常不方便。

当产品结构产生变化时，原有事件调整概率会比较大，因为之前都是按页面结构去设计，页面的调整直接影响事件采集。

第四坑：无用

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

第五坑：复用

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

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

需求清晰。

合理设计。

实施规范。

结果可验。

规范管理。

埋点方法论——五步一全（ODEIIC），需要多角色参与统筹决策

第一、需求梳理

在梳理埋点设计的时候，通常会以产品、运营和市场以及KPI三个视角去切入。通常，产品关注的核心业务点会聚焦在内容和功能上，运营和市场关注的业务点在拉新、留存、促活和转化上，KPI视角会聚焦在转化与收入上，但也需要根据客户的实际情况而定。

同时，会把不同视角的业务需求再转化成需要关注的核心数据，如产品运营在内容上所需要关注用户浏览、内容的转发或者是偏好，针对功能使用会关注注册、登录、搜索等这些功能的使用情况。

业务需求拆解成核心数据后，针对每一个核心数据进行维度的细分，如内容方面：会按照标题、频道或者是标签，进行拆分分析。那么我们针对功能方面，会按照功能使用情况以及步骤的转化去进行分析。通过要分析的关键点，就可以把细分维度拆出来，最后还会再加上一些通用的维度，例如可以对单个用户或者某一个地区的用户进行深度分析。