数据埋点:用户做了什么,向服务器发送一条日志
埋点的最终目的是有能力观察及分析数据
埋点会遇到的问题
自己理不清:要啥数据/有啥属性
研发听不懂:前端采集or后端采集?/跨越前后端取值?

数据采集方式:线上、全埋点/无埋点、线下、竞品

线上数据采集【数据需求文档(Data Requirements Document)】

  • 明确埋点需求:归纳需求(产品自身的指标建模/业务部门的分析需求)
    明确需求之后,考虑需要哪个指标来衡量需求,进而选择适当的埋点属性【需求→指标→埋点】
  • 选择适当的埋点属性
    依据经验,预先按分析维度设计属性(依赖分析经验,频繁添加埋点,需要研发密切配合)
    根据套路,预先设计埋点属性(WWWHW)
    Who When Where How What某个用户在某个时间点、某个地方以某种形式完成了某个具体的事情
    Who:认设备/认人
    认设备:web(cookie)/IOS(UUID/IDFV/IDFA)/Android(UUID/Android ID)
    认人:UID/微信等第三方UID/手机号/身份证
    When:哪个时间
    哪个节点的时间?事件发生-事件上报-事件接收-事件入库
    哪个时区的时间?上报时间时带时区/使用Unix时间戳
    Where:哪个地点
    GPS:获得的是经纬度,往往需要通过API取得详细的地址信息
    IP:统一分配给运营商,相对比较粗略,可通过第三方查所属地
    自主填写:相比用户真实位置,更关心用户希望在哪(租房/买房/装修)
    How:什么形式
    用的什么设备?/装的哪个版本?/操作系统是什么?/用的什么浏览器?/流量还是Wifi?/从哪个页面来的?/…
    What:什么事情
    购买:买了什么(商品名称)/什么类型(商品类型)/买了多少(数量)/花了多少钱(金额)/付款方式/…
    搜索:搜索关键词/搜索类型/…
    用户注册:注册渠道/注册邀请码/…
    用户投诉:投诉内容/投诉对象/投诉渠道/投诉方式/…
    申请退货:退货金额/退货原因/退货方式/…
    Who/When/Where是公共属性,不同的模块最好采用一种取值方式,便于后续合并分析/维护
    事件聚类:比如说有很多个模块可以完成支付,事件统一命名为支付pay,然后埋点一个position属性表明在哪个模块支付的
  • 前端采集or后端采集
    除非某个行为只在前端发生,否则都建议在后端采集
    前端埋点的弊端
    某些属性前端没有/改动依赖产品发版/事件上报时机略尴尬
    埋点属性的来源
    前端:调用API/取页面上的值/行为统计(计时器/页面浏览时间)
    后端:业务数据/查关联表/前端送来的数据/技术数据(单次事件响应时间)
    埋点有效性的校验(数据不具备回溯性,信息损失了就没了)
    抓包/看数据平台是否显示对应事件/与DRD逐个比对,核验是否符合预期
  • 埋点文档的常用字段
    事件编号/事件英文变量/事件名/事件定义
    属性英文变量/属性名/属性值类型/属性定义
    埋点属性当前状态/埋点行式/上线版本/上线时间/下线时间/备注常见值

全埋点/无埋点=把所有浏览和点击行为都记录下来
适用场景:分析需求简单(只需要统计PV和点击)/开发限制因素多(临时活动/没时间部署埋点)/业务流程简单(只需要点击/跳转)
技巧:可将本来能在一页完成的流程拆成多页来实现全埋点采集
限制:非浏览和点击事件无法采集到what/how类的信息
线下数据收集
人体传感器/饭店收银台/超市重力传感器
电商:物流信息/客服跟进情况
教育:到课率/线下招生收集到的客户信息
金融:地推/短信发送的用户(与新注册用户对比,验证推广效果)
竞品数据采集
明确采集目的、爬取所需数据

文章来源于互联网,如有雷同请联系站长删除:数据采集

发表评论