LZ-组6 全员答辩公共知识手册（v1）
用途：帮助四名成员统一项目事实、表达方式和答辩口径。
适用人员：黎钊恺、吴锐锋、贾天宇、康奕。
使用原则：公共内容人人都要会；个人主责部分需要讲得更深入；无法确认的历史过程不要临场编造。
1. 每个人要掌握到什么程度
1.1 必须记住
- 项目解决什么问题，最终交付了什么。
- 原始数据、清洗后数据、用户数、商品数、字段数、分析主题数等统一数据。
buy表示购买行为事件，不应直接说成真实订单。- 金额、订单、渠道、设备、地区等字段中哪些属于固定规则生成的模拟数据。
- 数据从原始文件到流水线、数据库、Streamlit 和 Metabase 的整体过程。
- 自己负责的板块、与谁进行了交叉检查、自己的看板展示了什么。
1.2 需要理解，不要求逐字背诵
- 27 个字段的四类来源及其用途。
- 25 个业务分析主题如何形成最终数据表、数据库查询入口和看板。
- 为什么不直接让 Metabase 查询一亿行明细。
- 主要指标如何计算，结论有哪些适用范围。
- 项目经历了哪些版本，为什么要迭代。
1.3 由主责成员重点掌握
- 黎钊恺：总体架构、Plus 流水线、部署、数据口径、版本演进和最终整合。
- 吴锐锋：清洗过程、数据质量、指标检查、过程记录及流量与转化分析。
- 康奕：可视化设计、看板布局、图表表达、截图和展示材料。
- 贾天宇：用户机会、商品机会、关联推荐和运营建议的解释。
2. 项目介绍的统一说法
2.1 30 秒版本
我们围绕电商用户行为数据完成了一套从数据处理到业务展示的完整分析项目。项目对一亿多条原始行为记录进行清洗和扩展，形成 27 字段的统一分析数据，并按 25 个业务主题生成可直接查询的结果。最终成果已经部署到服务器，通过 MySQL、Streamlit 和 Metabase 展示，四名成员共同参与看板制作，并分别负责数据质量、分析、可视化、推荐和项目整合等工作。
2.2 2 分钟版本
任务书要求我们完成数据采集或接入、数据处理、分析、可视化以及推荐或运营建议。我们在此基础上进一步做成了一条可以重复运行的数据流水线。
首先，我们接入 9 个原始数据分片，共 100,150,807 条用户行为记录。Plus 自适应 Windows 数据流水线负责识别文件、清洗异常数据、统一时间和字段规则，并扩展出 27 个字段。清洗后保留 100,095,182 条记录，排除 55,625 条不符合统一规则的数据。
然后，流水线围绕流量、转化、时段、用户、商品和机会识别等方向生成 25 个分析主题。Plus 企业后台把这些结果整理成 plus-release_006 发布版本，并导入 MySQL，形成 24 个固定的数据库查询入口，共 25,067 行汇总结果。这样 Metabase 展示的是已经整理好的主题结果，而不是反复扫描一亿行明细。
最后，团队使用 Streamlit 和 Metabase 制作展示页面。四个人都参与了 Metabase 看板，但各有主要方向，并通过指标复核、图表复核和统一发布形成协作闭环。项目不仅完成了任务书要求，也增加了可重复运行、版本记录、质量检查、服务器部署和多端展示等成果。
3. 必须统一的数据事实
| 项目 | 统一数据或说法 |
|---|---|
| 原始行为记录 | 100,150,807 条 |
| 清洗后记录 | 100,095,182 条 |
| 排除记录 | 55,625 条 |
| 清洗后用户 | 987,991 人 |
| 清洗后商品 | 4,161,138 个 |
| 原始商品类别 | 9,437 类 |
buy 行为事件 |
2,015,807 次 |
| 数据时间范围 | 2017-11-25 至 2017-12-03 |
| 统一时区 | Asia/Shanghai |
| 扩展后字段 | 27 个 |
| 分析主题 | 25 个 |
| Plus 发布版本 | plus-release_006 |
| MySQL 固定查询入口 | 24 个 |
| 数据库汇总结果 | 25,067 行 |
注意：
buy是数据中的购买行为事件。除非有独立订单号和订单表支持，否则不要把它直接说成“真实订单量”。- “排除记录”表示没有进入最终统一分析数据的记录，不等于随意删除。
- 所有正式材料中的数字应以最终版本的数据检查结果为准。早期报告中的样本数据或旧版本数字只能作为迭代过程记录。
4. 任务书要求与实际完成情况
4.1 任务书基础要求
- 数据接入与整理。
- 数据清洗和字段处理。
- 用户行为、流量、转化等分析。
- 数据可视化和仪表盘。
- 推荐、运营或业务改进建议。
- 团队分工、过程记录、总结报告和答辩展示。
4.2 超出基础要求的成果
- 面向 Windows 环境的自适应数据流水线。
- 对一亿级完整数据进行统一处理，而不只是使用小样本演示。
- 27 字段统一分析数据和字段来源说明。
- 25 个分析主题及统一指标口径。
- 处理过程的质量检查、结果一致性检查和可恢复运行设计。
- MySQL、Streamlit、Metabase 多种展示和查询方式。
- 服务器实际部署及正式发布版本。
- 从早期探索、v4.1 基线、Plus 正式流水线到企业后台和 Windows 工具的版本迭代。
5. 数据从哪里来，经过了哪些处理
9 个原始数据分片
↓
Plus 12：自适应 Windows 数据流水线
├─ 自动识别输入文件
├─ 清洗并统一数据规则
├─ 扩展为 27 字段
├─ 生成清洗数据和质量检查结果
└─ 生成 25 个业务分析主题
↓
官方完整运行结果 run_001
↓
Plus 13：企业后台
├─ 整理 plus-release_006 发布文件
├─ 导入 MySQL 固定查询入口
├─ 提供 Streamlit 展示
└─ 为 Metabase 提供汇总数据
↓
答辩看板、分析报告、PPT 和视频
统一表达：Plus 成果由 E:\实训\数据分析Plus\12_自适应Windows数据流水线 直接产出；13_Plus企业后台 负责接收成果并完成发布、数据库和展示。v4.1 是此前的基线版本，不是当前 Plus 数据的直接生产者。
6. 27 个字段怎样理解
27 个字段不是全部来自原始数据，分为四类：
| 类型 | 数量 | 普通解释 |
|---|---|---|
| 原始字段 | 5 | 原始数据本来就有的用户、商品、类别、行为、时间信息 |
| 按明确规则计算的字段 | 8 | 根据原始数据直接计算，例如日期、小时、星期、时段等 |
| 人工映射字段 | 5 | 通过固定映射表补充的业务分类信息 |
| 按固定规则生成的模拟字段 | 9 | 为业务分析和演示补充的金额、渠道、设备、地区等信息 |
答辩时应强调：模拟字段的规则是固定的，同样的输入会得到同样的结果，便于重复验证；但它们不是真实交易系统采集的数据，不能用来证明真实销售额或真实地区表现。
7. 各工具分别做什么
| 工具或模块 | 主要作用 |
|---|---|
| Plus 12 流水线 | 读取原始数据、清洗、扩展字段、生成分析主题和检查结果 |
| Plus 13 企业后台 | 整理发布版本、导入数据库、提供查询和展示入口 |
| MySQL | 保存已经整理好的主题结果，提供稳定查询入口 |
| Streamlit | 快速展示分析结果、运行状态和管理页面 |
| Metabase | 面向答辩和业务人员制作可交互仪表盘 |
| GitHub 版 Windows 数据流水线 | 将经验整理为更便于复用和继续完善的工具化版本 |
为什么不让 Metabase 直接查询全部明细：一亿行明细反复聚合会降低响应速度，也容易因不同人写法不同而产生指标差异。先由流水线统一计算，再让 Metabase 查询小而稳定的主题结果，可以提高速度并统一口径。
8. 核心指标和分析结论
8.1 指标解释
- 页面浏览量（PV）：
behavior_type = pv的行为次数。 - 购买行为次数：
behavior_type = buy的行为次数，不等于真实订单数。 - 严格浏览到购买转化率：按照统一规则，在规定观察条件内从浏览进一步发生购买的比例。
- 加购后购买率：发生加购后，在规定观察条件内进一步发生购买的比例。
- 收藏后购买率：发生收藏后，在规定观察条件内进一步发生购买的比例。
- 高活跃未购买用户：行为较活跃但观察期内没有出现购买行为的用户。它是机会人群，不代表一定会购买。
8.2 可用于答辩的主要发现
| 方向 | 发现 | 应怎样解释 |
|---|---|---|
| 日期高峰 | 12 月 2 日 PV 为 12,329,641，购买行为为 257,903，均为观察期高点 | 相对前 7 日平均值，PV 高 32.59%，购买行为高 20.34% |
| 时段 | 晚间 PV 为 36,912,077，购买行为为 728,562 | 晚间是主要活跃时段；浏览到购买用户比例为 11.37%，早晨为 6.01% |
| 行为转化 | 严格浏览到购买为 1.4163%，加购到购买为 6.1202%，收藏到购买为 4.2640% | 加购和收藏比普通浏览表现出更强意向 |
| 加购等待时间 | 2—24 小时完成购买占 36.03%，超过 24 小时占 40.64%，合计 76.67% | 很多购买并非即时发生，可设计延后提醒策略 |
| 商品集中度 | 513,641 个 A 层商品占商品数 12.34%，贡献 80% PV 和 77.22% 购买行为 | 流量和购买行为集中在少量头部商品 |
| 商品机会 | 共识别 15,000 个待进一步检查的商品 | 包括低曝光高转化 9,415 个、高曝光但无浏览后购买 4,140 个、高意向但无购买 1,445 个 |
| 用户分层 | 购买用户 672,404 人，占 68.06% | 意向未购 256,012 人，占 25.91%；仅浏览 59,575 人，占 6.03% |
| 高活跃未购 | 266,856 人，占 27.01% | 该口径与前述用户分层可能交叉，不能相加 |
8.3 结论的边界
- 数据只覆盖 9 天，适合分析短期行为，不适合直接推断长期趋势或季节规律。
- 观察期结束时仍未购买的用户，之后是否购买未知。
- 商品数据过少时不应直接判断转化好坏。本项目有 3,751,508 个商品因数据量不足未进入可靠比较；最终可靠筛选 13,871 个商品，约占全部商品的 0.33%。
- “机会商品”和“机会用户”表示值得进一步检查，不表示一定能带来收益。
- 分析建议是基于数据形成的推断，实施前仍需业务验证或实验。
9. 版本演进怎样讲
- 早期探索：完成 Python 清洗、样本分析、推荐思路和初版报告，主要用于验证方向。
- v4.1 基线：形成较稳定的数据处理和分析基础，为 Plus 版本提供经验。
- Plus 12 正式流水线：直接处理完整数据，生成 27 字段数据、质量检查和 25 个分析主题。
- Plus 13 企业后台：把正式结果整理成
plus-release_006，接入 MySQL、Streamlit 和 Metabase。 - Windows 数据流水线工具版：将现有流程进一步整理为便于复用、部署和继续完善的版本。
不要把不同版本的数字混在一起。早期样本报告可以证明项目经过迭代，但最终结论必须使用正式版本口径。
10. 团队怎样协作
统一模型是：组长总控、每人有主要负责方向、看板共同建设、成员互相检查、最后统一发布。
| 成员 | 主要负责方向 | Metabase 主要展示方向 | 需要参与的交叉检查 |
|---|---|---|---|
| 黎钊恺 | 总体架构、流水线、27 字段、部署、版本和最终整合 | 总览、数据处理和方法说明 | 核对各板块数据来源、指标口径和最终发布 |
| 吴锐锋 | 数据清洗、质量检查、指标复核、过程材料 | 流量与转化 | 检查指标计算和报告数字是否一致 |
| 康奕 | 可视化、页面布局、截图和展示材料 | 类别与商品 | 检查图表是否易懂、标题和单位是否准确 |
| 贾天宇 | 关联推荐、用户机会、商品机会和运营解释 | 用户与机会、模拟运营 | 检查建议是否有数据支持、是否超出数据边界 |
这不是四个人各做一个互不相关的文件。典型协作过程应是：黎钊恺提供统一数据和规则，主责成员完成分析与看板，另一名成员检查数字或表达，康奕协助统一展示，最后由黎钊恺整合发布。
11. 常见答辩问题与参考回答
问：你们处理的是完整数据还是样本？
答：正式 Plus 结果使用 9 个原始分片中的完整数据，共 100,150,807 条。清洗后保留 100,095,182 条。早期曾用样本验证思路，但样本结果不作为最终统一口径。
问：为什么购买次数不能叫订单量？
答：原始数据记录的是用户行为，buy 表示一次购买行为事件，没有独立订单号和订单明细，因此我们统一称为购买行为次数，避免把行为日志误当成真实订单系统数据。
问：27 个字段都是原始数据吗？
答：不是。5 个是原始字段，8 个按明确规则计算，5 个通过人工映射补充，9 个是按固定规则生成的模拟业务字段。我们在报告和看板中明确区分真实字段、计算字段和模拟字段。
问：为什么需要模拟字段？
答：原始数据缺少金额、渠道、设备和地区等业务维度。为了展示完整分析方法，我们用固定且可重复的规则补充这些字段。但相关结果只用于教学和方案演示，不作为真实经营结论。
问：为什么 Metabase 不直接连接一亿行明细？
答：直接反复查询大表会慢，也容易出现不同图表计算口径不一致。我们先用流水线统一生成 25 个主题，再将汇总结果导入数据库固定查询入口，Metabase 负责展示，因此速度和口径都更稳定。
问：你们如何保证数据质量？
答：我们记录原始数量、清洗后数量和排除数量，统一字段类型、时间和计算规则，并在流水线中检查结果是否完整、同样输入能否得到一致结果。最终发布时还会核对数据库、报告和看板中的关键数字。
问：推荐结果是否覆盖所有商品？
答：不是。为了避免数据量太少导致误判，我们先排除证据不足的商品。最终可靠筛选 13,871 个商品，约占全部商品的 0.33%。机会清单用于进一步检查，不表示自动推荐后一定有效。
问：9 天数据能得出什么结论？
答：可以分析这 9 天内的流量、行为转化、时段和短期机会，但不能直接代表长期趋势。对观察期末仍未购买的用户，我们会说明之后结果未知。
问：四个人都做了 Metabase，会不会分工重复？
答：共同制作看板是有意设计的协作环节。每人有主要展示方向，同时使用同一套数据规则；成员之间再交叉检查指标和图表，最后统一整合。这样既体现共同参与，也能避免每个人独立制作后口径不一致。
问：项目负责人贡献较多，怎样体现团队协作？
答：负责人承担总体架构、核心流水线、部署和整合，其他成员承担数据质量、专项分析、可视化、推荐解释和交叉检查。我们按实际任务和证据说明贡献，不简单写成平均分工，也不把负责人描述成只接收其他人的成果。
12. 建议使用的通俗表达
| 容易听不懂的说法 | 答辩时优先说法 |
|---|---|
| 数据血缘 | 数据从哪里来、经过哪些处理步骤 |
| 版本冻结 | 最终确认版本，之后不再随意修改 |
| manifest | 文件清单和版本记录 |
| logical hash | 结果一致性检查值 |
| physical hash | 文件是否变化的检查值 |
| 数据契约 | 大家共同遵守的字段、格式和计算规则 |
| workflow | 按顺序执行的数据处理步骤 |
| checkpoint | 中断后可以继续运行的位置 |
| release package | 用于服务器展示的一组正式文件 |
| stable views | 固定的数据库查询入口 |
| right censoring | 观察期结束，之后结果未知 |
| low-sample gate | 数据太少时先不下结论 |
| candidate | 需要进一步检查的对象 |
13. 不应出现的说法
| 不规范说法 | 建议改为 |
|---|---|
| “我们有两百多万真实订单” | “数据中有 2,015,807 次购买行为事件” |
| “这些是真实销售额” | “金额为固定规则生成的模拟字段，用于演示分析方法” |
| “推荐结果一定能提升销量” | “识别出值得进一步验证的机会，可通过实验评估效果” |
| “所有商品都进行了可靠推荐” | “先排除数据不足的商品，再对证据相对充分的商品进行筛选” |
| “九天数据代表全年趋势” | “九天数据用于短期行为分析，长期结论需要更长时间数据” |
| “四个人工作完全平均” | “每人有主要负责方向，同时共同制作看板并交叉检查” |
| “v4.1 产出了当前 Plus 正式数据” | “当前 Plus 正式数据由 Plus 12 流水线直接产出” |
14. 答辩前全员检查清单
- [ ] 能在 30 秒内说清项目目标和最终成果。
- [ ] 能说出原始记录、清洗后记录、27 字段、25 主题等关键数字。
- [ ] 能解释购买行为与真实订单的区别。
- [ ] 能说明哪些字段是模拟的，以及为什么使用模拟字段。
- [ ] 能按顺序讲清数据处理和展示过程。
- [ ] 能说清自己的主要任务、具体产物和一次交叉检查经历。
- [ ] 能打开并解释自己负责的 Metabase 页面。
- [ ] 能说出至少两项主要发现及其限制。
- [ ] 不使用未经确认的旧版数字或虚构的协作过程。
- [ ] 回答超出自己主责的问题时，先说共同口径，再由对应主责成员补充细节。
15. 本手册的后续维护
- 最终 PPT、视频和个人讲稿完成后，应再次核对本手册中的数字和术语。
- 若服务器数据或正式发布版本发生变化，需要同步更新手册版本号和变更记录。
- 个人板块手册可以引用本手册的公共内容，但不得自行创造另一套数据口径。