威斯康星大学麦迪逊分校 Field Day Lab——教育游戏实时数据监控平台

1. 项目概述（Overview）

在 UW–Madison Field Day Lab 担任数据科学产品实习生，参与教育游戏实时数据监控平台建设，负责需求分析、产品方案设计、数据可视化及核心功能落地。

2. STAR

Situation（项目背景）

实验室研究人员主要依赖游戏日志进行事后分析，无法实时观察玩家行为，也缺少统一的平台对多款教育游戏的数据进行监控和分析。随着支持游戏数量增加，研究人员希望能够实时查看事件流、玩家行为及关键指标，提高研究效率。

Task（目标）

负责梳理研究人员需求，设计实时数据监控产品方案，在兼容现有 OpenGameData 日志系统的前提下，搭建统一的数据分析平台，实现多游戏、多维度的数据可视化能力。

Action（行动）

• 与研究人员持续沟通，梳理实时监控场景，完成产品需求分析，并设计 Dashboard 信息架构，包括 Session、Player、Population 三层分析模型、游戏选择器及多维筛选能力。

• 针对现有 PHP Logger 已稳定运行、直接替换风险较高的问题，调研多种技术方案，最终采用 Flask + Flask-SocketIO 搭建 REST 与 WebSocket 中继服务，实现实时事件推送，同时保持原有日志系统不变。

• 基于 D3.js 开发实时事件流及数据可视化组件，完成响应式前端页面，实现教育游戏事件实时展示及玩家指标监控。

Result（结果）

• 完成教育游戏实时数据监控平台核心功能开发，实现研究人员实时查看游戏事件及玩家行为数据。

• 建立统一的数据分析入口，支持 5 款以上教育游戏的数据监控与分析。

• 在保留现有日志系统的基础上，实现实时数据推送能力，降低系统改造风险，为后续 Dashboard 与 Replay 功能扩展提供基础。

3. 产品思考（Product Thinking Highlights）

• 从研究人员的实际工作流程出发，而不是从技术实现出发定义产品需求。

• 将分析能力拆分为 Session、Player、Population 三个层级，满足不同粒度的数据分析需求。

• 在系统稳定性与开发成本之间做权衡，选择兼容现有日志系统的技术方案，而非整体重构。

• 将产品需求与技术实现结合，推动实时数据监控能力真正落地。

4. 挑战与解决方案（Challenges & How I Solved Them）

挑战一：现有日志系统已投入使用，无法贸然重构

直接替换 Logger 会影响已有教育游戏的数据采集流程，技术风险较高。

解决方式： 调研多种实时通信方案，最终采用 Flask + Flask-SocketIO 构建中继服务，实现实时事件推送，同时保持现有 Logger 不变。

挑战二：需求在开发过程中不断演进

研究人员随着原型体验不断提出新的分析维度和展示需求。

解决方式： 将 Dashboard 按模块设计，预留筛选器及分析模块扩展能力，便于后续增加新的指标和可视化组件。

挑战三：不同教育游戏事件结构存在差异

各游戏产生的数据格式及关注指标不同，统一展示存在一定难度。

解决方式： 设计统一的数据分析框架，以 Session、Player、Population 为核心抽象层，并通过游戏选择器支持跨游戏分析。

5. 项目成果（Impact Summary）

• 完成教育游戏实时数据监控平台需求分析与产品方案设计。

• 搭建统一的数据分析框架，支持多款教育游戏的数据监控。

• 完成实时事件流可视化及 Dashboard 核心功能开发。

• 在兼容原有日志系统的前提下，实现实时数据推送能力。

6. 项目反思（Reflection）

这个项目让我认识到，技术平台型产品的核心并不是追求最新技术，而是在理解用户工作流程和现有系统约束的基础上，找到风险与价值之间的最佳平衡点。相比重新设计一套系统，兼容已有基础设施并逐步扩展能力，往往更符合真实产品开发的决策逻辑，也让我更加理解产品经理在技术方案取舍中的价值。