Sports Tech's Data Layer Is Splitting in Two: Dashboards You Own, Agents You Aim

On 8 September, software consultancy Adaca published adaca-analytics on GitHub, a self-hosted dashboard layer for Google Analytics 4 that runs on Cloudflare Workers. Ten days later, on 18 September, a CData-sponsored white paper on the Wiley Science and Engineering Content Hub went after replication speed, promising 76% faster replication on the same infrastructure. Between those two dates, Starburst published an architecture analysis on 11 September that asks who, or what, should be allowed to query the data in the first place.

None of this is sports-specific. That is the point. The infrastructure that decides which athlete gets rested, which ticket price gets shown and which broadcast highlight gets cut is being rebuilt at the plumbing level, and the sports industry is mostly a consumer of those decisions rather than a maker of them.

The dashboard argument: own the numbers

Adaca's tool is deliberately unglamorous. According to its GitHub README, daily rollups from the GA4 Data API or a BigQuery export land in a D1 database the operator owns, while realtime data stays live on Google. It ships six dashboards out of the box and a four-step builder for custom ones. Every number is clickable: sources, pages and countries open into detail pages with their own trend and breakdowns, precomputed so they load in one round trip.

"Adaca is a software consultancy. We build custom software, embed senior engineers in client teams, and put AI to work for our clients. Adaca Analytics is open source under the MIT licence."

The setup requires a Google service account with Viewer access on the GA4 property and its JSON key. Deployment forks the repository, provisions D1 and KV, and asks for the key. There is no sign-in, so the README tells operators to put Cloudflare Access or the built-in Basic Auth in front of it.

For a club or a rights holder, the appeal is ownership and cost. For a sports data team, the appeal is that a comparison against the previous period, last year or any window is a click, not a ticket to a central analytics group that has twelve other requests queued.

The agent argument: hand over the keys

Starburst's post is not a product announcement. It is a taxonomy, and a useful one if you are trying to work out where sports analytics budgets will actually go over the next two seasons.

The author sets up a grocery example that maps almost perfectly onto a sports business question: was my sale on eggs last week profitable? Answering it properly needs transaction data, loyalty data, basket composition and store layout, spread across more than one database. Swap eggs for a discounted family ticket and loyalty cards for season-ticket holder records and you have the same problem a football club faces every Monday morning. The post argues that agents, not humans, are starting to do the bulk of this iterative work, and that the quality of the output depends heavily on how the data reaches the agent.

It lays out three options. Option 0, extracting raw data and shipping it to the agent as files, is dismissed outright: the post says it can get prohibitively expensive when agents charge per data item and that its performance disadvantages make it "not a good option in practice." Option 1 gives the agent direct database access and lets it write its own SQL, iterating against the database execution engine rather than dragging terabytes across the wire. The post notes this can strain systems, because agents are far more demanding than humans and can overwhelm a database with speculative queries, but says the database industry is now focused on supporting agentic workloads.

The intermediate options, where the database does some processing before handing results over, are where the post spends most of its analytical energy. The three dimensions it uses to judge them are the ones any sports analytics lead should be measuring: correctness, latency and token cost.

Where the sports data actually sits

Sports organisations tend to run a hybrid. Fan-facing web and app analytics live in something like GA4 or an equivalent, which is the layer Adaca is targeting. Ticketing, CRM and merchandise live in operational databases. Broadcast and tracking data lives somewhere else again, often at volumes that make the CData replication pitch relevant.

The white paper, sponsored by CData, argues that rising data volumes have moved the bottleneck from the data itself to the architecture that moves it, and that overnight batch windows no longer fit. It describes parallel partitioned reads that split a large source table into row-range partitions and read them simultaneously across CPU threads, plus write-path optimisations that reduce per-file and per-column overhead. Wide tables with hundreds of columns benefit most, it says, and the results are reported across common cloud destinations.

The parallel with sports tracking data is not hard to draw. A single match can generate hundreds of columns of event and positional data, and a league generates hundreds of matches a week. If replication is the constraint, then the analytics team is waiting on infrastructure rather than asking better questions.

What the three documents do not settle is governance. Adaca's answer is to put Cloudflare Access in front of a Worker that holds a service-account key with Viewer rights. Starburst's answer is to let the agent drive the database and accept that it will be a heavier user than any human analyst. Neither addresses what happens when the agent, or the dashboard, is pointed at athlete health data or at the betting-adjacent signals that regulators are already circling.

The tooling is arriving faster than the rules. That gap, not the dashboards, is the story sports technology will spend next season dealing with.