埋点—这一篇文章就够了

埋点—这一篇文章就够了

看见世界，贴近彼此，产品理应“壹佰分”。

​关注他

104 人赞同了该文章

来到公司第一件事，就是研发公司自己的埋点

为什么要研发自己的埋点

1、第三方埋点存在数据泄漏风险

2、第三方埋点无法支持之后的数据驱动，之后的AB测试系统，用户画像都需要我们自己的埋点才能实现

3、第三方埋点经常出现数据上报错误

4、第三方埋点每年支付大量现金

···

基于以上各个原因，开始开发自己的埋点

接下来通过以下三个方面讲解一下自研埋点

一、埋点埋什么

埋点埋什么取决于我们想从用户身上获取什么信息

一般主要分为用户的基本属性信息和行为信息

用户的基本属性信息主要包括：城市、地址、年龄、性别、经纬度、账号类型、运营商、网络、设备等等

行为信息即用户的点击行为和浏览行为，在什么时间，哪个用户点击了哪个按钮，浏览了哪个页面，浏览时长等等的数据。

以上说的就是一个简单的报文：

什么是报文

报文(message)是网络中交换与传输的数据单元，即站点一次性要发送的数据块。报文包含了将要发送的完整的数据信息，其长短很不一致，长度不限且可变。简单来说就是用户在App内有一个操作行为，就会上报一组带有数据的字段。这些字段组成一个报文。报文一般包含以下字段，简单举例，根据公司业务自行增删

{ "os": "js",
"os_vers": "端上的OS版本",
"dev_id": "设备id",
"model": "设备型号",
"manufacturer": "设备制造商",
"proj_id": "工程id",
"source": "渠道输入数字：1android_2ios_3H5_4小程序_5微信_6服务器后端_7QQ_100其它",
"proj_ver": "软件版本",
"up_time": "报文上传时间-毫秒时间戳",
"face_id": "事件全局唯一标识",
"accs_time": "事件发生时间,毫秒时间戳",
"serv_time": "服务器时间,毫秒时间戳",
"event_type": "view/click", "event_ver":"业务版本/事件版本
"ip": "290.39.55.75",
"longitude": "56°75.343",
"latitude": "143°07.230【非必填GPS关闭无法获取】",
"netwk_typ": "wifi/4G" },
"refer_id": "无埋点场景下所浏览页面的上一个页面的唯一标识",
"duration": "页面浏览毫秒数，关闭页面时统计",
"banner_id": "埋点自定义事件属性值",
"banner_name": "埋点自定义事件属性值",
"banner_type": "埋点自定义事件属性值",
"banner_city": "埋点自定义事件属性值" },
"usr_props": { "gid": "游客id", "uid": "登录账号", "province": ‘上海’】",
"city": "北京",
"city_code": "110",
"age": "22",
"sex": "1男_2女",
"phone": "13601197458",

解释一下这些报文的意思

1) trace_id为每个事件的全局唯唯一识别符，trace_id=md5(proj_id+source+accs_time+"salt盐")

• proj_id为工程id，accs_time为端上行为时间
• source为渠道来源：1android_2ios_3H5_4微信小程序_5微信环境_6服务器后端（只填数字）

2) 请求为post提交方式，header中需要添加：projId，source，upTime，uploadId 四个参数，uploadId=md5((projId+source+upTime+"salt盐")

• proj_id为设备id，upTime为上传时间
• source为渠道来源：1android_2ios_3H5_4微信小程序_5服务器后端（只填数字）
• 由于nginx中lua编程接收参数自身原因，header中的参数只能使用驼峰 projId，source，upTime,uploadId
• salt测试环境下为：test，salt正式环境下为：p1@PeFz4ZX

3）uid值在游客状态下为空，登录状态下有值；dev_id值在任何情况下都得传4）上面的报文为一次上报的报文格式，data中可以包括多次事件的信息5）基于客户端每次要使用客户流量才能获取$province，$city，ip，这三个字段保留，但是值为非必填。最终由后端根据请求ip和经纬度计算省市信息。6）报文中的json的所有的key可以不能遗漏，即使是value为空，如果是空值要用双引号""，不要用null。7) proj_id、sdk_ver、event_id，业务属性，必须按照产品需求保证对应关系，否则上报的数据会被丢弃。

二、埋点设计

在埋点设计时，要将客户端、m站等平台中

全部的页面及按钮按照规律清晰的罗列出来，

并为每个页面，每个按钮配置唯一的id

以此来区分每一个页面及按钮

以下埋点需求表仅供参考

 

 

这个埋点表中

第一列是App版本号

第二列是埋点上线状态

第三列是安卓或者ios端（因为有一些交互安卓与ios不同所以要做区分）

第四列是一级模块

这里直接说一下一级模块、二级模块、三级模块

一级模块

是指App下方的几个大的button即页面入口。

培优学而思App的 首页、选课、服务、我

是四个一级模块，每个一级模块都有自己的一个唯一id

图中一级模块是选课，id是固定的“11”

二级模块

是指一级模块下的全部页面

不仅仅是入口页面

入口页面下的 点击跳转的页面都算一级模块下的二级页面

比如课程列表页、详情页、购课单页、banner详情页····

每一个页面都有一个唯一id，这个id组成是该页面的一级页面id与页面id串联

图中选课首页的id为11-001、列表页id为11-002、详情页id为11-003···

这样给定一个id就可以查到唯一指定页面

三级模块

是指二级模块全部页面中的全部按钮

每一个按钮都有唯一一个id，这个id组成是一级模块、二级模块、三级模块的id串联

图中搜索框点击事件 11-001-001，

其中11是指选课一级模块

其11-001是指一级选课模块下的选课首页

其中11-001-001是指一级选课模块下的选课首页的搜索框按钮

这样每一个页面每一个按钮都有条理的排列下来了

其中bizinfo是业务字段

业务字段

是在用户点击或者浏览页面时上报的业务数据

比如banner点击事件，用户触发此事件需要上报banner-id，banner名称，banner城市、banner年级等

比如报名按钮点击事件，业务字段上报toast_value，这个toast_value是指用户点击报名按钮后的页面提示

可能是年级不匹配导致报名失败，可能是没有入学诊断导致报名失败，也可能报名成功

收集这样的业务字段为之后的业务数据分析提供保障

其实埋点表还需要有上报时机

这个上报时机是指用户在点击或者浏览页面后什么情况下进行埋点上报，存到数仓中

上报时机一般分为点击即上报 还有回调上报

点击上报很好理解

回调上报是指用户在点击或者浏览页面后有一个返回值，一般是由toast提醒后进行上报

通过设计如图的埋点表

进行需求评审

评审通过之后将其维护到业务库中

三、埋点系统

埋点系统主要功能

1、维护埋点事件及埋点事件ID。

比如我们增加了一个页面以及页面上全部的按钮，按钮点击之后的下一级页面

那我们需要生成好多埋点id

这个声场埋点id的功能就在系统中进行维护

2、数据异常报警

对于一些埋点数据不能正常上报，或者因为其他原因导致埋点数据丢失

通过埋点系统直观查看哪些点没有正常上报，第一时间进行检查

 

四、数据存储

数据从上报开始——Nginx——Filebeat——Kafka——Spark——Kudu

五、数据仓库结构设计

1、数据中心整体架构

• DB 是现有的数据来源(也称各个系统的元数据)，可以为mysql、SQLserver、文件日志等，为数据仓库提供数据来源的一般存在于现有的业务系统之中。
• ETL的是 Extract-Transform-Load 的缩写，用来描述将数据从来源迁移到目标的几个过程：
• Extract，数据抽取，也就是把数据从数据源读出来。Transform，数据转换，把原始数据转换成期望的格式和维度。如果用在数据仓库的场景下，Transform也包含数据清洗，清洗掉噪音数据。Load 数据加载，把处理后的数据加载到目标处，比如数据仓库。
• ODS(Operational Data Store) 操作性数据，是作为数据库到数据仓库的一种过渡，ODS的数据结构一般与数据来源保持一致，便于减少ETL的工作复杂性，而且ODS的数据周期一般比较短。ODS的数据最终流入DW
• DW (Data Warehouse)数据仓库，是数据的归宿，这里保持这所有的从ODS到来的数据，并长期保存，而且这些数据不会被修改。
• DM(Data Mart) 数据集市,为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据。面向应用。

2、数据仓库

数据仓库(Data Warehouse) 简称DW，顾名思义，数据仓库是一个很大的数据存储集合，出于企业的分析性报告和决策支持目的而创建，对多样的业务数据进行筛选与整合。它为企业提供一定的BI（商业智能）能力，指导业务流程改进、监视时间、成本、质量以及控制。

数据仓库存储是一个面向主题（移动的用户分析也可做为一个主题）的，反映历史变化数据，用于支撑管理决策。

特征：

• 效率足够高，要对进入的数据快速处理。
• 数据质量高，数据仓库是提供很多决策需要的数据支撑，DW的数据应该是唯一的具有权威性的数据，企业的所有系统只能从DW取数据，所以需要定期对DW里面的数据进行质量审，保证DW里边数据的唯一、权威、准确性。
• 扩展性，企业业务扩展和降低企业建设数据仓库的成本考虑
• 面向主题，数据仓库中的数据是按照一定的主题域进行组织的，每一个主题对应一个宏观的分析领域，数据仓库排除对决策无用的数据，提供特定主题的简明视图。
• 数据仓库主要提供查询服务，并且需要查询能够及时响应
• DW的数据也是只允许增加不允许删除和修改，数据仓库主要是提供查询服务，删除和修改在分布式系统.

3、操作性数据

操作性数据(Operational Data Store) 简称ODS，作为数据库到数据仓库的一种过渡形式，与数据仓库在物理结构上不同。ODS存储的是当前的数据情况，给使用者提供当前的状态，提供即时性的、操作性的、集成的全体信息的需求。ODS作为数据库到数据仓库的一种过渡形式，能提供高性能的响应时间，ODS设计采用混合设计方式。ODS中的数据是"实时值"，而数据仓库的数据却是"历史值"，一般ODS中储存的数据不超过一个月，而数据仓库为10年或更多。

特征：

• ODS直接存放从业务抽取过来的数据，这些数据从结构和数据上与业务系统保持一致，降低了数据抽取的复杂性。
• 转移一部分业务系统的细节查询功能，因为ODS存放的数据与业务系统相同，原来有业务系统产生的报表，现在可以从ODS中产生。
• 完成数据仓库中不能完成的功能，ODS存放的是明细数据，数据仓库DW或数据集市DM都存放的是汇聚数据，ODS提供查询明细的功能。
• ODS数据只能增加不能修改，而且数据都是业务系统原样拷贝，所以可能存在数据冲突的可能，解决办法是为每一条数据增加一个时间版本来区分相同的数据。

4、数据集市

数据集市(Data Mart)简称DM，是为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据（subjectarea）。在数据仓库的实施过程中往往可以从一个部门的数据集市着手，以后再用几个数据集市组成一个完整的数据仓库。需要注意的就是在实施不同的数据集市时，同一含义的字段定义一定要相容，这样再以后实施数据仓库时才不会造成大麻烦。

数据集市，以某个业务应用为出发点而建设的局部DW,DW只关心自己需要的数据，不会全盘考虑企业整体的数据架构和应用，每个应用有自己的DM

特征：

• DM结构清晰，针对性强，扩展性好，因为DM仅仅是单对一个领域而建立，容易维护修改
• DM建设任务繁重，公司有众多业务，每个业务单独建立表。
• DM的建立更多的消耗存储空间，单独一个DM可能数据量不大，但是企业所有领域都建立DM这个数据量就会增加多倍。

本文由 斑马 原创发布于产品壹佰平台，未经许可，禁止转载和商用。