实习过程中接触了埋点工作，参与了埋点的设计、评审、验收，对一些相关经验进行了总结。
什么是埋点
埋点是将用户在App或者网页上各种行为记录下来并且上报的机制。埋点能够记录用户的行为路径，帮助我们从数据角度一窥用户习惯和用户体验。
埋点方案设计
在接到一个埋点需求后，要进行以下步骤
- 与需求方（产品/运营）确认所需要指标的明确定义，讨论指标是否有意义、是否可行。
在设计埋点方案前，通常要先和产品/运营过一遍需求prd，了解整个产品/活动的流程。有经验的需求方一般已经列出了所需指标和定义，但需求方往往站在产品角度而不是数据角度，所以一些定义可能会不够明晰。如一个节日活动中要统计“参与活动的pv、uv”，怎样算是“参与活动”呢？与需求方沟通后定义为“在活动页面有点击行为的用户数”。
- 根据指标初步设计埋点方案
明确指标后，就可以进行初步的方案设计。埋点方案实际就是对其中的事件、参数进行定义。根据我的经验，主要关注以下
- 事件
常见事件：曝光、点击、浏览、下载、激活 - 公共参数
一级页面(ref)、二级页面(sub_ref)、详情页(detail/…)、来源页面(from_ref)、页面路径(refs)
页面是区分打点位置的重要标志，这些参数在埋点方案中一般必不可少，需要给出定义。 - 私有参数
私有参数和业务有关，根据业务需求而定。本部门的业务中，私有参数主要和页面结构有关，即明确了ref后，进一步明确在页面的哪个位置打点。对一个以卡片组成的页面，常见的参数如下
card_title; card_position; item_name；item_type；item_position；
页面结构ref>card>item，以这种方法定位打点位置 。不是每个参数都需要定义，具体的参数使用方法具有一定的灵活性，依业务情况而定。
比如对某页面第二个卡片模块的“开始下载”按钮打点
ref = "regularEvent_'
card_position = 1;
item_name = "start_download'
item_type = "button"
-
与开发核对
设计方案交付开发后，需要和开发进行沟通，确认方案的可行性。一些不能实现的功能需要和产品拉齐，一起寻找替代方案。从这点看，埋点工作设计产品->数据->开发，需要沟通的部分会比较多。 -
埋点验收
在开发埋好点后，需要数据同学对埋点情况进行验收。常从两个方面进行验收。(1)通过测试机和埋点平台测试打的点是否符合方案。（2）若埋点已有数据返回，则取出返回的数据进行查验，查看用户整个行为链路的数据是否正常。比如若出现漏斗数据倒置则说明存在问题。
什么是好的埋点方案？
层级明确、链路打通、参数规范、简洁方便。
实习中有幸见到了两套打点体系，其中一套及其混乱，基本是想到哪里打在哪里。比如它完全没有层级意识，一级页面、二级页面、tab页统统定义为ref；此外也没有用以标志用户行为路径的参数（from_ref /trace_id等）；参数值的定义方式也随意改变。这些都给数据使用造成了不便。
好的埋点应该能够便捷地进行数据查询，串起用户的整个行为路径，用数据来反映出我们关心的用户行为，