作者简介:
谭子健:达达集团大数据和算法应用部数据产品,负责达达集团流量相关的产品规划及设计。
前言
随着达达集团的发展,产品线增多、功能丰富、运营细致,这些导致每个版本的埋点需求量都居高不下,因此我们引入“天河”埋点管理平台来对埋点流程和质量进行把控。本文侧重从埋点需求管理平台对各角色的合作模式改进和思考,同时兼顾埋点查询和数据报表的应用场景使用,希望对大家有所启发和帮助。
现状及痛点
目前集团内外部存在多条不同类型的产品线,其中以to C的京东到家埋点最为多样和复杂,京东到家经过4年的发展,主要采用代码埋点+服务端埋点方式,线上运行常规埋点数量已超万个,参与的角色也较多。到家埋点是通过线上文档来进行管理的,随着业务模块的增多,不仅埋点的数量在在提升,复杂度也相应提升,部分模块的埋点需求往往涉及到曝光、点击、PV、甚至API等多种埋点类型一起实现。虽然线上文档能够实现信息在多人之间的沟通,但仍然会以下困难:
1.使用困难:除亲自参与埋点设计同学,其余的人对埋点不熟悉,检索难度大,无法快速查询。且受限于人力和时间的缘故,还存在线上文档维护不及时的情况;
2.缺乏规范:在线文档没有强一致性,相同的需求可能用不同的字段来表征,增加后期数据清洗成本;同时也可能出现重复埋点,冗余埋点等等问题,这些会使研发判断难度增加,沟通成本上升;
3.管理混乱:在线文档并非一个强交互流程,提交及确认都需要人为通知与干预,面对人数较少的项目尚可应付,一旦项目人数较多,沟通成本呈指数型上升。这对埋点项目的管控造成极大的困难;
4.缺乏验证:线上埋点的文档只能提供需求,对埋点的验证缺乏有效的支持。
基于以上问题,达达大数据团队搭建天河埋点平台,实现数据埋点流程化、自动化管理,提升埋点效率和质量。在经历几个版本迭代之后,已经可以实现了全站埋点管理,并探索出与之配套的全流程的管理规范。
明确平台目标
在需求调研之后,项目组总结了天河埋点管理平台需要完成的目标:
1.需先定义埋点流程和参与的角色,制定与业务匹配的埋点开发节奏和流程,在此基础上开发埋点管理平台;
2.天河平台必须遵循现有的埋点技术框架,兼容现有的埋点框架页面、点击(跳转协议替代的点击)、曝光、API的埋点发送规范,以避免对数据层和研发层造成工作量上的较大的改动;
3.天河平台中的埋点设计、研发、查询应使用同一套字段规范,即非结构化的埋点需求文档必须转化成可被查询的结构化的埋点条目,便于后期直接按需求查询埋点数据;
4.天河平台需提供实时单条明细验证和T+1统计性验证两种验证形式;
5.天河平台需支持多系统便捷扩展,最好能实现系统权限管理和安全信息隔离;
制定埋点流程
磨刀不误砍柴工,要解决以上这些挑战必须先制定埋点流程和规范,只有与之相契合的平台才能发挥最大效能,如果缺乏埋点流程和规范,不仅权责不明,天河平台的能力范围与产品边界也无法得到确认。因此,制定如下埋点流程规范:
架构与产品功能
4.1 整体架构
天河平台的目标是规范埋点及保证埋点可查询,基于对该目标定性和埋点流程的拆解,我们进行了如下的架构设计:
4.2 产品功能
天河平台的产品功能主要分三大功能:①埋点需求管理、②埋点大全、③数据报表;其余支持模块:④埋点配置、⑤首页、⑥帮助
4.2.1 埋点需求管理
该模块主要是用来管理埋点需求,控制埋点需求的提交、审核、开发至最终上线。所以包含埋点需求提交,埋点需求设计,埋点开发,埋点测试共4个阶段。
step1:埋点需求提交
为用户提供便捷的埋点需求填写模板
在需求收集阶段,产品会收集该模块数据使用需求,这些需求主要包含2个维度:①埋点种类:页面信息、点击信息、曝光信息、后端埋点;②埋点种类基础上区分颗粒度包含:资源位位置、资源位房间、AB标签,新增功能的参数,常规的转化漏斗埋点等,这些信息异同主要体现在参数异同上。
所以,为了保证埋点应收尽收,天河平台提供了埋点需求包的阶段,由某模块的统一收口人将埋点需求录入需求包内,需求包中必须明确埋点种类和业务必须的参数信息。这样的埋点需求包一来能用于存档查看,二来保证埋点需求质量。
埋点需求设计
实现埋点格式统一和埋点需求个性化之间的平衡是该环节的首要任务
埋点的设计是天河较难实现的环节,考虑到埋点现状,天河在该流程设计做了多方的兼容和改进:
旧版本兼容性:对合理的历史埋点规范进行兼容,保证历史数据可查,避免数仓底层逻辑改动;
保证埋点可读性:平台无需对常规必选字段进行设计仅设计与需求相关的字段,保证埋点设计文稿的高可读性;
埋点可查询性:统一埋点设计规范、埋点开发规范、数据库规范,保证埋点设计的参数设计,无需转换能够直接被使用为埋点查询条件。
实现特殊化埋点设计:为了缓解流量日志上报的压力,天河对部分埋点规范设计做了特殊的定制。如曝光数据的整合上报与拆分,页面替代点击事件上报,前后端埋点组合上报等。
埋点开发
保证研发能够顺畅阅读埋点设计文档,提升开发效率
埋点经过审核之后,需求包将会拆分成原子粒度(分平台、页面、版本粒度)进入需求池,用户可以根据相应的模块自主创建埋点需求开发包,领取相关任务进行开发。
埋点测试
提供线上日志和埋点设计文档快捷比对工具,保证测试准确度
该阶段的主要任务是将埋点的自测结果与线上结果进行比对,验证该条埋点是否已成功触发,如果成功触发则将该条埋点状态置为验证完成,当需求包内所有需求验证完成后,该需求包的埋点将自动归档。
4.2.2 埋点大全
作为埋点成果展示窗口,既要展示关键信息也必须考虑可阅读性,不至于让用户在绕晕了头。通过对用户需求的分析和拆解,天河平台提供2个产品功能:
用户需求
产品经理:当做埋点字典和备忘,这点很重要,因为对于产品来说,并非所有的产品经理都有时间和经历写出完美的埋点文档,如提供一个固化模板,稍微了解即可快速上手;
分析师:对于分析师而言,关心的埋点参数是否清晰准确,做到这点就能为分析师取数&与各方核对数据逻辑节约95%的时间;
埋点设计:用作查询埋点设计文档,主要用于复盘和历史需求的查询及核对。
产品功能
埋点大全:提供最新版本的埋点命名,对应参数,可直接用于查询;
埋点历史:告诉用户某个埋点在每个版本的迭代和改动情况,一般用于查看历史更迭。
4.2.3数据报表
数据报表的功能是通过查看埋点数据趋势和关键维度的下钻,可以实现分城市、平台、版本维度下的准实时趋势查询,用以预估趋势和数量级并验证数据。
4.2.4 其他模块
其他模块是保证埋点正常进行的支持模块:
应用注册:天河已兼容多个内部系统,实现接入即查询的效果,只需要4步即可完成应用注册并查看数据:①提交应用申请;②告知接口信息等关键信息;③管理员完成审核确认;④T+1日数据流配置成功开始使用。
版本管理:用于标记埋点上线的版本;
页面管理:用来统一规范页面名称,保证用户埋点需求准确的表达。由于京东到家有多个平台,而各平台之间的命名规范各不相同,在天河中对相同页面不同名称映射为统一的PageCode,并为该页面打上群组的标签,供后页面分析使用;
操作审计:记录每个用户的操作,用于对用户敏感操作的审计,可实现历史操作记录追溯,保证信息安全;
首页:该模块主要包含快捷入口及重要信息的提示,旨在帮助用户快速上手,降低使用难度、便于项目管理;
帮助中心:模块的介绍、名词定义、最佳实践、等常见问题解释;
平台现状
天河平台自上线后,迭代了4个小版本,经历了双11大促、415周年庆和618大促等P0级别的大促,没有出现线下转移至线上引发的流程问题。平台接纳不同业务线大大小小共23个系统,涉及页面数超过3000多个,事件更超过上万个,目前仍在持续接入中。
未来发展
未来,为了保证埋点准确和便利性,天河平台有以下改进方向:
流量数据闭环的入口:作为数据闭环入口,集合包括埋点需求管理、应用日志管理、埋点数据源管理等相关流量数据管理平台,便于用户使用查询;
更丰富的数据看板:当前仅有页面和点击趋势查询,远远满足不了用户进一步的看数需求,后续将会补齐曝光和后端埋点的查询;并且提供埋点明细报表,通过设备号或用户id快速定位的用户设备实现埋点明细查询。
自助验证及自动预警:数据验证是埋点质量的守门员,目前都通过基础的数据看板和人工的取数服务来验证埋点质量,这种方式实现成本高,见效慢,后期如果规范好底层数据接入,配置需要验证的字段,实现即配即验的效果。对于重要数据的大幅波动除了实时看板被动触达之外,还可通过企业即时消息、邮件主动触达;
支持多系统自主管理:随着接入的应用越来越多,单一的管理员不仅在埋点工作量、业务熟悉度上都存在瓶颈,可以通过权限的分配为每个业务线(或业务类)分配一个管理员,实现各业务线自主管理。