手机版 欢迎访问人人都是自媒体网站
先谈谈埋点吧——用户行为分析的数据来源(通俗些就是格式化,以表格形式展示的目标日志数据)。
战士上战场,莫得子弹 就是一个死——分析者是战士,数据就是子弹,埋点就像制造子弹的机床。
就我所知,目前大部分企业获取用户行为大数据最好的方式就是在各终端设置埋点。目前使用的是全埋点的策略——也就是终端框架内,所有可交互的元素在触发时都会被采集。
(好像5W一下子都有了)
How采集元素目前主要分为四大类:页面采集(Page)[弹窗的弹出也可以归类为页面元素上报]、按钮采集(Button)、输入框采集(Input)、列表曝光采集(Expose)。
所有希望数据入库的事业部,必须严格按照上报入库流程与格式,传入数据,并给出相应注释。
这是目前整个大数据侧埋点入库的基本框架,他对所有事业部都一视同仁,保证了行为数据入库的规则性(觉得此处用“规范”,力度欠缺)。
规则性这个定义,在我的职业(还有学习,生活)生涯中真的很重要,很重要,很重要。特别是对数仓这样一个承载各方海量数据,且经常出现跨系统关联的载体来说,严格遵循入库规则是重中之重,否则就是一场灾难。
好了,再细说一下埋点采集与数据上报:
1. 页面采集(Page)用户每打开新页面都会上报一次页面访问记录(重新打开同一页面也会再次上报)。该条记录上报的内容是前端预先设定(有上报需求来源于业务侧),通常由页面上报名称和其它通用上报字段组成。通用上报字段因为是共有字段,我们最后一起说。来看看页面上报名称的设计,我的心得是:千万!不要!让前端自己决定! 如果你希望你的数据来源一团浆糊 Whatever
页面ID上报结构:A_B_C_D:用这种层级下划线连接的方式,定义上报ID,就很清晰。如:page_id = BUSA_acp_home
定义:A业务线下,页面上报类,首页 的页面上报。
2. 按钮采集(Button)用户每点击一个按钮都会上报一个按钮点击记录。该条记录上报的内容是前端预先设定(有上报需求来源于业务侧),通常由页面上报名称和其它通用上报字段组成。
按钮ID上报结构:btn_id = BUSB_acb_{prod/other/outer}_Alist#1_Productid 我仍然在用的一种按钮上报方式,体验不错。
定义:B业务线下,按钮上报类,{商品类,功能类,对外导流类 三种按钮类型 选其一},按钮嵌在A列表的第二个位置(智能推荐,千人千面,此处仅代表单个用户的情形),按钮的产品号。
3. 输入框采集(Input)记录用户在文本框输入的任何信息和动作。包括你与意中人交流时时,反复斟酌句读,辞藻,踌躇犹豫的矛盾心理,在此处都能记录得明明白白。
输入框上报结构:1:我稀饭你很久噜,做我女朋友中不 /2:我稀饭你很久噜 /3:一起吃个饭吧 / 4:你在做什么?你到家了嘛
——直男聊天案例 定义:首先输入了1,删除部分输入后到2,增加输入到3,4等等。
连带你的初始输入,删除,撤回……曲折的心路历程还有总输入时间,都会被记录且细化到毫秒级。所以不要再质疑企业能获取你的生日/身份证号/密码等信息,数据安全真的全靠自觉(以及草票)。
4. 列表曝光采集(Expose)简单讲就是给用户看到了哪些元素。因为智能匹配或着死规则匹配的普及。每个分类的客户都会被给到企业认为合适的行为路径(哪一类的用户被推荐哪一类的产品,跳转哪一个页面早已被商家安排的明明白白 )。
列表曝光上报结构:按钮ID,所在列表,所在页面以及其它通用上报字段。
定义:页面下曝光了哪些列表,这些列表中又展示了哪些按钮元素,分别在第n个位置。
5. 能采集到的东西肯定不限于此(Other)能采集到的东西肯定不限于此(Other),终端位置,APP版本,终端内其它APP。。。只有你想不到~
#附上通用字段:
上报/采集时间
来源业务线
来源终端 APP/微信/官网
来源渠道
经纬度,等等。
这个业务侧可以根据业务需求增加多个,个性化很强的上报,放在同一个json格式的字段即可。
Whytips:上面说的一些东西应该是对大数据自研比较看重的公司,才会考虑到的事情,使用三方BI服务或者对数据监控,分析要求一般的企业may不用care这个。
Copyright © 2018 DEDE97. 织梦97 版权所有 京ICP