体育数据分析正在吞掉自己的数据管道

苹果有一款应用叫 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，用一个 .dev.vars 文件把服务账号 JSON 放在一行里，再做类型生成、数据库迁移和启动开发服务器。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 展示了如何把中间件限定在某个路由组上，这样看板本身不会被记成流量。

两个小细节说明作者在生产环境跑过分析。请求可以带上键值属性，界面能据此筛选。用户属性有特殊处理，会显示与该用户相关的全部流量。路由可以完全排除在记录之外。路径参数按原样记录，但用 UseRequestPath 包一层处理器就会记录字面路由。当你在通配符下提供文件、又不想每个 URL 都变成单独一行时，这一点很要紧。

这一切底下的智能体问题

Starburst 在 9 月 11 日发表了一篇分析，讲智能体做数据分析的两种架构，点出了上面这些工具都在绕着走的问题。场景是一家连锁超市问，上周的鸡蛋促销是否赚钱。这个问题没法只靠鸡蛋销量回答。它需要追问：促销是否带来了本来不会来的顾客，新顾客有没有回头，那些交易里还买了什么，这些商品摆在店里什么位置，以及它们的利润有多高。

Starburst 给出了两种给智能体喂数据的实用方式。第一种被作者称为“选项 0”，并明确表示除非情况特殊否则不推荐：抽取原始数据，以文件或直连管道的方式交给智能体，让智能体自己处理。反对理由是成本和性能。把数 TB 数据送给一个按数据条数计费的东西会很贵，而且智能体在做数据库引擎更擅长的工作。

第二种让智能体直接访问数据库，自己写 SQL 并迭代细化请求。数据库做它被优化过的事，智能体负责监督。Starburst 指出，文献提示这里有一个真实风险：智能体可能比人类用户苛刻得多，在逐步逼近答案的过程中用大量试探性查询压垮系统。但作者认为，业界现在正专注于支持这类负载。

文中有一处限制值得重复。作者写道，智能体要像今天市面上的数据库系统那样、以同样的优化水平处理数 TB 结构化数据，还需要一段时间，那些系统建立在数十年的研究之上。在那之前，重活仍由数据库承担。

为什么这是一个体育故事

体育是这套技术栈里最难的消费级场景，因为比分的价值几秒钟就衰减，观众又是成批涌来的：世界杯小组赛、季后赛之旅、一个同时有十几场比赛的周日下午。Slate 的评测者指出，这款应用快到能在流媒体信号跟上之前就把结果剧透出去。这不是界面的功劳。这是一条管道，它要调和几十个联赛，把它们映射到用户选定的球队，并在一个延迟窗口内把更新推到锁屏上。

苹果出得起这笔钱。其他做球迷产品、博彩产品或俱乐部应用的人都在用零件拼装。9 月发布的这些零件对取舍很坦白：自己掌握数据库，就能不靠供应商拿到下钻能力；把分析嵌进自己的进程，就能跳过平台；或者把查询权限交给智能体，并接受它会比任何人类分析师问得都多。没有功能的那款应用是简单的那部分。在流媒体之前把数字送到屏幕上，才是产品。