数据分析入门：初始数据埋点
在流量红利基本消失殆尽的大背景之下，流量逐步呈现愈发明显的马太效应，智勇双全的前辈们遂提出了精细化产品探索之道，等各种方法论，通过数据分析团结一切可以团结的力量，利用可以利用的一切工具通过数据驱动产品迭代，通过数据驱动产品优化从而在激烈的同行竞争中杀出一条血路来，谋生存，求发展；最终通过数据始终在战略上比竞品（同行竞争对手）快一步，在战略上藐视敌人，在战术上重视敌人，让对手摸不着套路。
我们出一个新功能，如果竞品立即跟进就会陷入被牵着鼻子走的尴尬境地，慢一拍，即使是大团队有钱有人模仿的再快，跟上了迭代速度，如果没有看透竞品迭代的本质原因，数据逻辑，则很可能输掉整场游戏，从而让对手无法模仿，跟不上、看不懂—（surprise O(∩_∩)O~老司机的会心一笑）
基于以上背景首先培养的就是以数据思维驱动产品迭代，精细化产品探索，及时发现产品问题，持续优化，提升用户体验让用户用的爽、满足用户的深层次情感需求，来达到“大吉大利，今晚吃鸡”的目的。
文章背景
通过随机抽样调查，发现关于数据产品经理、数据分析、产品设计等关键词的单篇文章多如牛毛，不乏干货、或者大佬写的24K干货文章。但像每一篇文章只写一个点，每个点连成线写成一个系列，甚至组成一个面，让看官老爷能系统性的了解某一条线的系列文章却少之又少，看官老爷很难系统性的提升对某一个知识分支的认知，或者只能凭文章中提及的一些线索自己去探索，归纳（葛优瘫..生无可恋的看官老爷可能会说：我能怎么办，我也很无奈呀），就像：
- 我听了好多大道理，但是依然过不好这一生。
- 我看了好多恋爱秘籍，搭讪攻略，但是却依然找不到女盆友，比如本汪（双狗特效加持：单身狗 产品狗）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值：
- key01=source用于标记当用户点击了一次按钮后是在哪个频道的页面点击的这个按钮X value01=X1，value2=X2用于标记不同位置同属性的按钮。
- Key02=type用于标记用户是点的砍价还是点的拨打电话按钮，例如：01value用于标记砍价按钮，02value对应的拨打电话按钮。
记录规则字段：
定义什么情况下触发埋点，例如：在列表页点击一次记录一次
备注：
用于描述当前埋点什么时间新增？什么时间修改过？原因？什么时间被删除？谁删除的？等信息记录，此处好多看官可能以为写不写无所谓，但是为了信息的完整性和可追溯性最好每一次变动都要备注。（认真脸）
结语：
本篇主要介绍了工作中埋点相关的基础，以及阐述了埋点在产品流程中应在什么时间实现，怎么实现，定义埋点时对应规则规范等细节内容，以期帮助各位看官老爷理解以及实践。
本篇将在之前介绍的基础之上，深入一步，详细讨论Key-Value字段的价值，以及灵活运用的方法。期望能帮助各位看官老爷基于业务需求在自己进行产品的埋点方案设计时提供一些解决问题的思路。
在第一篇文章埋点定义规范部分对应Key-Value字段没有向看官老爷交代清楚，本汪痛定思痛，面壁思过，还望各位海涵。在本篇中针对遗留问题做了详细的图文解释，还望之前留言的看官笑纳。
正文
在上篇中我们已经知道，一个完整的埋点需要定义哪些字段，回顾如下：
- 功能字段
- 中文名字段
- 事件类型字段
- 事件ID字段
- Key字段
- Value字段
- 记录规则字段
- 备注字段
写到这里，看官老爷可能会问：埋点中定义Key-Value有什么价值？接下来本篇第一部分的篇幅将与大家一起一探究竟。讨论到底Key-Value是做什么用的。
先写结论：
设计事件埋点时：
- 同种属性的多个事件，建议命名一个埋点事件ID，并通过Key-Value键值对进行区分。
- 不同属性的多个事件，建议命名多个埋点事件ID，不建议使用Key-Value键值对进行区分。
乍一看，可能有些晦涩难懂，以下将举两个实例，自然就能明白易懂。
实例背景：某汽车互联网公司，领导对负责新车业务的产品经理X君、负责二手车业务的产品经理Y君提出需求：对新车APP和二手车APP销售线索数据指标进行数据监控，如有超过5%的数据变动，则需要向上级汇报波动数值以及波动原因。
名词注释：
- 销售线索：通过事件记录到用户有明确的购买意向，记录行为的事件例如：电话咨询、短信询价、加入心愿单、收藏、特别关注等类型事件。记录一个用户即代表一个线索。
- 数据波动：即(（当日数据-昨天数据）/昨日数据)*100%=环比数据波动
根据领导需求，假设定义短信砍价按钮与电话咨询按钮为销售线索指标，销售线索按钮页面的入口来源页面包含：页面A与页面B。
X君与Y君分别设计了埋点方案，如图所示：
X君埋点方案：
X君经梳理得出，在商品详情页共计有两个按钮是销售线索的核心指标分别是按钮一：短信砍价、按钮二：电话咨询。并且有外部入口导流到详情页的有两个页面，分别是：页面A、页面B。根据流量来源的不同与事件类型的不同分为4个埋点事件，每一个埋点事件代表一种情况，如上图所示。
方案分析：
X君对每一种情况都单独设置了一个埋点事件ID，初步看上去还没什么问题，X君只需每天用这四个事件ID去后台搜索即可满足领导的需求：对核心指标进行监控。
假设随着业务的快速增长，新增更多的外部入口页面，由原来的页面A、页面B的2个入口页面增加至4个、8个、12个，同样随着产品优化需求的上线，新增更多的销售线索事件，由原短信砍价和电话咨询2个销售线索事件增加至4个、8个、12个。
在极限情况（12个外部页面入口、12个销售线索事件）下X均需要共计维护：
12*12=144个埋点事件ID。
假设分析场景：12个流量来源、12个销售线索事件，分析X天共计提交了多少线索？，来自页面A的有多少？
问题一：分析X天提交的销售线索中来自页面A的有多少？
解决以上问题，X君首先需要将流量来源是：页面A的12个不同类型销售线索埋点事件ID找出来求合算出数值。
问题二：分析X天用户共计提交了多少线索？
其次需要将剩下的11个流量来源各维度下12个不同销售线索事件的ID一一取出数据加上流量来源是页面A维度下的所有类型线索取出的数据，并进行最终求合算出X天共计提交线索数…写到这里，各位客官老爷可能会说：X君好累啊~，其实不仅累，并且会带来严重效率问题：
- 产品经理自身的工作效率会极大的降低，埋点事件ID越多，效率越低，最后极限情况下会无限逼近于零效率、零产出。
- 埋点事件无论是普通埋点还是关键核心指标埋点，不仅产品经理需要监控自身产品健康情况，兄弟部门像：数据运营同事、数据分析同事都会基于部门需求对产品进行数据分析与监控，如果像刚才这种情况，数据运营同事每周写数据周报时，单单是一个埋点事件就要计算12个流量来源进行求合，效率极低，会严重拖累运营同事的工作效率。并且对于数据分析师来说，假设在统计整体的销售线索指标时，如通过X君定义的埋点进行分析，在写查询语句SQL时，单是事件ID就要写144个，（大家脑补下数据分析师有节奏的拷贝事件ID 144下时这个画面），数据分析时会毫不犹豫的说：“来来来，X君我有事找你谈谈~~”可能有的看官会说：一个按钮用一个埋点事件ID记录就好了，不用区分页面流量来源，那问题来了：当数据产生异常波动时怎么确定是哪个页面的流量入口的流量变动导致最终的结果？
- 由于每天产品经理需要大量的埋点事件ID来统计一个指标，导致工作效率低下，可能会让领导对你产生工作能力差，产出效率低下的不好印象…
那客官老爷会问：那怎么办？稍安勿躁，马上揭晓，请继续向下看。
Y君埋点方案：
首先Y君对于销售线索有关的内容从各个维度，按照逻辑关系进行拆分，梳理出以下脑图：
写到这里就不卖关子了，基于思维导图中的逻辑关系，Key-Value闪亮登场！！！
Y君基于思维导图中的逻辑关系，使用Key字段表示分析的维度，使用Value字段表示不同维度下对应的唯一参数标识，从而将每个维度下众多不同的参数区分开来。通过Key-Value与同属性事件ID的配合，像销售线索这个指标就可以用一个事件ID来表示。在未来即使扩展N个外部入口流量页面，也只需要在当前事件ID在表示流量来源Key维度下在首次开发时新增N个Value参数即可。在未来应用于数据分析时，只需要搜索或写一个事件ID即可对各维度（Key）下不同参数（Value）进行分析，简介、高效。
例如假设分析场景：12个流量来源、12个销售线索事件，分析X天共计提交了多少线索？，来自页面A的有多少？
问题一：分析X天提交的销售线索中来自页面A的有多少？
Y君只需在后台查一个事件ID，并指定维度Key=指标来源（source）、Value=对应维度下参数为：页面A，最终求出的结果，即代表来自页面A的总数。
问题二：分析X天共计提交了多少线索？
同理，Y君只需要写一个事件ID，并指定维度Key=指标来源（source）,Value=无。最终查询出的结果即代表总的线索数。
注释：
- 当不指定Value时，默认为包含该维度下所有参数（本例中即代表所有来源）。
- 各位看官可能会问：当不指定Value参数，且不指定Key维度，Key=无，Value=无 时，对最终总线索数有影响吗？答案是没有。
- 同理，一个事件ID，指定Key=其他的维度，例如：Key=指标类别（type）,不指定Value参数，例如Value=无，对最终总线索数统计有影响吗？同理答案是没有。
Y君通过梳理逻辑关系，将同属性的埋点事件使用一个总事件ID表示，结合Key-Value细分不同维度下的不同参数，方便日后数据分析。通过此方式很好的解决了X君面临的问题，不仅如此，并且具备以下优点：
- Y君的维护成本低，更加简洁，新增时只需要首次开发时加一个Value参数即可。
- 提高Y君自身、数据运营、数据分析师等兄弟部门在数据分析时的工作效率。
- 扩展性好，对未来新增业务需求有良好的扩展性。
相信介绍到这里，大家对埋点事件中Key字段、Value字段配合使用带来的价值已经有了一定的了解。当然如果不同属性的埋点指标还是建议分开，一个属性定义一个事件ID，不能将八竿子打不着两种属性的埋点强行捆绑在一个埋点事件ID上,为了用Key-Value而用Key-Value，生搬硬套，最后只会适得其反，没有实际意义。
例如：在实际业务中，将用户点击“注册账号提交”按钮的行为放在销售线索这个属性事件ID中也通过Key字段、Value字段进行区分标识。结果没有参考价值，更没有实际意义。
综上所述，得出在正本第一篇幅中给出的结论：
设计事件埋点时：
- 同种属性的多个事件，建议命名一个事件ID，并通过Key-Value键值对进行区分。
- 不同属性的多个事件，建议命名多个事件ID，不建议使用Key-Value键值对进行区分。
各位看官老爷可根据自己产品的实际业务需求灵活运用，希望对大家在进行埋点方案设计时提供一些逻辑思路，帮助大家解决实际问题。O(∩_∩)O~
总结：
通过上一篇文章的基础理论铺垫，以及本篇中对埋点Key-Value字段的进一步介绍，涉及埋点方案规划的内容已基本讨论完成，期望本文中涉及埋点的篇幅能够帮助0-1岁的产品老爷在工作中规划以及维护埋点时提供一些逻辑思路，以及针对不同情况下解决问题的一些方案。
使最终交付的产物具备良好的扩展性、健壮性、易用性、高效性、可维护性等特性，以达到使自己以及兄弟部门花最少的时间成本获得最高数据价值的目的！
作者：Aaron
既然来了，说些什么？