用户行为简介
用户行为分析主要关心的指标可以概括如下:哪个用户在什么时候做了什么操作在哪里做了什么操作,为什么要做这些操作,通过什么方式,用了多长时间等问题,总结出来就是WHO,WHEN,WHERE,WHAT,WHY以及HOW,HOW TIME。
根据以上5个W和2H,我们来讨论下们如何实现。
WHO,首先需要x获取登陆用户个人的信息。用户名称,角色等
WHEN,获取用户访问页面每个模块的时间,开始时间,结束时间等
WHAT,获取用户登陆页面后都做了什么操作,点击了哪些页面以及模块等
WHY,分析用户点击这些模块的目的是什么
HOW,用户通过什么方式访问的系统,web,APP,小程序等
HOW TIME,用户访问每个模块,浏览某个页面多长时间等
以上都是我们要获取的数据,获取到相关数据我们才能接着分析用户的行为。
埋点一般分为无埋点和代码埋点。这两种各有优缺点,这里只做一个简单的介绍:
全埋点是前端的一种埋点方式, 在产品中嵌入SDK,最统一的埋点,通过界面配置的方式对关键的行为进行定义,完成埋点采集,这种是前端埋点方式之一。
优势:
劣势:
作为前端埋点会存在一些天然的劣势
代码埋点,这个也是目前我们使用的埋点方式,代码埋点分为前端代码埋点和后端代码埋点,前端埋点类似于全埋点,也需要嵌入SDK,不同的是对于每个事件行为都需要调用SDK代码,传入必要的事件名,属性参数等等,然后发到后台数据服务器。后端埋点则将事件、属性通过后端模块调用SDK接口方式发送到后台服务器。
我们采用的是代码埋点,分为前后端。埋点是一个特别重要的过程,它是数据的源头,如果数据源头出现问题,那么数据本身就存在问题,分析结果也就丧失了意义。
由于我负责日志检测,也就是埋点后的事件日志的检测告警,并通知对应的埋点开发人员,运营方,产品方,所以也就遇到了过其中存在的很多坑,大部分是流程方面的。
事件属性是有一套元数据管理系统,业内的一些服务也是这种结构。一般是先定义事件、属性,后埋点的方式,原因是事件日志数据是需要经过检查的,需要检查事件是否存在,属性是否缺失,数据是否正常等等。
遇到的坑:
有了上面的思路,下面我们来说下实现的相关技术问题,如何落地用户行为分析。
根据运营定义好的埋点接口形式获取到的用户的访问日志数据,一定要提前后端和前端定义好数据的保存格式,也就是保存哪些字段内容,需要把埋点数据按照约定的格式统一封装,以便于存储分析。
下面该数据采集神器Flume出场了。
实时的埋点数据采集一般会与两种方法:
那么Flume 采集系统的搭建相对简单,只需要两步:
flume配置模板:
a1.sources = source1
a1.sinks = k1
a1.channels = c1
a1.sources.source1.type = org.apache.flume.source.kafka.KafkaSource
a1.sources.source1.channels = c1
a1.sources.source1.kafka.bootstrap.servers = kafka-host1:port1,kafka-host2:port2...
a1.sources.source1.kafka.topics = flume-test
a1.sources.source1.kafka.consumer.group.id = flume-test-group
# Describe the sink
a1.sinks.k1.type = hdfs
a1.sinks.k1.hdfs.path = /tmp/flume/test-data
a1.sinks.k1.hdfs.fileType=DataStream
# Use a channel which buffers events in memory
a1.channels.c1.type = memory
a1.channels.c1.capacity = 100
a1.channels.c1.transactionCapacity = 100
# Bind the source and sink to the channel
a1.sources.source1.channels = c1
a1.sinks.k1.channel = c1
数据采集到HDFS后,下篇我们分享一下用户行为之数据分析。
历史好文推荐