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

小提示：您能找到这篇{埋点还是埋雷？ 十年数据分析经验，教你如何结}绝对不是偶然，我们能帮您找到潜在客户，解决您的困扰。如果您对本页介绍的埋点还是埋雷？ 十年数据分析经验，教你如何结内容感兴趣，有相关需求意向欢迎拨打我们的服务热线，或留言咨询，我们将第一时间联系您！

本文作者带你避开埋点的深坑，梳理结构化的埋点方案。

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

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

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

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

第一坑：遗漏

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

第二坑：杂乱

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

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

第三坑：低效

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

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

但这里埋着两个雷区：

1. 在分析数据时，例如想了解整个用户浏览内容的情况，或者是想了解某个功能（搜索引擎）整体使用情况，按照如上设计，内容和功能的采集都分布在每一个事件中了，这样后面再归类、分析就非常不方便。
2. 当产品结构产生变化时，原有事件调整概率会比较大，因为之前都是按页面结构去设计，页面的调整直接影响事件采集。

第四坑：无用

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

第五坑：复用

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

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

1. 需求清晰。
2. 合理设计。
3. 实施规范。
4. 结果可验。
5. 规范管理。

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

第一、需求梳理

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

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

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

以产品视角的需求样例，产品通常情况下会聚焦内容与功能上的使用，但在需求收集时都是分散和抽象的，例如：业务需要分析内容偏好和推荐效果以及内容受欢迎的程度。

那在这个环节就需要先做需求拆解，也就是说要去找到能分析这个需求的核心数据与能够帮助判断业务变化的一些指标，细分维度在这里的作用更多的是做需求详细的拆解，可以理解为是去做核心数据的多维度明细展示，那么目的就是从更细的维度去满足业务分析需求；

总结：先要找到能满足这个需求的核心数据，在找到核心数据分析时所需要涉及的细分维度，如图：

第二、事件设计

可以通过这3个步骤去完成事件的结构化设计：

• 第一个步骤是要了解产品结构，也就是先要了解分析的范围是什么，例如需要知道对哪些页面或者哪些功能有分析需求；
• 第二步，就是要针对这些锁定的范围，去明确我们要分析用户的行为有哪些；
• 第三步，要把这些行为，落实到具体的分析维度上。

后面会通过指标体系、分析需求、分析方法这3个角度，在去结合这三个步骤，进行事件结构化设计的详细说明。

在介绍按照指标体系去进行结构化事件设计前，我们先看下指标体系的样例，通常会按照这几个模块去搭建指标体系，分为：概况、营销、用户价值、运营和核心功能。

1. 概况可以理解日常关注的核心数据，比如：新增、启动、日活、周活、月活以及会员数据、注册数据以及使用黏性、使用时长、留存等，还包括技术、产品较为关注的稳定性数据。总的来说：就是将核心或常看的数据放在概况的大板块中。
2. 营销。通常会把广告数据，例如：广告的曝光、点击率以及广告点击排行，媒体排行、展示排行信息会放在第二个板块。
3. 用户价值。通常会把新用户的次留、成本以及用户回本周期模型和生命周期模型放在用户价值模块。
4. 运营。主要关注内容与转化，通常会分析内容的热度，任务的交互与会员的转化，针对会员还会分析会员新增、会员累计、会员续费等维度。
5. 核心功能。是产品岗位较为关注的，例如：导航位、导航按钮，被用户点击的情况、使用的情况，对应核心功能，比如说搜索功能或者是注册功能，整个功能的入口、被点击的情况和转化率等相关的这些数据会放到这个板块。

从指标体系到事件设计

如何通过指标体系去进行结构化设计？指标体系可以理解为指标与报表的一个组合，整个指标体系对应到产品结构上，可以分为对产品页面和产品功能的分析需求。

下面先从产品页面的角度去进行事件设计说明：

• 第一步，会先锁定页面的范围，比如产品里有活动页、内容页、如果是视频App的话会有播放页，小说App会有阅读或者是听书页面。
• 第二步，范围圈定后就需要找分析行为，用户看到内容是否有点击行为，进入页面后的浏览行为，以及是否有分享、评论等行为。
• 第三步，确定了要分析的行为后，就需要进行分析维度的细化，如要分析用户浏览（浏览完成行为）内容都有哪些，还想分析用户是哪个入口（来源）进入到页面等等，这些都是针对用户行为要分析的维度。

按照这三步梳理清楚后，事件设计中与产品页面相关的事件和参数就能整理出来了，如页面范围对应的“内容页”和分析行为对应的“点击”行为，就能够清楚我们要采集的事件为“内容点击”，在根据这个事件需要分析的维度是页面名称、页面分类以及页面来源，这个事件所需要的参数也就找到了。

下图中是以内容页和活动页梳理的结构化事件样例。

以产品功能的角度去进行事件设计说明：

同样，第一步先找到要分析哪些功能，比如：搜索、登录、注册、会员、付费、签到等。第一步找到监测功能的范围。

第二步在找行为，功能层面的行为比内容会稍微简单一些，主要是点击行为或者是完成状态。

第三步是维度，例如：搜索功能，想分析搜索入口的点击情况，搜索的关键词是什么，针对登录与充值的话，需要分析帐号登录的类型、充值的方式等等。

页面功能所产出的结构化事件样例

以搜索引擎为例：搜索引擎监测的行为是点击和完成，通常会用两个事件进行监测，搜索引擎功能在很多页面都会有入口，通常会建议在这里增加一个参数叫搜索位置，可以辨识用户点击哪些搜索位的按钮，另外可增加参数叫用户ID，去了解具体是哪些用户进行的点击。

重点说一下功能按钮点击事件。通常情况下，会将核心要分析的功能都抽离成单独的事件进行统计。如登录、注册、付费或者是会员购买等，这些属于核心要关注的功能，并且会为这些核心功能事件单独设计要分析的参数。

但如扫一扫、加载更多以及一些Tab键，只需要监测用户点击即可，不需要监测功能背后的参数信息。通常会将这些点击行为放在一个事件下，定义名称叫功能按钮点击，会通过“按钮名称“与“所属页面”等参数去锁定用户点的具体按钮是哪个。

小结，通过指标体系去进行事件设计，就能够把大部分需要采集的页面与功能都能覆盖到，并且可以满足后期看数据的需求。

从分析需求到事件设计

先引用小说行业的一个需求举例，近期上架了新书，要分析新书对用户的吸引力如何。那么第一步，就要把需求进行转义，也就是需要知道哪些数据和维度，能证明用户对新书的吸引力。

针对这个需求，分析思路是：今天新上架的小说，用户看了多少章节和时间，明天会不会继续来看，可以通过这几个维度去判断出新书吸引力。

那么在落实到事件设计的三个步骤中，第一步采集的页面范围是小说页面，第二步采集的行为就是阅读，这两步对应出我们需要采集的事件就是小说阅读，第三步需要分析的维度就是阅读章节、阅读时长、小说名称以及上线日期，这些维度就可以转化成参数在事件中设计进来。

另外，一般做内容事件时，通常还会增加来源参数，比如：来源页面、网络营销教学视频来源版块、来源位置，这些参数可以帮我们定位到用户是从那些入口获取到内容的，便于后期去分析各入口的导流效率。

从分析方法到事件设计

这部分指的是根据核心目标，在利用一套分析方法去解决问题时，如何找到解决问题环节中所需要采集的事件。

比如，目标锁定是要提升用户留存或者是提升付费转化率，那么，首先要找到不同的人群，针对人群找差异（功能使用、内容偏好的差异），找到不同的人群在功能使用、以及转化路径的差异后，在去找问题，如某一些功能对于非留存用户或者是非付费用户体验不好或推荐的内容用户不感兴趣，找到问题后，就需要进行优化，并进行验证。

针对分析方法中的每个环节，其实都能对应到需要分析的事件，如找问题的环节会对入口的点击、完成的情况，内容浏览的来源等等进行事件采集，在分人群环节，会对用户的付费行为进行事件采集等等。

通过每个环节找到对应需要分析的行为后，就可以把相关信息以事件或者是参数的形式，补充到现有结构化埋点方案中了。

按照指标、需求、方法这3个角度去做了事件设计方法的介绍，总体可归纳为：

有了指标体系与分析需求，整个结构化埋点方案的框架就能设计出来了。分析方法更多的作用是做分析思路上的贯穿，可以帮我们发现埋点设计中缺少或者遗漏的环节，整体上我们就可以理解为，指标体系+分析需求+分析方法这三部分的结合，才能得到一个非常贴合业务的埋点方案。

小结：“事件采集“就是要知道谁在什么时候做了什么事情，设计思路可以分为三步。

首先，了解产品结构（产品结构的范围，页面结构、功能结构）；其次，了解用户行为（点击行为、完成行为、曝光行为等）；最后，行为可以细分哪些维度，按照三步结构化事件就可以设计完成了。

总结三个避坑的Tips

（1）需求

如果前期需求不是很明确时，可以先把这个指标体系梳理起来，比如：核心关注的指标，采集方案是可以满足暂时看数的需求，后期可以根据对分析需求的升级再去补充。

（2）归类

在事件设计时要合理的进行归类，尽量用一个事件满足多个分析需求。比如，了解用户都是从哪些入口获取内容的，和内容浏览的热度排行，是可以通过一个事件来实现的，只需要通过内容名称和来源页面两个参数，就能够满足这两个需求了。

（3）范围

在参数设计中两个范围需要注意，即来源和点击按钮，内容采集会涉及三个来源：来源页面、来源板块和来源位置，是为了去锁定到底内容从哪里点过来，开发也会要求将入口信息梳理清楚，从而进行埋点的开发工作。点击按钮，将按钮都归属到一个事件中，将参数设置为按钮名称，梳理出具体的按钮采集的范围给到开发，才能去进行后续的埋点。

埋点设计不是简单的事件与参数的结合，而是需要贴合业务、贴合分析场景去进行设计。

结构化事件设计完成后，下一步就是要交付给技术进行开发，下图为一个资讯行业的事件埋点模版，可以参照这个模板去进行梳理并提交给技术。

埋点实施：

市场上主流支持的四种埋点方式，分别是代码埋点、服务端埋点、可视化埋点和全埋点。代码埋点，支持事件与参数这种结构化的使用方式，弊端是想增加或修改事件，都需要重新发版，用户更新后才能采集。服务端埋点，通常用于业务数据的采集，例如：付费成功、用户注册等，这个场景会选择用服务埋点进行采集。

可视化埋点和全埋点，都是解决整个App前端操作的一些点击行为，例如说某些按钮、页面，每一个点击都能监测。但差异点在于可视化埋点只能看到圈定后的数据，那么全埋点则是在圈定时，历史数据也能去追溯。

但这两个埋点的弊端是散点采集，每一个点击行为都是一个事件，在数据分析时，事件的量级会较大，不易于分析，而且它只能是取这种点击行为的事件，并不能把参数带过来，你可以理解为它就是一个纯扁平化的一个事件采集。

针对需求的不同，数据采集方式应该是结合使用的，以友盟+为例，友盟+现在支持两种埋点方式，代码埋点和可视化埋点，开发者可以结合使用，去满足事件方案的采集需求。

看板校验：

埋点后可通过三种方式验证：

1. 打印日志，开启debug去打印Log，去验证触发事件log是否有上报，这种方式需要技术来配合验证。
2. 集成测试，只需要在测试设备上去触发事件，产品、运营的同学就可直接测试埋点情况。
3. 也可以使用市场上智能验证的工具，自动去识别整个埋点的情况，且日志是实时的，可产出事件的验证报告。

智能验证：

可以智能验证这些事件的点是否采集了，是否有遗漏，最后会定期给出体检报告，详细的明细都会有。只需要注册一个测试设备，这个测试设备填加完之后会实时把客户这些埋点的数据进行验证，到底是成功还是异常，以及测试的时间是什么都会有详细的数据。

综上所述

一个公司的埋点要可见、可控、可管，如果一家公司不清楚自己的埋点结构，便是在错误的数据上长期持续经营业务，越走越错。合理的埋点方案，可以使埋点能够智能调试和验证，大幅降低埋点采集的成本，从而最终达成数据质量的根本性提升。

作者：友盟全域数据；公众号：友盟全域数据（ID：umeng_data）

本文由 @友盟全域数据 于。，

，基于CC0协议