碎碎念：文中有个别应该是从其他地方拿过来的，没有记录出处，加上自己的一些经验想法，做记录，并拿来分享。
背景：
从使用者的角度，用户行为数据分析的前提是在前期埋点时打好扎实的基础。埋点触发的条件、需要追踪的属性以及想要分析的维度，这些核心分析要素设置的好坏，将会直接影响到你们在分析时的体验。错误的埋点触发条件，混乱的属性名设置，以及重要属性的遗漏，都会影响分析的效率与准确性。
某某活动当时数据如何，需要用哪个事件去查询，事件名是什么，有好几个支付订单，我该用哪个。我想按照支付方式，这里怎么有多个属性都叫支付渠道？我们可能会发出很多让人头疼的疑问。。
从研发的角度，
面临来自使用者的问题，这个事件是什么意思，那个属性是什么意思，怎么都没数据？某某事件什么情况下采集的？怎么没有某个事件，我该怎么分析某功能的参与情况？之前负责埋点的开发离职了，新的开发卖面对新的需求，吭哧吭哧了解历史当前埋点情况。。。。。
种种上下游链人员的协作，人员的流动，让人模棱两可的埋点，几近崩溃的发问。就没有好用的埋点么？怎样可以减少不必要的沟通。好的埋点，一定是清晰的，规范的，系统的，完备的，易懂的，可追溯的，需要维护的。那么如何构建好的数据埋点方案呢？
本文分享些埋点过程中的小技巧
埋点基础规范建议
埋点设计的小技巧
属性设计的小技巧
埋点更新迭代记录
埋点基础规范的建议
主要是规整的格式，事件和属性命名，用户标识的规范
1.1 以规整清晰地格式记录的埋点方案
使用文档来记录埋点方案，是相当好的使用习惯，但如果在记录时结构不够系统，内容过于杂乱的话，那么文档的作用将会大打折扣。建议在构建文档时注意结构的规整以及内容的清晰，可以按照XXX建议的如下格式来构建埋点文档：
字段说明：
研发负责人：开发埋点的同事。用于研发记录自己的工作进度。也方便业务同事找对应研发确认及修正埋点。
是否完成：如果项目十分庞大，且版本迭代频繁，那么有必要在文档中记录哪些事件是已经完成、哪些事件还在埋点中、哪些功能尚未上线，这对于了解项目进度会很有帮助。
优先级：用来标识该事件的重要程度，对于庞大项目来说，优先级的标识会很有帮助。
所属模块：建议按照产品的系统与玩法模块来进行埋点。
事件名：埋点时使用的事件名。
事件中文名：事件的中文名，应和后台设置的映射名一致。
属性名：埋点时使用的属性名。
属性中文名：属性的中文名，应和后台设置的映射名一致。
属性类型：属性的类型，有需求可以添加。
属性示例值：取值的枚举、易混淆属性的解释以及难理解属性的说明等。
是否为公共属性：标识该属性是否是公共属性。
触发条件：埋点触发的条件，对于理解事件的意义很有帮助，也可以帮助使用者排查埋点是否正确。
数据负责人：设计埋点的人。主要是确认是解决哪类业务需求的。以及校验埋点是否是需要的，准确的。
以上的格式是推荐示例，可以根据实际情况进行修改。请注意，进行文档记录的核心目的是将有价值的信息规整地汇总起来，以便项目成员的理解、沟通和分析，在进行文档记录时要牢记这一点。
1.2 事件及属性命名规范
1) 事件命名规范
事件英文命名通常采用snake命名法（即单词全部小写，单词间用“_”分割）或驼峰命名法（由一个或多个单词连结在一起，第一个单词以小写字母开始，从第二个单词开始以后的每个单词的首字母都采用大写字母）。
当产品较为复杂，涉及到多个业务线或小组协作时，建议优先采用 snake 命名法，方便标记事件所属业务线。
首先，需要确定事件英文命名法达成内部统一；
其次，在事件的命名组成上可遵循：
一般情况下，采用“行为动词_行为名词”或“行为动词”的形式，例如：get_code、login；
特殊情况下，采用“行为名词_行为动词”的命名方式，例如：login_result；如事件命名中带有 click 或者 view ，则采用“行为名词_行为动词”的命名方法，以 click 或 view 结尾，例如：search_result_click；
若涉及多业务数据接入时，如果某用户行为属于某业务线独有事件，在以上规则基础上，在事件名中增加业务线前缀。例如：xx(业务线)_detail_view。，
2) 属性命名规范
一般来说，建议属性英文命名使用snake命名法，即：单词全部小写，单词间用“_”分割。在属性的命名组成上可遵循：
通常使用名词的形式。例如：product_id, product_type等。
同一属性允许在不同事件中复用，但需保持全局属性设计的一致性。
1.3 用户标识的规范
匿名id：不同端的匿名分别是什么，设备id：安卓端-安卓id/IMEI？IOS-DFA/uuid？web端-cookieid，ip+UA。
唯一登录id是什么？业务id？格式是什么样的？
Oneid是什么？有没有idmapping，方案是怎样的。
这些最好都是有说明。方便使用的人了解。
埋点设计的小技巧
主要包括：埋点的顺序，埋点的抽象原则，埋点设计的原则和建议，埋点设计思路。
2.1 从整体到部分，按照各系统、玩法模块的顺序进行埋点
根据业务线，不同系统，不同模块来设置埋点的思路，这么做的好处在于三点：
1）一是从整体到部分。为了方便各业务线灵活查看平台整体数据、各业务线的数据及对平台的贡献，这时候需求是共通的。我们需要将共通的需求设计为同一事件。但各自业务线或者系统模块，又有独有的需求。所以分别为业务线/系统共享事件，和独有事件。
2）二是按照各自模块设计埋点，可以避免埋点的遗漏，对于玩法复杂、系统庞大的项目而言，能够帮助快速理清思路；
3）三是对于同一模块的多个事件，一些属性实际上是通用的，因此在设计埋点的时候，应该将这些事件设置为同一个属性，根据模块设计埋点可以很好让你发掘哪些属性可以被多个事件共用。
2.2 事件抽象原则
事件可具象可抽象，抽象原则可总结为以下两方面：
1）对于全局性的事件，建议设计为同一事件，通过特定的属性值对特定操作进行区分，而不是针对每一个操作设计一个事件。例如：产品内宫格区、轮播图、公告栏等不同运营位的点击事件可以抽象为一个事件——“运营位点击”，再通过此事件所附带的属性 “业务线名称”、“运营位类型”、“运营位序号”、“内容名称”等字段区分用户是对哪一个运营位的什么内容进行了点击操作。
2）对于相似场景中的事件，有两种设计思路：
设计为同一事件。适用场景：各事件所需属性相差不大，平时分析场景多为整体分析。
设计为不同事件。适用场景：各事件所需属性相差很大，需要频繁分场景查看数据。如果采用本思路，也建议在一些相同属性上用一样的属性名称，便于今后使用“虚拟事件”的功能进行整体分析。
2.3 事件设计的原则和建议
1) 为了节约使用成本，应该从需求出发(包括监测需求，分析需求，指标需求，标签需求等)，只记录那些会分析到的事件。埋点是为了详细地了解用户谁。是如何使用产品的，用的怎么样。对于暂时不会分析到的那些使用情况，可以暂时先不记录。
2）为了方便分析有些事件尽量不能省，也需要适当牺牲些成本。比如某福利活动有多5个档位奖励，有一个档位是点击后可以获得积分。积分来源会有很多渠道，我们会分析积分的获得消耗情况。在分析活动每档位参与情况，我们需要有积分获得事件，其中积分来源是一个属性。在分析活动参与时，我们最好有个事件叫活动参与，其中活动档位是一个属性。虽然一个动作会产生2条事件，但方便我们日常分析。所以2个事件都是必要的。
3）埋点的数量不应过多，以实际使用为主。一些类似的用户操作，可以合并成一个。参考上述共有事件，事件抽象原则。
4) 事件不仅局限于用户在 App、Web 界面等前端的操作和使用，一些其它类型的用户行为，例如用户的电话投诉、用户在线下接收服务、用户在线下商家进行消费等，如果能够获取到相应的数据，并且数据分析也会用到，则也可以作为相应的事件。
5) 关于既可以前端又可以后端采集的，建议除非某个行为只在前端发生，对后端没有任何请求，否则，永远只在后端收集数据。原因如下：
很多行为，如下单等，他们的很多字段在前端（App 和 Web 界面）是拿不到的。甚至有些行为，如用户线下消费等，前端根本就没有提供相应的功能，就更拿不到对应的数据。
后端修改程序更加方便便捷，如果是在 App 端记录数据，则每次修改都需要等待 App 的发版和用户更新；
App 端收集数据会有丢失的风险，并且上传数据也不及时。App 端为了避免浪费用户的流量，一般情况下，都是将多条数据打包，并且等待网络状况良好以及应用处于前台时才压缩上传，因此，自然会造成上传数据不及时，很有可能某一天的数据会等待好几天才传到服务器端，这自然会导致每天的指标都计算有偏差。同时，由于 App 端可以缓存的内容有限，用户设备的网络连接等问题，App 端收集的数据目前也没有太好的手段保证100%不丢失。
2.4 埋点思路
根据业务路径和关键影响因素梳理设计事件
1）梳理路径信息：根据需求方需求梳理对应的用户核心行为路径，初步整理要埋点的事件。
2）明确属性字段：明确事件的关键信息和重要影响因素，事件上报时需要采集哪些属性信息，包括行为描述信息、访问端标识、业务线标识、功能模块标识、登录状态标识、用户属性等。
3）明确埋点形式。数据采集方案中也要定义该事件是前端上报还是ETL导入，前端具体指Android、iOS、H5、Web、小程序等客户端，ETL导入指从业务库中导入相关数据。
4）事件触发的时机。 是在点击支付的时候上报事件，还是在支付成功的时候上报事件。时机不对，获取的数据肯定也跟想的不太一样。
5）根据业务需求，补充其他埋点，避免遗漏。
3、属性的小技巧
主要包括，公共属性，所有属性汇总，属性名易懂，属性类型的注意点。
3.1 将重要的属性设置为公共属性
当你需要分析多个事件时，可以根据这些事件共有的属性，也就是这些事件的属性交集，作为维度进行查看。一个常见的例子是，当你想要进行渠道分析，并且所有的事件都有“渠道”这一属性时，你可以便捷地选择“按渠道维度”进行查看。因此将重要的属性设置在每个事件中就显得相当重要了，如果你使用客户端接入，那么建议你将这些属性设置为公共属性。
如果你根据系统模块来设置埋点，那么应该优先关注那些与KPI相关的属性，诸如平台、渠道、区服，是否登录状态、当前会员等级、VIP等级等等，像这样的属性，在设置的时候可以不去考虑具体的事件，而只需考虑哪些属性更重要，也就是说就算有些事件中该属性是冗余的、无意义的，也应该将其设置进去。同时如果有新的事件需要追踪，也需要将这些属性添加进去。
3.2 将所有的属性汇总起来
相较于理解事件的意义，使用者更可能在理解属性意义时犯难，因此埋点的设计者最好将所有的属性汇总起来，便于排查属性设置的问题。可以参考下述给出的建议格式构建你的属性汇总文档：
3.3 保持属性意义的独立
建议你将多个事件中具有相同意义的属性进行合并，但需要避免让一个属性在不同的事件中承载不同含义，比如说level在一系列事件中指代“用户等级”，在其它事件中又代表“难度”或“层数”，这样的属性设置使得中文名只能写上所有的含义，而使用者在进行分析时就必须去猜测这个属性到底指的是哪个含义，这就显得相当不便了。
实际上这个问题的本质是不同事件的属性重名，通过属性汇总文档，很容易就可以排查出这一问题，而解决方法也十分简单，只需更改其中一个事件中的属性名即可。
如果你的项目比较庞大，很容易频繁出现重名的情况，可以在这些属性名前加入模块或者事件的名称，比如login_type，pay_type，enter_type,等，即可有效避免属性重名。
3.4 属性的类型最好与实际操作相匹配
大多数情况下，属性的类型不会对理解产生太大的困扰，但仍有可能出现这样的情况：使用数值型来表示布尔值时，可以使用0与1、1与2或者-1与1等多种方式来指代“真”与“假”，对于使用者而言，需要花费时间确认项目中使用的是哪种方法，另外还有可能出现同时使用两种方法的情况，使用者的理解成本又会因此上升，所以最好直接设置成布尔型。
另外，对于诸如“商品ID”“关卡ID”等以数字表示但无计算需求的属性，建议你将这些属性设置成字符串型。这是因为属性的类型决定了其在分析时可进行的操作，不同类型可进行不同的操作，这样设置既避免了无意义操作，比如计算“商品ID”的总和，同时增加了有意义的操作，比如使用正则表达式查找“道具ID”。
综上所述，建议你根据属性的实际意义以及具体的操作来设置类型，布尔型优先使用布尔型，需要进行计算的使用数值型，不需要进行计算的设置为字符串型。
3.5 如果大多是中国人用，属性值能用中文尽量用中文。尽量保持同一语种。
对于可以用中文来表示的属性，建议尽可能地直接使用中文，比如，描述用户来源的页面，你可以直接用homepage,也可以用中文”首页”，这种情况下，最好还是用中文名。不然还需要去查询对应是什么页面。另外，如果有多种语言版本时，属性值采用同一语种，然后增加一个属性当前语言来区分是什么语种。
4、埋点更新迭代记录。将所有的改动记录下来
主要包括：事件的变更，属性的变更。可记录在采集方案文档说明页。
产品随着版本的更新迭代后，一些事件可能会删除，同时，也会产生新的需要追踪的事件。由于后续的事件变动-比如触发时机或者属性的变动不会在老的事件上，因此任何事件的更新，都会导致前后数据的剧烈变动，可能造成异常的假象。在删除事件时，我们记录事件下线原因。在原有事件需要变更时，这种情况下，最好是增加新的事件名。如果延用老的事件名，则需要记录前后的触发时机及版本变化。
同样，随着需求的更新，一些属性可能会失去作用，同时也会产生新的需要追踪的属性。由于后续的属性变动不会作用到老数据上，因此任何属性上的改动都会导致前后的属性不一致。
为了避免增删改事件和属性对历史数据的分析造成影响，请将所有的改动都记录在文档中，当某个事件或属性被弃用时，请不要将其从文档中删除，而是通过底色或者字体颜色或者备注等方式标注出该字段被弃用。这样能够保证在分析过往数据时，仍能查找到所有事件和属性的意义。
最后：在构建了完备、清晰的埋点方案与记录文档后，就可以快速的进行用户分析，行为分析，留存、漏斗、行为序列，路径等等或者用户洞察，从数据中挖掘能够推动用户快速增长的有效策略。埋点做好这些，就形成了我们的很重要的埋点资产，打造了坚实的数据根基。
看到最后的都是最棒的，周末愉快~欢迎留言私聊，加油~
