数据埋点：用户做了什么，向服务器发送一条日志
埋点的最终目的是有能力观察及分析数据
埋点会遇到的问题
自己理不清：要啥数据/有啥属性
研发听不懂：前端采集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类的信息
线下数据收集
人体传感器/饭店收银台/超市重力传感器
电商：物流信息/客服跟进情况
教育：到课率/线下招生收集到的客户信息
金融：地推/短信发送的用户（与新注册用户对比，验证推广效果）
竞品数据采集
明确采集目的、爬取所需数据