数据采集有多种方式,埋点采集是其中非常重要的一部分,不论对c端还是b端产品都是主要的采集方式。
数据采集,顾名思义采集相应的数据,是整个数据流的起点,采集的全不全,对不对,直接决定数据的广度和质量,影响后续所有的环节。在数据采集有效性,完整性不好的公司,经常会有业务发现数据发生大幅度变化。
数据的处理,通常由以下5步构成:
大体知道数据采集及其架构之后,我们看看工作中遇到的问题,有多少是跟数据采集环节有关的:
我们需要根源性解决问题:把采集当成独立的研发业务来对待,而不是产品研发中的附属品
所谓埋点,就是数据采集领域的术语。它的学名应该叫做事件追踪,对应的英文是Event Tracking 指的是针对特定用户行为或事件进行捕获,处理和发送的相关技术及其实施过程。
数据埋点是数据分析师,数据产品经理和数据运营,基于业务需求或者产品需求对用户行为的每一个事件对应位置进行开发埋点,并通过SDK上报埋点的数据结果,记录汇总数据后进行分析,推动产品优化和指导运营。
流程伴随着规范,通过定义我们看到,特定用户行为和事件是我们的采集重点,还需要处理和发送相关技术及实施过程;数据埋点是服务于产品,又来源于产品中,所以跟产品息息相关,埋点在于具体的实战过程,跟每个人对数据底层的理解程度有关。
埋点就是为了对产品进行全方位的持续追踪,通过数据分析不断指导优化产品。数据埋点的质量直接影响到数据,产品,运营等质量。
埋点的方式都有哪些呢,当前大多数公司都是客户端,服务端相结合的方式:
准确性:代码埋点>可视化埋点>全埋点
所谓的顶层设计就是想清楚怎么做埋点,用什么方式,上传机制是什么,具体怎么定义,具体怎么落地等等;我们遵循唯一性,可扩展性,一致性等的基础上,我们要设计一些通用字段及生成机制,比如:cid, idfa,idfv等。
在设计属性和事件的时候,我们要知道哪些经常变,哪些不变,哪些是业务行为,哪些是基本属性。
基于基本属性事件,我们认为属性是必须采集项,只是属性里面的事件属性根据业务不同有所调整而已,因此,我们可以把埋点采集分为协议层和业务层埋点。
Ev事件的命名,也遵循一些规则,同一类功能在不同页面或位置出现时,按照功能名称命名,页面和位置在ev参数中进行区分。仅是按钮点击时,按照按钮名称命名。
ev事件格式:ev分为ev标识和ev参数
规则:
ev标识和ev参数之间用“#”连接(一级连接符);
ev参数和ev参数之间用“/”来连接(二级连接符);
ev参数使用key=value的结构,当一个key对应多个value值时,value1与value2之间用“,”连接(三级连接符);
当埋点仅有ev标识没有ev参数的时候,不需要带#;
备注:
ev标识:作为埋点的唯一标识,用来区分埋点的位置和属性,不可变,不可修改;
ev参数:埋点需要回传的参数,ev参数顺序可变,可修改;)
app埋点调整的时,ev标识不变,只修改后面的埋点参数(参数取值变化或者增加参数类型)
eg:一般埋点文档中所包含的sheet名称以及作用:
A、曝光埋点汇总;
B、点击和浏览埋点汇总;
C、失效埋点汇总:一般会记录埋点失效版本或时间;
D、PC和M端页面埋点所对应的pageid;
E、各版本上线时间记录;
埋点文档中,所有包含的列名及功能:
用埋点统计数据怎么查找埋点ev事件:
根据ev事件怎么进行查数统计:当查询按钮点击统计时,可直接用ev标识进行查询,当有所区分可限定埋点参数取值;因为ev参数的顺序不做要求可变,所以查询统计时,不能按照参数的顺序进行限定;
体系化的指标可以综合不同的指标不同的维度串联起来进行全面的分析,会更快的发现目前产品和业务流程存在的问题。
人对图像信息的解释效率比文字更高,可视化对数据分析极为重要,利用数据可视化可以揭示出数据内在的错综复杂的关系。
3. 埋点元信息api提供
数据采集服务会对采集到的埋点写入到 Kafka 中,对于各个业务的实时数据消费需求,我们为每个业务提供了单独的 Kafka,流量分发模块会定期读取埋点管理平台提供的元信息,将流量实时分发的各业务 Kafka 中。
数据采集犹如设计产品,不能过度,留出扩展余地,但要经常思考数据有没有,全不全,细不细,稳不稳,快不快。