体育数据分析正在吞噬其数据管道

苹果有一款应用叫 Sports。名字就这么简单。Slate 在 6 月 10 日世界杯开赛之际对其进行了评测，指出该应用功能极简：仅包含队名、队标、战绩、比赛时间和比分。没有新闻流，没有观赛指南，也没有 TikTok 式的无限滚动。

这篇评测为体育科技的营销常态提供了有益的对照。在发布该评测的同一时期，一批面向数据分析底层管道的开发者工具也相继问世。这两者之间的差距，正是有趣工作所在之处。

苹果到底发布了什么

Slate 的评测者描述了一款以“减法”为核心的产品。应用内没有新闻标题，也没有观赛指南，但点击某场比赛可查看播出频道。比分板默认显示博彩赔率，用户可通过一个开关永久关闭。广告极少，仅在页面顶部偶尔出现 Apple TV 推广。用户可自选首页和侧边栏显示的联赛及球队，这些球队的比分可推送至锁屏的实时活动，也可选择不推送。

评测中关于速度的描述具体且可验证。作者提到，在斯坦利杯季后赛期间，他不得不关闭匹兹堡企鹅队的自动更新，因为该应用比他的流媒体套餐更早推送比赛进展。他在 NFL、大学橄榄球和大学篮球比赛中也有类似体验。应用覆盖范围包括世界杯、MLS、NWSL 及约 30 个其他足球联赛，此外还有男子和女子网球以及 LPGA 巡回赛。点击即可获取基础赛后数据、排行榜和球员名单。

苹果于 2024 年冬季宣布推出该应用。Slate 引用了一位苹果高管在发布时的表述：“我们创建 Apple Sports，是为了给体育迷他们想要的东西——一款能极快获取比分和数据的应用。”

“我们创建 Apple Sports，是为了给体育迷他们想要的东西——一款能极快获取比分和数据的应用。”

这是一个被包装成设计问题的数据问题。屏幕上的每个比分背后，都对应着一条数据流、一层联赛与球队的映射关系，以及一份延迟预算。苹果能够承担这一成本，但大多数试图构建类似产品的组织却无力承担。因此，同一时期出现了一批发布，旨在帮助那些必须自行搭建管道的人。

用 GA4 的数据重建旧版 Analytics

以 adaca-analytics 为例，这是由软件咨询公司 Adaca 于 9 月 8 日在 GitHub 上发布的项目。它是 Google Analytics 4 的自托管仪表盘层，运行在 Cloudflare Workers 上，通过 GA4 Data API 或 BigQuery 导出进行每日汇总，数据存入运营者自有的 D1 数据库。实时数据仍保留在 Google 端。仓库开箱提供六个仪表盘，并附带一个四步自定义仪表盘构建器。每个关键数字均可点击进入详情页，查看其趋势和细分数据，这些内容已预先计算，确保单次请求即可加载。

运维细节比功能列表更为关键。安装需要一个具有 GA4 属性查看权限的 Google 服务账号及其 JSON 密钥。部署流程包括 Fork 仓库、配置 D1 和 KV、申请密钥，以及部署带有 Cron 任务的 Worker。由于系统无登录功能，README 建议在其前端部署 Cloudflare Access 或内置的 Basic Auth。本地开发需运行 npm install，将服务账号 JSON 写入 .dev.vars 文件的一行中，随后执行类型生成、数据库迁移并启动开发服务器。CI 包含四道关卡：构建、类型检查、Lint 和测试。许可证为 MIT。

用仓库自己的话说，其核心卖点是恢复一种被 GA4 取代的产品形态：支持下钻的仪表盘、可保存的细分、能固定筛选条件的只读分享链接、与上一周期或去年同期的对比、每周和每月摘要，以及通过邮件或 Slack 发送的流量告警。

将分析视为中间件，而非平台

第二个发布项目采取了相反的架构策略。Plainoldanalytics 于 9 月 13 日在 GitHub 上发布，是一款为 Go 应用设计的嵌入式网站分析工具。README 指出，其理念类似 Umami、Plausible 或 PostHog，但它是嵌入在你的应用中，而非托管在外部。核心包与存储无关，不依赖任何特定后端，因此导入它不会引入额外的后端依赖。用户可选择存储包，或实现 Storage 接口并传入构造函数。

用法被刻意设计得极简。memory_store 构造函数同时返回 Storage 实例和接线配置，一次 analytics.Middleware 调用即可包裹现有路由器。仪表盘挂载在用户指定的路径上。通过一个 script 标签启用客户端事件采集，支持可选的会话录制，并允许调用如 plainoldanalytics.track('signup', {plan: 'pro'}) 这样的方法。流量约每秒刷新一次磁盘，关闭时调用 Close 方法清空缓冲区。项目提供了 gin 和 chi 的适配器。README 展示了如何将中间件限定在特定路由组，以避免仪表盘本身的访问被记录为流量。

两个小细节表明作者拥有生产环境运行分析的经验。请求可携带键值属性，UI 可据此进行筛选。用户属性享有特殊处理，可显示与该用户关联的所有流量。路由可完全排除在日志记录之外。路径参数默认按原样记录，但若使用 UseRequestPath 包裹处理器，则会记录字面路由。当在通配符路径下提供文件服务，且不希望每个 URL 都成为独立记录时，这一点至关重要。

这一切背后的智能体问题

Starburst 于 9 月 11 日发布了一篇分析文章，探讨了智能体数据分析的两种架构，并指出了上述工具所围绕的核心问题。场景设定为一家连锁超市询问上周的鸡蛋促销是否盈利。仅凭鸡蛋销量无法回答此问题。它需要进一步追问：促销是否吸引了原本不会光顾的顾客？新顾客是否回头？这些交易中还包含哪些商品？这些商品在店内的位置如何？以及它们的利润率是多少？

Starburst 提出了两种向智能体提供数据的实用方式。第一种被作者称为“选项 0”，并明确建议除特殊情况外不要使用：提取原始数据，以文件或直连管道形式交给智能体，由其自行处理。反对理由在于成本和性能：将 TB 级数据发送给按数据量计费的服务成本高昂，且智能体正在执行数据库引擎更擅长的工作。

第二种方式让智能体直接访问数据库，自行编写 SQL 并迭代优化请求。数据库执行其优化后的任务，智能体负责监督。Starburst 指出，文献中提示此处存在真实风险：智能体可能比人类用户更具侵略性，在逐步逼近答案的过程中，用大量推测性查询压垮系统。但作者认为，业界目前正专注于支持此类工作负载。

文中有一处限制值得重申。作者写道，智能体要达到当前市场数据库系统那样的优化水平来处理 TB 级结构化数据，还需要一段时间，因为这些系统建立在数十年的研究基础之上。在此之前，繁重的工作仍由数据库承担。

为什么这是一个体育故事

体育是这套技术栈中最具挑战性的消费级场景，因为比分的价值在几秒内就会衰减，而观众则是成批涌入的：世界杯小组赛、季后赛征程，或是一个同时有十几场比赛的周日下午。Slate 的评测者指出，该应用速度快到能在流媒体信号跟上之前剧透比赛结果。这不是 UI 的成就，而是一条管道的能力：它需要协调几十个联赛，将其映射到用户选择的球队，并在严格的延迟窗口内将更新推送到锁屏。

苹果能负担得起这笔成本。其他运营球迷产品、博彩产品或俱乐部应用的人则需自行组装组件。9 月发布的这些组件对权衡取舍持坦率态度：拥有自己的数据库，即可在不依赖供应商的情况下获得下钻能力；将分析嵌入自有进程，即可跳过平台依赖；或者将查询权限交给智能体，并接受它会提出比任何人类分析师都多的问题。没有功能的应用是容易的部分。在流媒体之前将数字呈现在屏幕上，才是产品本身。