接上篇《埋点&运营分析产品设计》之后，关于埋点方案还有一些不得不探讨的内容：为什么选择全埋点而不选择可视化埋点？埋点上报的内容格式是什么样的？高效的代码埋点应该有哪些规范和注意事项？结合项目的经验，拿出来与各位交流探讨一下。
为什么选择全埋点而不选择可视化埋点？
埋点方案对比
从上篇提供的优劣势对比中可以看到，全埋点似乎比可视化埋点存在更多的缺点，优势也不是特别明显。可视化埋点和全埋点都是通过圈选的方式实现了业务自定义埋点事件，保证了业务能够更高效的定义埋点事件而无需开发介入，唯一的不同点在于可视化埋点是“先定义后采集”，全埋点是“先采集后定义”。因此，全埋点相比可视化埋点多了大量的冗余，导致服务器成本高出一个数量级。我们当初选择全埋点的方案主要基于以下几点考虑：
1、业务变化快，网站前端经常做改版，每次网站前端改版之后，运营都需要重新定义圈选事件，如果选择可视化埋点的方案，意味着无法回溯历史数据，运营人员至少要在事件定义后两天才能查看到完整一天的数据。
2、全埋点的数据可用于计算部分常用的预定义指标，比如页面浏览量、访问量、人均访问次数/页数、跳出率等，这部分通用的指标计算用全埋点数据会更合适。
3、代码埋点的SDK往往是由网站开发人员维护，由于所谓的”大公司病“，经常出现网站发版没有及时通知到大数据部的情况，导致数据发版后出现丢失、错误的问题无法及时解决。这种情况下，全埋点可用于辅助代码埋点进行数据准确性的监控。
具体选用哪个方案，可以结合公司具体使用数据的业务场景和业务变化的频率来定，不存在最优，只有取舍。
埋点上报的内容格式是什么样的？
埋点事件上报的内容及格式，最早我们参考的是GrowingIO的文档，在规范化方面，商业公司做的非常优秀，以代码埋点为例，可以参考下图（截图来源于growingio事件体系实施方案_模板.xlsx）：
事件体系实施方案
需要注意的是：
1、数据一致性：
即便在事件管理层做了多租户管理，在同一个租户（可以理解为是同一个网站或业务模块，如淘宝--聚划算）内，还是要保证事件名称、变量名称的统一，避免出现同名不同义、同义不同名的情况。例如，同样是【商品】维度，在加购事件中上报的是goods_id，在付款事件中上报的是sku，在后端应用数据的时候，研发人员就需要对这些不规范的维度做二次清洗加工，开发效率低往往就是因为这样的细节问题导致。
2、数据准确性：
在流量数据的应用过程中，我们所遇到的最大的挑战就是多次出现异常后，运营人员会对采集的流量产生不信任。因此在埋点事件管理功能中，对于每个变量的字段类型、是否非空需要严格定义，如果可以，建议对字段长度、枚举值也定义清楚，这样会方便在清洗过程中就对数据质量进行监控。
高效的代码埋点应该有哪些规范和注意事项？
一、梳理业务场景
确定运营分析的业务场景，用最少的代码埋点满足业务分析需要。前篇有提到公司以前PC端的埋点采用的是元素级上报的方式，这种数据上报方式是从技术角度出发的方案，带来的问题也很明显：产品经理、运营人员不清楚埋点能支持哪些业务分析场景，埋点数据上报存在大量冗余甚至是脏数据。
业务场景梳理示例
缺少业务场景的元素级埋点除了数据冗余的成本外，主要有以下问题：
1、能上不能下：由于运营人员无法理解埋点的业务含义，因此当某项业务已经不再需要分析的时候，埋点往往不会停掉；
2、维护成本高：每次对业务分析场景进行调整，产品和运营人员需要重新梳理业务逻辑以确定各个坑位上报的业务属性，维护成本高；
二、从业务场景抽象化特定的变量属性
运营人员在分析过程中常常会做广告位、活动位、推荐位的销售归因，以此来确定不同坑位甚至不同类型产品的转化情况，调整运营策略。下面截取了一段埋点上报的事件变量json代码（公共变量未截取）：
{
"af_version_id":"",
"af_inner_mediasource":{
"name":"Search",
"search_type":"history_search",
"tab":"",
"type":"redmi airdots",
"keyword":"redmi airdots",
"goods_nums":31,
"rank":1
},
"af_bts":[
{
"planid":"1111",
"bucketid":"46",
"policy":"B",
"plancode":"androidkeyword",
"versionid":""
}
],
"af_content_type":"Bluetooth Headphones",
"af_content_id":"***",
"af_country_code":"***",
"af_filter":{
"category":"redmi airdots",
"sort":""
},
"af_currency":"USD",
"af_plan_id":"1111",
"af_inner":{
"name":"Search",
"search_type":"history_search",
"tab":"",
"type":"redmi airdots",
"keyword":"redmi airdots",
"goods_nums":31,
"rank":1
},
"af_price":"18.99",
"af_bucket_id":"46"
}
以上上报格式为例，需要注意以下问题：
1、减少数组嵌套：部分变量（如 af_inner_mediasource）是用数组格式嵌套了多个子变量，字段解析复杂，监控数据质量成本高；
2、减少个性化变量：针对某一个特定的需求，如【搜索转化】将需要的来源页面、坑位信息从首页透传到订单页，虽然短期内满足了分析场景，但未来针对【用户行为轨迹】等更加细致的需求，又需要增加新的事件变量来记录。
针对【搜索转化】【销售归因】【用户行为轨迹】等需求，本质都是要获取用户在网站的行为路径，因此需要在事件变量中传递行为轨迹字段（就简称轨迹字段吧），这里给出两种方案供参考：
第一种，每个事件的轨迹字段中都带有来源页面的信息，例如阿里的SPM编码：
示例： spm=a21b0.50862.201862-1.d1.5dcec6f7xfd1fj
结构：5段式 a.b.c.d.e
a：a21b0，代表站点或某大业务
b：50862，代表业务下的页面 ID
c：.201862-1，具体一个链接在页面中的模块，如：201862-1、201862是 Banner 位，-1是位置
d：点击的链接在模块内部的索引位置
e：按特定规则生成的 Unique ID
优点：前端上报压力小，不影响应用访问性能；可以拼接出完整的访问链路；
缺点：如果埋点上报阶段的丢失率比较高会导致数据无法追溯；需要前端对每个页面、组件配置唯一ID，对前端规范有较高要求。
第二种，每个事件的轨迹字段中将访问过的所有事件ID串拼接并透传到购物车、付款事件
示例：browse_path=“1001,1002,1003,1004,1005”
① 在所有事件中增加浏览路径browse_path（事件ID）
② 在埋点上报时添加自增唯一事件ID：event_id
③ event_id 需要针对不同设备单独维护
优点：通过自增唯一ID：event_id可以获取到事件的页面/组件信息，获取完整访问链路；无需依赖前端页面规范；
缺点：可能会增加前端上报压力，影响访问性能；
由于网站前期没有对页面、组件进行规范，上报埋点丢失的情况也比较多，因此我们退而求其次，选择第二种方案
以上是个人对于这一年以来对于埋点工作的一些思考总结，比较零散缺少体系化。希望大家对于文章内容中存在疑问、错误的地方也予以指正，对看到这里的各位表示由衷感谢。
网友评论