读书笔记: <<数据驱动 从方法到实践>>

看到 caoz 推荐了这本书, 赶紧买来读一读, 写一写笔记.

数据驱动的两个价值

我猜大家还是驱动决策方面做得多

痛苦: 埋点混乱, 常规埋错, 漏埋

看来大家都需要一个完善的埋点需求管理工具, 在英语流利说，我们这样管理数据采集需求 拿走不谢

无奈: 数据团队和业务工程团队配合困难

首先, 求"快", 数据分析让路产品升级
其次, KPI 驱动, 数据团队需求得不到重视

关于 数据分析让路产品升级, 书中给出的回答也足够日后拿来怼类似场景了: 没有数据支撑, 如何衡量产品做得是否合理?

关于 KPI 驱动, 数据团队需求得不到重视, 我觉得还是看老板: 老板的风格就是数据驱动, 天天跟业务方要数据, 你说数据团队的需求业务方配合不配合? 相反, 靠业务方主动根据数据反馈优化功能, 你怎么保证你找来的产品经理不是凭借自身感觉做事的"艺术家"? 数据团队作为业务支持部门, 还是要尽力避免"皇上不急太监急"的尴尬.

数据采集遵循法则

让数据驱动落地企业, 数据采集的质量将决定数据分析的深度. 其中, 数据源是最重要的.

这一点深有同感, Garbage In, Garage Out 法则. 在数据质量上我们也走了一些弯路, 花费了很多功夫. 还是很好奇 SensorData 自己的 SDK 是如何保障数据质量的.

数据采集的四个法则: 大, 全, 细, 时

• "大"强调的是宏观的大, 这不只需要海量数据, 还要从系统的角度去考虑
• "全"强调多种数据源. 对于用户行为分析来说, 不但要采集客户端数据, 还要采集服务端日志, 业务数据库, 以及第三方数据, 全面覆盖, 而且是全量数据.
• "细"要求把不同的维度都采集下来. 对于用户行为来说, 我们要采集 Who, When, Where, How, What 等信息. 如果缺失会导致重新采集, 延长迭代周期
• "时" 则强调时效性

实际工作中, "大"可作为宏观考量, 重点关注"全"和"细", 而"时"可以根据业务场景灵活把控, 毕竟数据的时效性是有成本的.

这个四个原则中, 全 细 时 我非常赞同, 并且也是这样实践的, 尤其后续总结毕竟数据的时效性是有成本的这一语道破真谛.
而关于大的描述, 我看着有些虚, 或许是境界不够吧.

无埋点优劣势分析

总结一句话: 一旦企业有复杂的分析需求, 就必须进行代码埋点, 否则数据无法进行灵活下钻.

前端埋点 vs 后端埋点

使用后端埋点会有一个问题: 维度采集的问题. 上文也提到数据采集要尽量细: Who, When, Where, How, What 都要带着, 但后端请求可能在当次请求时能拿到的维度信息不够(例如没有设备相关的信息等), 解决的办法也无外乎这几种:

1. 后续 ETL 的时候补数据, 靠 ETL 计算出用户 session 期间的设备信息, 然后补全到后端埋点数据中.
2. 在用户首次请求时保存设备 Context 信息到缓存中, 后续埋点通过缓存将数据补齐.

导致数据不准确的几个原因

1. 网络异常
2. 统计口径不同
3. 代码质量问题
4. 无效请求

关于 网络异常 代码适量问题, 我想解决的办法只有一个: 让最靠谱的工程师来开发这个 SDK, 并给充足的时间和耐心进行测试.

关于统计口径不同, 我的看法是统一口径是一个方面, 另一个方面就是方便阅读数据计算逻辑, 例如如果用 SQL 开发, 那么这个结果使用了哪些数据, 这些数据的来源是如何, 如何方便的看到代码, 开发过程是否有 code review, 这后面其实是整个数据开发平台工具链的建设, 非一日之功.

今天暂时写到这里, 改天继续.
-- EOF --