大家好，希望大家都好！ TL;DR, 总结和完整的技术细节见下面。 背景： 最近我在这里发表了一篇关于 Day 1 的帖子，这是我的一个副业项目 ShuffleBall Arena 的第一天（它是一个免费的浏览器游戏，结合了shuffleboard得分与其他游戏如bumper池、弹球和Frogger的疯狂）。这个项目是使用AI（主要是GPT / Cursor / Fable）来帮助开发的。 我试图定期发表更新，但最近发现时间不足。因此，我决定将此项目的第1到第14天的更新发布，希望能够为大家提供一些价值。 为了加速了解，我使用了一个 结构化提示 去回顾我的GPT会话并提取有用的信息。希望这个提示可以帮助大家跟踪或从过去的AI项目会话中提取价值。 说到这里， 我将发布关于 ShuffleBall Arena 的第11天的更新。 今天，我花了4个小时来处理4个会话（2个保存的文件版本） 第11天的概述： =========================================================== # TL;DR * 将Google Analytics直接添加到可玩的游戏中。 * 将重点从页面浏览转移到真实的游戏事件。 * 验证跟踪与GA Realtime。 * 建立内部模式以避免开发人员测试干扰分析。 * 修复广播和嵌入式分析行为。 * 改进广播机器人匹配算法，使用随机配对。 * 最大教训： 页面浏览不代表游戏。 =========================================================== 第11天的总结： 直到现在，我可以看到人们访问网站，但我没有可靠的方法来知道是否有人真正 玩 这个游戏。由于游戏运行在自己的Cloudflare Pages网站上，因此仅仅添加Google Analytics是不够的。 我花了整天时间来整合GA直接到可玩的游戏中，调试服务工作者、内容安全策略、部署缓存和验证所有内容通过实时报告。 一旦跟踪工作正常，我就将重点从页面浏览转移到游戏事件，如游戏开始、射击和完成的比赛。 我还意识到我的开发人员测试会扭曲数据，因此我建立了一个内部测试模式，允许我禁用分析，同时开发。 这样，我就可以告诉自己是否有真正的玩家出现，而不是计算数千次我的测试游戏。 最后，我改进了自动直播的机器人匹配算法，使其使用随机配对而不是观看相同两台机器人玩游戏的同一对。 这是一个小的改变，但它使直播感觉更生动。 =========================================================== 第11天的完整技术总结（结构化提示输出）： # 部分1：技术分析和反思 # 开始点 在第11天的开始，ShuffleBall Arena已经到达了一个阶段，人们可以开始发现并玩这个游戏，但没有可靠的方法来回答一个简单的问题： "真实的人是否正在玩这个游戏?" Google Analytics只跟踪Webflow的landing页面，而不是可玩的游戏所在的Cloudflare Pages子域。即使有人启动比赛并发射子弹，也没有可靠的方法来衡量实际游戏。 与此同时，自动化OBS直播是可用的，但每场比赛都呈现相同的机器人对战，这使直播看起来像一个重复的场景，而不是一个活跃的竞技场。 # 会话目标 会话的目标是实现两个目标： 1. 建立一个隐私意识的分析基础，能够衡量真实的游戏行为而不是页面浏览。 相反于简单地计算访问者，目标是跟踪有意义的事件，如： * game_start * shot_fired * match_completed 在避免广播、嵌入式和开发人员测试的分析时。 2. 改进自动化广播，使机器人对手在比赛之间自然轮换，而不是重复地与相同的对手比赛。 # 我们实际做了什么 # 分析基础 我们首先确认可玩的游戏 实际上并没有被跟踪，尽管landing页面已经被跟踪。 这导致了： * 将Google Analytics直接添加到可玩的游戏中 * 验证正确的测量ID * 更新内容安全策略 * 解决服务工作者缓存问题 * 确保分析在部署后正确加载 一旦基本跟踪工作正常，重点就从页面浏览转移到游戏事件。 # 游戏事件 相反于将页面加载视为成功，项目开始跟踪实际的互动。 事件包括： * game_start * shot_fired * game_completed * match_completed * 布局选择 * 音乐互动 使用实时报告来验证这些事件，而不是仅仅依赖页面_view指标。 # 分析调试 会话涉及大量调试： * Google Analytics实时 * DebugView * 服务工作者缓存 * Cloudflare缓存 * CSP限制 * 控制台错误 最终，游戏事件在GA实时报告中正确显示。 # 保护数据质量 我们意识到：开发人员测试会扭曲使用数据。 相反于仅仅依赖Google Analytics的IP过滤，使用URL参数如： * ?sba_analytics=off * ?sba_analytics=on 设计了一个浏览器级别的关闭或开启分析的系统。 长期目标是：从一开始就不要发送开发人员自己的游戏事件。 这样可以保持分析代表真实玩家，而不是数千次内部测试会话。 # 广播分析 一旦分析同意工作正常，另一个问题出现了：分析同意提示在OBS直播中出现。 这导致了一个设计变化：广播模式和网站嵌入模式应该完全抑制分析提示，因为它们是自动化的显示，而不是真正的玩家。 # 广播改进 然后我们关注了呈现本身。 以前： * 同一台机器人不断地与同一台机器人对战 * 同一对对战不断重复 在匹配逻辑上进行了重写，使得： * 每场直播比赛都选择一个新的随机对手 * 机器人不会与自己比赛 * 前一场比赛的具体对手不会重复出现 * 玉石皮肤与玩家名称一起旋转。 这使自动化直播看起来更像一个不断运行的竞争性竞技场。 # 阻碍和摩擦 有几个问题阻碍了进展。 最大的挑战是发现 landing-page分析和游戏分析是两个完全不同的问题。 添加Google Analytics并不能回答人们是否正在真正玩游戏。 服务工作者缓存反复出现，导致部署后旧版本文件的缓存，难以确定修复是否已应用。 Cloudflare内容安全策略限制生成了额外的控制台错误，这些错误与游戏分析本身无关，耗尽了调试时间，直到变得清晰这些警告可以暂时忽略。 最后，测试本身创建了误导性的分析。 incognito窗口、清除缓存、部署刷新和多个浏览器都被视为不同的用户，使“活跃用户”计数在设计了显式开发人员关闭策略之前是不可靠的。 # 做出的决定和权衡 有几个重要的产品决策来自这个会话。 相反于优化页面浏览，项目选择优化游戏事件，因为它们更好地代表实际参与度。 相反于仅仅依赖Google Analytics的IP过滤，项目采用了浏览器级别的抑制，开发人员测试从一开始就不会被发送。 广播模式和网站嵌入模式被故意排除在分析之外，因为它们是演示而不是玩家。 对于广播本身，确定性机器人轮换被放弃，取而代之的是随机匹配，接受稍微更少的可预测性以换取更有趣的观看体验。 # 创新/教训 最大的认识是： 页面浏览不是玩家。 对ShuffleBall Arena来说，成功被衡量为像： * 开始游戏 * 发射子弹 * 完成比赛 这些指标揭示了人们是否正在真正参与游戏，这比简单地计算访问者更有意义。 # 值得分享的艺术品 # 产品规则 "将game_start视为您的真正的 '玩家'指标，而不是页面浏览。" # 广播设计规则 "同一台机器人不会与自己比赛，且相同的具体对手不会连续重复出现。" # 内部测试工作流程 ?sba_analytics=off ?sba_analytics=on 简单的URL以关闭或恢复分析收集为测试浏览器。 # 最终状态 到第11天结束： * Google Analytics正确跟踪可玩的游戏而不是仅仅跟踪landing页面。 * 游戏事件如game_start和shot_fired在GA实时报告中可见。 * 分析架构转向衡量真实参与度而不是页面浏览。 * 为生产分析建立了一个隐私意识的策略，以排除开发人员活动。 * 广播模式和网站嵌入模式配置为避免显示分析同意提示。 * 广播机器人匹配算法改进为随机配对，避免了重复对战，给自动化直播增添了生机。 感谢阅读！