场景
对于产品经理，数据采集一般发生在:
1.新上线/优化某功能，验证功能效果，为后续产品方向提供依据；
2.现行业务是否正常稳定发展，监测有无出现异常；
3.其他部门提出了一些统计需求。
方法步骤
一.明确目的
因为什么原因要通过观察数据指标的表现来推断什么结果，这些指标怎么定义，需要取哪些值来进行计算。
1.新上线了一个阅后即焚功能，这个功能是为了提高即时交流和互动。
2.同比，环比核心业务数据，发现数据突然猛增，排查原因。
3.运营部门想要知道近两次拉新活动的效果。
二.分析需求
需要取哪些值，从哪取，谁来取，怎么取。
1.通过阅后即焚功能发布内容的触发统计，要能统计到总的内容数量和发起人数，发起时间，地区，发起人性别，年龄，频次，占总发布内容的比例。
阅读他人发布的阅后即焚内容的总人数，每条内容的总阅读数，总评论数，总点赞数等
2.新增用户数，活跃用户数等指标
3.活动页访问人数，注册人数，首次登录人数，次日留存人数，支付人数等。
三.梳理drd文档
注意:
(1)自已要理清需求:要啥数据，需要从哪些维度进行分析
根据套路尽量把需求想全:who when where how what:哪个用户在哪个时间点在哪里怎么样(以什么样的方式)做了一件什么行为(完成了什么具体的事情)。
(2)要可以给rd讲清楚需求:讲清触发时机，前端采集还是后端采集，是公共的属性还是某一事件的属性
选前后端的原则:后端可以取到值的都选后端，后端取不到值的选前端。
原因:后端的准确，前端因为种种原因要进行取舍，往往不可避免数据少量失真。
前端:调用api ，取页面上的值，行为统计(前端timer,自动触发&记录页面时长)
后端:业务数据，查关联表，前端送来的数据(存储)，技术数据(单次事件响应时间)
样例:
事件显示名 事件英文名 事件定义 属性显示名 属性英文名 属性值类型 属性定义 埋点形式 发布状态 上线时间 下线时间 备注
四.埋点数据验证
手段:抓包/后台查看
方法:与drd逐个对比，检验是否符合预期
意义:数据不具有回溯性，信息损失了，后续再也补不回来
其他场景埋点
全埋点/无埋点:比较简单的产品，比如就一个活动页，上面只有一个按钮。
跨跃物理限制的数据采集:比如重力感应货架
竟品数据采集:爬取展示出来的数据，计算得到想要的数据
比如想知道用户留存率:可以通过找到发布过内容的用户，看他们每个时间段是否有继续发布内容来推算留存。
