闲聊：
这世界实在是太美好了，作为被世界包围的人类难免不会想去多领略它的美丽，而这世界似乎也知道这点还特地为人类注入了勇于探索的精神，先人们身体力行地我们创造了一套可行的探索模式：先做信息收集从中找出规律最后提炼成通俗的知识。随之诞生了数学和各类学科。我们一直是通过对分析信息这一手段去解构世界以期消除不确定性和未知，同时可以让自己获得更多的掌控感和安全感，这一点在数据分析领域尤为重要，随着时间推移大数据技术越发成熟，我们已从只关注结果数据演进到更关注过程数据，并通过分析模型或者采用经验、问卷等方式以较费力的节奏逐一解答业务上遭遇的异常情况，在不久的未来必然会有更懂得信息加工和总结的机器人出现，帮助人类更高效地发现问题、解释问题甚至提出解决方案并自动修复，我似乎已经感受到这股力量正在崛起，在某一个地方开始灼烧并散发着耀眼的光。
埋点分析是当前能同时对产品体验、流量管理、创建用户行为标签等分析目的进行管控的有效手段之一，但其实真正用的好的案例并不太多。虽已有heart、ptech等成熟的分析模型，但其实这些模型都是将用户的行为抽象提炼成可描述性的指标而非用于解释问题的内因，所以鑫入以上一个或多个分析模型仅仅只是将分析课题从诸如“产品体验”这四个字变成了一堆可以量化的指标而已，这是远不能帮业务解决问题，而人处理数据的效率很低，当眼前出现一堆指标时并没有意义仍然需要解读。我们恐怕都遭遇过看着密密麻麻的指标陷入一片茫然的状态，那么假如再高阶一些的数据解读，比如我们应该尝试做指标之间的关联性解读，如ptech中的task success即任务完成率每提高了1%会对happiness中的留存率带来多大幅度的提升？又有多少人会有这种研究呢。所以在高效的自动化智能分析工具出现前，只能靠我们自己而非别人。我们不应盲目追求热门分析模型只是为了避免汇报难堪，而更应该基于运营目标、产品定位、品牌价值等角度先构建产品价值体系，比如应该服务10万用户，同时帮助他们由之前很长的查询流程简化到极少几步，且优化后让用户有更多精力去尝试体验其他的业务等。有了根据产品价值体系后再开始埋点设计，让埋点数据回归产品价值本身。
正篇：
我们已经明白埋点不是为了应付上层的噱头、也不该是别人做了所以我们也要做的产物。做埋点就是为了确认产品是否达到预期价值的量化手段。那么在说埋点设计注意事项前我们应该知道事件的生命周期。
一、事件生命周期
1、基础-命名
埋点和我们一样一般都有自己的英文名和中文名，比如Tom和汤姆。用户在实际发生交互操作后我们会采集英文名即Tom并同步到数据库，只采集英文不采集中文的原因是：英文在存储、计算方面具有低错误率，另一方面是中文存储成本更高。为了能让分析师在埋点分析平台快速配置计算规则，所以需要为英文事件名设定一个中文名（汤姆），也就是说中文名是英文事件的一种对人显示的属性而且可以是动态变化的属性，我们在分析平台内修改英文对应的中文，如将Tom的中文名从汤姆调整为躺姆或者杰瑞。
目前两种主流命名方法：每个页面和控件都分配独立事件以及合并同类项式的命名方案，比如首页上有icon模块，前者会命名为首页-icon点击，后者会命名为平台入口点击。
2、基础-维度
接着为了能真实、客观记录用户在产品内的操作内容就需要了解操作控件所在位置（页面+模块+按钮名称+排序+排序规则等）以及操作业务内容如产品/优惠券id、类目/类型、金额等维度就需要对事件进行横向补充，试想在首页弹屏模块中分别曝光100-10优惠券和100-90优惠券，点击和转化率会有显著差异，没人愿意通过根据排期表反推哪天弹的a广告哪天弹的b广告，更何况现在到哪儿都是分客群策略和算法推荐，没人能轻易知道用户实际看到的是什么内容，所以我们应该将这些有助于提炼运营价值的重要信息纳入采集范围。
3、上线
在埋点代码随app或h5页面首次对外后，埋点数据就开始记录用户行为数据直至对应页面内移除或者整个页面彻底下线时才会停止采集。数据入库后分析师将着手进行业务分析，根据预设的产品价值标准进行验证，根据产品设计动机对包括平台资源池争夺结果、核心路径转化、信息或异常引导、提效功能降低操作成本的效果等维度考核产品综合表现。
4、调整
在获取基于埋点分析得出的产品运营结论后，有可能会发现一些问题，此外业务团队可以通过诸如外部调研、400电话录音、网络舆情等方式获取用户使用反馈，于是产品就迅速进入了迭代优化的阶段。根据数据和外部反馈结论再对页面流程、样式等进行调整，改动大的可以是流程重构和页面重做、改动小的如新增小功能像icon由单一的图形改成gif动图或增加小标签和音效等、个别按钮文案/颜色/字体变更。可以说只要是有人重视这块业务，早晚会迭代。大多数情况下所有的调整改的是前端样式和后端逻辑，可以让用户更好地get到重要信息进行全面地决策，而产品的内核价值一般是不会改变的。页面一旦发生变动那么埋点也需要同步进行调整，好的埋点不仅仅会考虑当前采集的内容，还会兼顾后续将上线的内容，比如首页第一个icon是A业务，改版后变成了B业务，好的埋点会将变动的维度做成事件属性，这样不管这个icon下一次变成什么业务都会自动调接口返回实际的业务名称。
5、下线
随着业务有调整就可能导致某些功能被替代而下线，对应的页面和控件的埋点代码也一并下线不再执行采集任务。或者当某项分析已经达到预期效果，且该事件向后不再有分析价值也可以手动注释埋点代码缓解数仓压力。
二、埋点设计注意事项
1、得到结果：当然首先分析师得想清楚该产品该达到哪些预期的价值然后哪些数据或指标可以量化。埋点就是为了能解构用户对产品的理解程度和反应表现。比如业务方想知道每天用户都是从哪些入口进入到自己负责的场景，那么所有入口在被曝光或点击时就需要在事件属性内记录：该入口指向的业务名称或业务code，又或者用户在办理某一业务时会有n种分支，那么每一种分支都应该被标识和采集，否则转化率波动时你都不知道是哪个业务分支出现了问题。如果分析的高阶一些，可以给页面添加流程节点属性，专门记录:首页、详情页、确认页、成功页、失败页，然后用事件属性场景名进行展开，直接鸟瞰全部场景转化率。
2、便于统计：市面上的埋点产品都会提供数据分析平台，分析人员会经常在该平台内进行数据统计，此时如果设计的埋点过于零散则非常不利于配置，假设平台有100个入口，如果每个业务需要掌握每个月都争取到了哪些入口以及他们分别带来多少点击和交易量，如果统计时间足够长期间正好将100个入口都遍历了，所以极端情况下分析师可能要配置100个事件，要么在事件属性中添加是平台入口的标记，或者通过分析平台的功能将众多事件临时合并为一个事件，当然也可以直接在埋点设计时将该批入口统一成一个事件，采用所在页面名称、模块名、入口类型（固定、资源、推荐等），或者分为少数几个事件，比如产品推荐位采集的维度会包含产品ID、产品类型等属性，即和固定入口、资源位不一致，可以独立设计成不同的事件名。
3、命名继承：综上所述产品是一定会发生改版的，改动时可能功能逻辑没变但按钮的位置、样式、文案发生了变更，那么一定要确保事件英文名不变，同时代表业务内容的属性（也可以是事件英文名）也不能变更，比如【购买】改成了【去购买】，业务逻辑完全没有变仅仅是通过文案中添加了“去”字做强指引性，那么事件英文不能改动，同时业务属性如价格、金额等也不能变更。只有这样才能确保所有版本的数据都能参与计算和比较。如果要让分析师能在分析平台内准确筛选事件中文，那么事件英文不变前提下将事件中文调整为新的文案即【去购买】。
