数据反馈，不仅能验证我们的产品是否符合市场的预期，而且还能为我们优化产品，迭代产品提供需求，建立产品的优化飞轮。

因此，数据分析是形成整个产品工作闭环中，必不可少的一环。

去年我们团队上线了一个新的产品，上线后，由于一直招不到合适的数据产品经理，因此团队让我先暂时支持下数据产品的基础工作。

于是，在这期间，我成了半个数据产品，在支持了一段时间的数据工作后，也建立了对数据的基本认知。

所以今天，我先从埋点开始，介绍下数据埋点工作过程中要了解的要点，同时补充介绍下，在数据分析工作中，可以直接应用一些分析框架和工作方法。

01

—

1、什么是埋点、事件、参数

埋点，是通过在程序中植入代码的方式，记录用户在软件（web、app、小程序）上的操作行为的技术手段。

事件，是记录用户在软件中操作行为的标签，如，用户在首页的曝光事件、按钮的点击事件等。

而在事件中，为了进一步区分事件的范围，更好地进行数据分析，会增加事件的“参数”，用来框定某个范围内的数据。如，时间参数、城市参数，就是用来筛选某个区间内事件上报数据的。

假如，我们要看到3月20日的产品首页曝光人数。

我们首先可以在首页中增加带有“时间”参数的“曝光”事件埋点。

在查询时，可通过代码在数据库中找到“首页曝光”这个事件，并在时间上选择“昨天”这个时间参数。

就可以得到昨天在首页曝光的用户数。

2、事件分类

事件是通过用户在软件中留下的痕迹，来进行统计和上报的。

因此，从用户痕迹获取的维度上来看，事件可分为：基础事件和行为事件

（1）基础事件是用户的属性标签，可用来建立用户画像的。如，用户id、城市、地址、年龄、经纬度、设备、ip地址、运营商、网络等信息，都属于基础事件。

（2）行为事件就是用户在软件上的行为标签。如，曝光pv/uv、点击pv/uv、停留时长等，都属于行为事件。而根据用户操作的行为，行为事件又可进一步细分出以下三类：

• 点击事件。指用户在软件中的点击，如用户在某个按钮、某个功能的点击，都记录为一次点击事件；

• 曝光事件。指用户打开页面的行为，如用户在某个页面上曝光一次，记录为一次曝光事件；

• 页面事件。指用户在页面中的操作，如，通过统计A用户在B页面停留时长；

3、埋点的方式

介绍完事件分类之后，我们再来看下埋点的两种主要方式：

（1）私有化部署，全部功能都自己开发，在代码中写入事件和上报逻辑，并搭建起相应的查询后台，埋点后，事件上报到对应的平台即可进行可视化呈现。

私有化部署的优势是：数据安全性高；且可根据业务需要，定制埋点逻辑；

但缺点也同样明显，就是不论是埋点开发还是可视化平台的搭建，所耗费的成本都比较高；

所以，一般只有大厂或相对成熟的产品，才会选择私有化部署的方案。

（2）第三方统计工具，如使用友盟、神策等平台工具进行埋点、统计和上报。

这么做的话，优劣势和自行开发刚好相反：通用化的方案，带来的结果是可自定义程度低，但成本也会相对较低。

所以，一般中小型企业或新产品，都会选择此方式，满足业务的基本数据诉求。

4、埋点工作流程

从工作流程上来说，埋点需要业务方先从拆解需求核心流程开始梳理，提出埋点需求；

开发团队根据埋点逻辑进行开发，开发完成后，测试团队进行上线前的测试；

上线之后，产品将数据的事件维护到表格中，而后，业务方才方便根据反馈的数据，定义数据，进行数据分析或可视化呈现。

因此，埋点也是数据采集和分析的基础。而在埋点开发到上线过程中，我们要注意以下几点：

（1）埋点方案，要保证埋点需求的合理性

随着数据维度的健全，所需的数据量也增大，因此需要埋点的事件也会越来越多，这是必然的趋势。

但因为埋点的本质是代码中加入代码，因此如果埋点的事件增多，也必然会导致软件加载速度变慢，影响用户体验。

所以，埋点需求一定要仔细审核，否则就是给后面工作挖坑。

因此，一般我在收集埋点需求时，都会让业务方在文档中尽可能明确的阐述，每一个埋点的意义和价值（尤其是曝光事件），否则不予上报。

以此来减少产品代码压力，提升产品使用体验。

（2）埋点测试，验证每一个埋点和参数的上报情况

测试，是保证需求上线后能够正常运转的最后一道关卡。

所以埋点开发完成后，除了测试要验证埋点是否上报上报之外，产品人也必须亲自确认，看数据是否正常上报、相关参数是否正常加入埋点。

（3）事件管理，要建立建全的统计维度

在埋点需求上线之后，我们也要建立事件管理的表格，以便后续在进行数据分析时，快速得到数据源

如上图所示，我们团队就是用表格中的这几个维度，来对所有事件进行维护和管理的：

• 场景id和场景名称：在哪个页面执行的埋点——id是代码层面的统计，名称则是后续查询的时候方便识别；

• 位置id和位置说明：在页面中的哪个位置写入埋点上报事件；

• 行为id和行为说明：主要是曝光、点击、停留时长等行为，用来区分用户的操作；

• 事件英文和事件中文：埋点的具体事件名称，我们一般是“场景”+“0”+“位置”+“0”+“行为”；

（除了“0”之外，也可以用“_”来连接，但不可用“-”，因为代码无法识别这个字段）

• 参数（key）：用来进一步区分当前事件下的不同维度，如表中所示，time代表时间——用来区分这个事件下曝光时间点，city代表城市——用来区分这个事件下的城市维度；

通过上述方式对事件进行管理之后，团队成员就能在文档中，快速查询到对应事件。

（4）事件更新同步

事件都写入维护表格之后，还有很重要的一步，就是一定要和各相关方，尤其是和业务关联的核心产品或运营团队，同步上报事件逻辑。

否则，在一定时间内，你的工作重心就变成天天帮他们找事件，解释每个事件意义...

一般在版本发布后，我们团队产品、研发和运营都会组织个上线会，同步版本新增功能，而我一般也会趁这个机会，给大家同步数据事件的更新情况。

数据分析

在埋点正常上报之后，我们就需要通过定期查看上报数据，来判断产品的数据表现情况。

1、核心指标：北极星指标

在进行数据分析之前，我们得先了解产品的核心指标，也就是“北极星指标”。

北极星指标，是产品在某个阶段内最关键的唯一指标，因为它像北极星一样指引着前进的方向，通过它能反映当前团队对产品核心价值的追求的指标。

因为每个团队业务不同，要关注的核心数据也不同。

如，电商产品，北极星指标或许是交易笔数，又或许是成交量；而社交产品，北极星指标是活跃用户数；

所以，北极星指标的制定，通常是由数据团队，产品团队，运营团队共同定义出来的指标。

并由此出发，进一步量化，并最终拆解成各团队的业务考核指标。

所以说，我们在工作中，也需要要时常关注团队的北极星指标，以此来判断我们的工作方向是否正确。

除此之外，同行业的产品在不同的发展周期，要关注的核心数据也会有所不同。

业务前期，目的是抢占市场，所以，业务要关注用户对产品的认可度，此时的北极星指标可从产品的使用量出发。

如，在微信上线初期，北极星指标是每日成功发送的消息数。

业务中期，目的是为了验证产品能否解决用户需求，所以，业务更应该关注用户结构，优化用户结构，此时的北极星指标可从用户活跃度出发。

如，Facebook就曾把月活跃用户数，作为北极星指标。

业务后期，目的是变现能力和市场份额，所以，业务核心是要关注产品转化量和收益，那此时的北极星指标，就可从营收情况出发。

如，爱奇艺当前的北极星指标，就应该是付费会员数；

2、发现问题：异常数据排查四步法

在产品基础数据能力搭建完成，且业务团队也定义了本阶段的北极星指标后，产品人要养成查看数据的习惯。

首先先关注产品每日核心数据是否出现异常，并尝试分析定位问题，这样才能及时发现产品问题，找到产品突破点。

刚支持数据业务时，我经常被我领导diss。

主要是因为我在定位异常数据时，没有掌握系统的方法，不能及时解决问题，导致产品隔三差五就会被用户投诉。

而在我定位了数十次数据问题后，终于总结出一套异常数据定位的方法论，主要分为以下四步：

（1）确认数据异常情况

如果有人告诉你说某个模块数据出问题了，叫你排查，一定要先自己核实数据异常情况，千万不能人云亦云。

其次，我们在定位问题时，要先尝试初步判断问题产生的原因。

可以先拉长时间维度，看是否是行业的淡旺季导致产品周期性变化，还是真的是产品数据出现异常了。

所查看后，确认是近期才发生的数据骤增或骤降的情况，我们再从宏观、中观、微观三个层次逐步排查。

（2）宏观社会因素：假期、政策影响

宏观的社会效应，是由于大环境的变换影响整个行业，导致产品数据突增或突降，如：

• 假期效应：国庆节，导致全国用户出行暴增，从而导致携程等旅游产品用户数据暴增；

• 政策影响：深圳政府7.15房地产制度，提出购房指导价，对整个深圳的房地产都产生了不小的冲击，进而导致贝壳买房app在2020年7月16日用户访问数据下降；

（3）中观市场因素：热点事件、大型活动、竞品调整、城市因素

中观的市场因素，是由于行业变化或短期市场波动导致的，如：

• 热点事件，今年315点名简历问题，导致智联、猎聘等平台品牌受损，用户访问量下降；

• 大型活动，双11、618等活动导致电商平台影响；

• 竞品调整，竞品上线新功能或新的运营能力，如爱奇艺上线超前点播功能，对优酷、腾讯视频用户产生影响；

• 城市因素，如某城市突降暴雨，导致该城市打车用户突增，滴滴的产品数据也猛然上涨；

（4）微观内部因素：产品功能更新，运营策略、数据分析逻辑通路

如果宏观和中观都排除之后，通常就是产品本身出现了问题，如：

• 产品版本迭代，产品上了新功能模块，导致某页面访问用户增加或减少

• 运营策略，如运营做了产品推广策略，导致一段时间内产品用户突增，但运营没有及时和我们同步活动的时间节点；

• 底层数据问题，如上报逻辑出错，导致多渠道数据埋点未能正常上报；

根据数据异常排查的经验来看，以上排查四步，可以有效解决90%的产品数据异常的问题。

3、工作前置：建立告警

可在实际工作中，我们不能等同事发现并跟你提出了问题，才思考解决方案。

这样不仅会打断自己的工作计划，而且无法从根本上解决问题。久而久之，我们就会变成整天忙于异常定位的救火队员了。

所以，为了减少异常数据发展成更为严重的产品事故，也为了提高我们的工作效率，我们可以在产品的核心流程中，增加告警上报机制。

之所以只在产品的核心流程中设置，是因为如果告警太多，维护的开发迟早会麻木的。一旦麻木，就失去了设置告警的意义。

比如，可以在用户支付流程中，对产生的报错码建立监控体系。

我们团队的规则是，当有大于5个用户拉起微信支付失败，即支付失败报错码出现报错次数大于5时，平台就会出发告警，并触达开发，让开发去排查和定位问题。

从而减少由于小范围的产品问题演变成影响大量用户使用的产品事故。

4、锻炼自己的数据感

告警机制只能解决核心产品流程的问题，但产品的组成，除核心流程之外，还有很多其他的功能也需要我们时常关注。

所以，除了系统层面的解决方案之外，我们自己也要养成看数据的习惯。

数据感，是我们在分析事情，或说服他人的时候，都能用数据来证明自己的想法；在看到数据时，会去思考数据的合理性与准确性。

培养数据感和产品感一样，都是需要我们长时间对数据的思考、沉淀和积累之后，实现从量变到质变的过程。

所以我们团队也会要求每个产品人，每天都必须抽时间看看产品的数据表现，我一般是早上9点-11点的时候，看昨天的数据日报。

虽然说刚开始看数据时，数据工作确实是一个无聊且枯燥的工作。

因为每天的数据无非就是突增、突降、正常，这三种情况，所以很多人会觉得很无聊。

可我们日常的数据分析就是要从这三种情况下，找到产品的优化点和破局点：

如果是数据突增，产品要思考能否趁风而起，提升产品指标；

如果是数据突降，可以从更长时间周期进行分析，看是周期性环境变化、稳步下降的产品原因、亦或是内部产品迭代导致的异常，进而提出优化需求或策略。

即便是每天都一样的数据，也能说明现在的产品策略，无法实现产品的稳步增长，产品也可以进一步调整产品策略。

因此，不论什么数据，都存在分析的价值和意义。

只有意识到这点，数据分析才算是真正入了门。