Sports Analytics Is Eating Its Own Data Pipeline

Apple has an app called Sports. That is the entire name. Slate reviewed it on 10 June, as the World Cup got under way, and found it does almost nothing: team names and logos, records, game times, scores. No news feed, no streaming guide, no TikTok-style scroll.

The review is a useful counterweight to how sports technology usually gets sold. The same weeks that produced that piece also produced a run of developer tools for analytics plumbing, and the gap between the two stories is where the interesting work sits.

What Apple actually shipped

Slate's reviewer describes a product built around subtraction. The app carries no news headlines and no streaming guides, though you can see a game's channel if you tap it. Betting odds appear on the scoreboard by default and can be turned off permanently with a single toggle. There is almost no advertising, just occasional Apple TV promos at the top of a page. Users pick which leagues and teams appear on the homepage and in the sidebar, and those teams' scores can feed Live Activities on the lock screen, or not.

The speed claim in that review is specific and testable. The writer says he had to disable automatic Pittsburgh Penguins updates during the Stanley Cup Playoffs because the app surfaced developments before his streaming package did. He reports the same experience with NFL, college football and college basketball games. Coverage extends to World Cup matches, MLS, the NWSL and roughly 30 other soccer leagues, plus men's and women's tennis and the LPGA Tour, with basic box scores, leaderboards and rosters behind a tap.

Apple announced the app in the winter of 2024. Slate quotes an Apple executive's framing at launch: the company "created Apple Sports to give sports fans what they want, an app that delivers incredibly fast access to scores and stats."

"We created Apple Sports to give sports fans what they want, an app that delivers incredibly fast access to scores and stats."

That is a data problem dressed as a design problem. Every score on that screen is a feed, a mapping between leagues and teams, and a latency budget. Apple can absorb that cost. Most organisations building anything similar cannot, which is why the same period produced a cluster of releases aimed at people who have to assemble the pipeline themselves.

Rebuilding the old Analytics on GA4's data

Take adaca-analytics, published on GitHub on 8 September by Adaca, a software consultancy. It is a self-hosted dashboard layer for Google Analytics 4, running on Cloudflare Workers, with daily rollups from the GA4 Data API or a BigQuery export landing in a D1 database the operator owns. Realtime data stays on Google. The repo ships six dashboards out of the box plus a four-step builder for custom ones, and every headline number opens into a detail page with its own trend and breakdowns, precomputed so they load in one round trip.

The operational details matter more than the feature list. Setup asks for a Google service account with Viewer access on the GA4 property and its JSON key. Deployment forks the repository, provisions D1 and KV, requests the key and deploys the Worker with its cron job. There is no sign-in, so the README tells you to put Cloudflare Access or the built-in Basic Auth in front of it. Local development runs through npm install, a .dev.vars file holding the service-account JSON on one line, type generation, a database migration and a dev server. CI is four gates: build, typecheck, lint and test. The licence is MIT.

The pitch, in the repo's own words, is restoring a shape of product that GA4 displaced: dashboards with drill-down, saved segments, read-only share links that can pin a filter, comparison against the previous period or last year, weekly and monthly summaries, and traffic alerts by email or Slack.

Analytics as middleware, not a platform

A second release takes the opposite architectural bet. Plainoldanalytics, posted to GitHub on 13 September, is bolt-on web analytics for Go applications. The README frames it as similar in spirit to Umami, Plausible or PostHog, but embedded in your app rather than hosted beside it. The core package is storage-agnostic and knows nothing about any backend, so importing it never pulls one in. You pick a storage package, or implement the Storage interface and pass it to the constructor.

Usage is deliberately small. A memory_store constructor returns both a Storage and the wiring, and an analytics.Middleware call wraps an existing router. The dashboard mounts at a path of your choosing. A script tag enables client-side event capture, including optional session recording and calls like plainoldanalytics.track('signup', {plan: 'pro'}). Traffic flushes to disk roughly once a second, and a Close call on shutdown empties the buffer. Adapters exist for gin and chi, with the README showing how to scope the middleware to a route group so the dashboard itself is not recorded as traffic.

Two small details suggest this was written by someone who has run analytics in production. Requests can carry key/value properties that the UI can filter on, and the user property gets special treatment, showing all traffic tied to that user. Routes can be excluded from logging entirely. Path parameters are recorded as-is, but wrapping a handler with UseRequestPath records the literal route instead. That matters when you are serving files under a wildcard and do not want every URL to become its own row.

The agent question underneath all of it

Starburst published an analysis on 11 September of two architectures for agentic data analysis, and it names the problem the tools above are circling. The scenario is a grocery chain asking whether last week's egg promotion was profitable. That question cannot be answered from egg sales alone. It needs follow-ups about whether the promotion brought in customers who would not otherwise have come, whether new customers returned, what else was in those transactions, where those items sit in the store, and how profitable they are.

Starburst lays out two practical ways to feed an agent. The first, which the author calls "option 0" and explicitly does not recommend outside unusual circumstances, extracts raw data and ships it to the agent as files or a direct pipe, leaving the agent to do the processing itself. The objection is cost and performance: sending terabytes to something that charges per data item gets expensive, and the agent is doing work a database engine is better at.

The second gives the agent direct access to the database so it writes its own SQL and refines its requests iteratively. The database does what it is optimised for, and the agent supervises. Starburst notes the literature flags a real risk here, that agents can be far more demanding than human users and overwhelm a system with speculative queries as they narrow in on an answer, but argues the industry is now focused on supporting these workloads.

There is a limit in the piece worth repeating. The author writes that it will be a while before agents can process terabytes of structured data at the same level of optimisation as the database systems on the market today, built on decades of research. Until then, the database keeps the heavy end.

Why this is a sports story

Sports is the hardest consumer case for this stack, because the value of a score decays in seconds and the audience arrives in bursts: a World Cup group stage, a playoff run, a Sunday afternoon with a dozen concurrent games. Slate's reviewer makes the point that the app is fast enough to spoil results before a streaming feed catches up. That is not a UI achievement. It is a pipeline that has to reconcile dozens of leagues, map them to teams a user selected, and push updates to a lock screen inside a latency window.

Apple can fund that. Everyone else running a fan product, a betting product or a club app is assembling it from parts, and the parts published in September are candid about the trade-offs: own the database and get drill-down without a vendor, embed the analytics in your own process and skip the platform, or hand the agent query access and accept that it will ask more questions than any human analyst ever did. The app with no features is the easy part. Getting the number onto the screen before the stream does is the product.