Hi，各位看官老爷大家好，今天跟大家分享的主题是“初始数据埋点”，本文主要面向的对象是0-1岁刚入门或者即将入门的看官老爷们，本汪把自己实际工作中数据相关的经验写出来分享给大家，一起交流学习。

在流量红利基本消失殆尽的大背景之下，流量逐步呈现愈发明显的马太效应，智勇双全的前辈们遂提出了精细化产品探索之道，等各种方法论，通过数据分析团结一切可以团结的力量，利用可以利用的一切工具通过数据驱动产品迭代，通过数据驱动产品优化从而在激烈的同行竞争中杀出一条血路来，谋生存，求发展；最终通过数据始终在战略上比竞品（同行竞争对手）快一步，在战略上藐视敌人，在战术上重视敌人，让对手摸不着套路。

我们出一个新功能，如果竞品立即跟进就会陷入被牵着鼻子走的尴尬境地，慢一拍，即使是大团队有钱有人模仿的再快，跟上了迭代速度，如果没有看透竞品迭代的本质原因，数据逻辑，则很可能输掉整场游戏，从而让对手无法模仿，跟不上、看不懂—（surprise O(∩_∩)O~老司机的会心一笑）

基于以上背景首先培养的就是以数据思维驱动产品迭代，精细化产品探索，及时发现产品问题，持续优化，提升用户体验让用户用的爽、满足用户的深层次情感需求，来达到“大吉大利，今晚吃鸡”的目的。

文章背景

通过随机抽样调查，发现关于数据产品经理、数据分析、产品设计等关键词的单篇文章多如牛毛，不乏干货、或者大佬写的24K干货文章。但像每一篇文章只写一个点，每个点连成线写成一个系列，甚至组成一个面，让看官老爷能系统性的了解某一条线的系列文章却少之又少，看官老爷很难系统性的提升对某一个知识分支的认知，或者只能凭文章中提及的一些线索自己去探索，归纳（葛优瘫..生无可恋的看官老爷可能会说：我能怎么办，我也很无奈呀），就像：

1. 我听了好多大道理，但是依然过不好这一生。
2. 我看了好多恋爱秘籍，搭讪攻略，但是却依然找不到女盆友，比如本汪（双狗特效加持：单身狗+产品狗）buling buling…的效果是一样一样的。

基于知识点分散，系统性归纳整理低效的场景，面向0-1岁或者即将入坑数据产品的看官老爷，解决数据产品入门的问题，带来帮助看官老爷整体理解数据产品基础，系统性入门的价值。

文章更新规划

计划将实际工作中最高频的与数据相关的一些工作经验以及技巧与大家做一个交流沟通，初步计划整体分6-8篇文章、每篇1-2周的频率由外到里，由浅入深，并伴随实际工作中案例系统性的分享。根据看官老爷的反应调整后面要写的内容，以及更新文章的速度。

以上都是废话，分割线以下是重点。

———————————————我是可爱的分割线—————————————-

埋点概述

数据埋点是数据产品经理、数据运营以及数据分析师，基于业务需求（例如：CPC点击付费广告中统计每一个广告位的点击次数），产品需求（例如：推荐系统中推荐商品的曝光次数以及点击的人数）对用户行为的每一个事件对应的位置进行开发埋点，并通过SDK上报埋点的数据结果，记录数据汇总后进行分析，推动产品优化或指导运营。

埋点分析，是网站分析的一种常用的数据采集方法。数据埋点分为初级、中级、高级三种方式。数据埋点主流部署的方式有：

• 私有化部署（即部署在自己公司的服务器上，如果期望提高数据安全性，或者定制化的埋点方案较多，则适合私有部署，并开发一套针对自己公司定制化的数据后台查询系统保证数据的安全性和精确性，缺点是成本较高）。
• 接入第三方服务，比如国内的某盟和国外的GA（Google Analytics）统计，在以后的文章中会单独介绍，此处不再展开。（优点是成本较低，部分基础服务免费，缺点是：数据会存在不安全的风险，另外一个就是只能进行通用的简单分析，无法定制化埋点方案）

此处只展开初级：在产品、服务转化关键点植入统计代码，据其独立ID确保数据采集不重复（如收藏按钮点击率）；

主要的埋点事件分类：

点击事件：

点击事件，用户点击按钮即算点击事件，不管点击后有无结果；如下图红框标注所示，点击一次记一次。

曝光事件：

成功打开一次页面记一次，刷新页面一次记一次，加载下一页新页，加载一次记一次。home键切换到后台再进入页面，曝光事件不记；如下图页面所示，打开一次记一次。

页面停留时间事件：

表示一个用户在X页面的停留时长记为停留时长。例如：小明9:00访问了X网站首页，此时分析工具则开始为小明这个访问者记录1个Session（会话）。接着9:01小明又浏览了另外一个页面列表页，然后离开了网站（离开网站可以是通过关闭浏览器，或在地址栏键入一个不同的网址，或是点击了你网站上链接到其他网站的链接……）为了简单，我们把这个过程当做一个Session。

则最终小明在首页的页面停留时间：

（Time on Page，简称Tp）Tp(首页) = 9:01 – 9:00 = 1 分钟

如下图所示：

When？什么时间做？

产品经理的需求来源众多，可能来自一线市场人员，可能来自身旁油腻的领导。可能来自用户反馈的一条吐槽…无论需求来自哪里，首先要搞清楚的就是这个需求涉及的问题：

• 在什么样的场景下？
• 面向哪些目标用户？
• 解决了哪些问题？
• 带来了什么价值？

梳理清楚问题后，拆分问题：

• 哪些是主要问题？
• 哪些是次要问题？
• 重不重要？
• 紧不紧急？

将每个问题拆解后下一步就是带着PRD文档找亲爱的数据分析师童鞋与产品经理汪一起沟通，解决以下问题：

• 每个问题应该怎么量化？
• 量化指标是什么？
• 怎么通过数据定义每个问题以及整个需求的成功与否？
• 有哪些辅助指标？

定义好数据指标后，此时则需要数据产品或者数据分析师定义埋点。

同时为帮助各位看官老爷理解，可参考以下流程图：

How?怎么定义埋点？

无规则不成方圆，良好的定义规范可以帮助埋点相关人员更好的维护，以及理解，极高的提升工作效率，降低推倒重来的风险，基于此分享一份埋点的定义规范帮助各位看官老爷以后维护自己产品的埋点。

使用此规范后，本汪一人就可以维护一个APP版本（包含点击事件、曝光事件、停留事件）累计1500多个埋点，井然有序，完全不会乱。

（怀念那些加班维护埋点跑数的日日夜夜，让我与看门大叔成了挚友，结下了深厚的友谊。咳咳，此处应该有掌声…）

埋点分类概述：

• 首先从事件属性这个维度上分为三份Excel（点击事件表、曝光事件表、停留事件表）
• 其次每一个事件表中新建三份子表（Sheet）,以点击事件表为例拆分为：首页事件集合、列表页事件集合、详情页事件集合
• 每当APP发布新版本时，从上一个版本的埋点中做一份Copy,新版本中新增了哪些埋点，删除了哪些埋点？都用不同的颜色，或者时间标记进行标注说明。

真实环境中分类更为复杂，仅以上面例子说明分类思路，各位看官老爷可以根据业务需求做针对自己产品更合适的分类。

字段明细：

功能字段：

用于说明当前埋点是在哪个页面的哪个功能。例如：收藏功能，对应功能字段名：自定义为我的收藏

中文名字段：

用于描述X功能模块内X位置，例如起名叫：收藏功能-文章收藏

事件类型字段：

用于说明当前埋点是点击事件还是曝光事件还是其他

事件ID字段：

如果是自己公司开发的数据查询系统，则每一个埋点都对应一个事件ID，上线后用于拿着事件ID去后台取数使用。事件ID的命名规范：事件英文简写_哪一端的产品_产品名称简写_页面名称_模块名称_功能名称。

例如：点击事件_APP端_二手车_个人中心_收藏_文章收藏 对应事件ID==  click_app_2sc_ Personal Center_ Collection_ Article Collection

如果是用的第三方统计工具：例如某盟，同理定义好事件ID，上线后去X盟后台，输入事件ID查询相应的数据。

Key字段与value字段：

当一个埋点对应不同类型的多种位置的埋点时，则需要命名当前埋点的key参数与value参数，一个key可以对应1个value或者多个value,但一个value不能对应多个key.只能对应唯一的一个key  例如：二手车信息网站有2个关键按钮，一个是砍价按钮，一个是拨打电话按钮，但是在多个频道中每个频道都有多个砍价按钮多个拨打电话按钮，在这样的场景下就可以设计2个KEY值：

1. key01=source用于标记当用户点击了一次按钮后是在哪个频道的页面点击的这个按钮X value01=X1，value2=X2用于标记不同位置同属性的按钮。
2. Key02=type用于标记用户是点的砍价还是点的拨打电话按钮，例如：01value用于标记砍价按钮，02value对应的拨打电话按钮。

记录规则字段：

定义什么情况下触发埋点，例如：在列表页点击一次记录一次

备注：

用于描述当前埋点什么时间新增？什么时间修改过？原因？什么时间被删除？谁删除的？等信息记录，此处好多看官可能以为写不写无所谓，但是为了信息的完整性和可追溯性最好每一次变动都要备注。（认真脸）

结语：

本篇主要介绍了工作中埋点相关的基础，以及阐述了埋点在产品流程中应在什么时间实现，怎么实现，定义埋点时对应规则规范等细节内容，以期帮助各位看官老爷理解以及实践。

下篇预告：

如果各位看官老爷已经对埋点有了初步的了解，则下一篇文章会基于以上内容更深入一步，具体是实际案例分析还是涉及埋点方案的设计相关，或者各位看官老爷留言问题对应的解决方案，或者其他，敬请期待~

牺牲了给开发爸爸捏肩捶背的时间加一个周末，赶出了这一篇，如有错误之处还请批评指正。

不说了，先来两个葛优瘫，好累ヽ(￣▽￣)و

最后一句：以上我说的都是错的，只有适合你的才是正确的！

再加一句：各位看官老爷，如果您觉的本文对您有帮助，记得给个赞哦，(* ￣3)谢谢啦。

本文由 @Aaron 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash ，基于 CC0 协议