For most analytics teams, the bottleneck has moved. It is rarely the data or the tooling anymore. It is the line of people waiting for an analyst to rewrite a query the analyst has already written once. We think the way out is a change in what analysts build, and SEGA's Persona5: The Phantom X team shows what that looks like.
Yusaku Abe runs the Business Analytics Section behind the game. Before writing a query, the team asks whether an analysis model can answer the question, and it accepts a little extra setup to avoid the query. The reason is about who can use the work afterward.
You already know the case for SQL. It gives an experienced analyst precise, flexible control over an analysis. The cost shows up later, in the second and third request.
In a query-first workflow, follow-ups go back to analysts
At SEGA, a request from live-ops used to follow a familiar path. An operator wanted a number, an analyst wrote the SQL, and the result went back as a chart. Then the follow-ups arrived, such as the same metric split by segment or viewed by week, and each one landed back with an analyst. Abe describes what that meant for the analysts.
"With SQL, we sometimes had to rebuild everything from scratch each time, which was a heavy load for analysts."
The rebuild is the hidden cost. Analysts need different aggregation logic for daily and monthly unique users, because a player active on three days counts three times in one view and once in the other, and Abe notes that changing the grain sometimes meant separate SQL. For each change, the team still relies on someone who can modify the query safely. A team with three analysts and thirty people who want numbers has built a queue, whatever it calls it.
A model is a question the next person can change
With an analysis model, the next person adjusts choices such as the grouping and the time grain without editing SQL. On the SEGA team, switching the same analysis from daily to monthly, or to a total for the period, takes one click. The bigger gain is in who can pick the work up. An analyst sets up a model once and shares it as a sample, and an operator explores from it without filing a request.
"Analysis models are easy to operate even for live-ops members who aren't familiar with SQL, and they do actually use them as a base to explore on their own."
Funnel Analysis for new players shows the effect. The team builds one funnel and compares it by platform and by country, and Abe says they have become much faster at pinpointing where players get stuck. In the team's previous workflow, follow-up views like these commonly went back to an analyst who could write SQL.
If you run an analytics team, this is the part to notice. The shift changes what analysts do in meetings. On P5X, live-ops members now report KPIs themselves, and analysts bring the deeper investigation when a number needs one. The queue gets shorter as more routine questions stay with the live-ops members who ask them.
Tags keep the state a segment had before
Segments are where the query-first approach breaks down fastest. Most teams define a segment, such as players who bought a season pass or players who reached a certain level, as a filter inside a query. When each dashboard carries its own copy of the definition, the copies can diverge over time.
Abe's team defines segments once as tags, and any dashboard can filter or group by them. The detail Abe values most is time. A tag updates to each player's latest state, and its past states stay available. Live-ops questions are often comparisons across time, such as how the players who were big spenders before the last event behave today. A filter based only on the current state covers this morning's players, while the team can use the tag's history to answer both halves of the comparison.
Where SQL still belongs
The team still writes SQL for complex processing and for detailed checks on one player, and Abe suspects there may not be many analyses that truly need SQL. A workable test follows from that. Questions that come back with small changes are strong candidates for models, and complex processing and one-player checks stay in SQL.
There is a cost to this approach. Building in models takes more effort up front, as Abe acknowledges. The return comes from the follow-ups they no longer have to write, and from the investigations they finally have time for.
What an analytics lead can change this month
Start with your own request log from last month. Sort the requests by how often a question came back with a small change, such as a new grain, a new segment or a new date range. Those repeat requests are the candidates for models. A request for last week's retention by platform, followed a day later by the same view split by country, is a typical pair. Rebuild the five most common as shared models, define the segments they use as tags, and hand them to the people who asked. Then track whether the same requests come back over the following month.
Some SQL specialists may question the change. Show them which repeated requests consumed their time last month and which deeper investigations are still waiting, because that time comes from the requests they stop answering.
At SEGA, the result was a live-ops team that reads its own numbers and an analytics team that brings the deeper investigations. The P5X team does this in Agentic Engine, where Events Analysis, Funnel Analysis and Retention Analysis serve as the models and tags carry the segments, and the full story is in our SEGA case study.
The bottleneck was the queue all along. Build the question so the next person can change it, and the analyst stops being the only way in.
© ThinkingAI · Persona5: The Phantom X ©Perfect World Adapted from Persona5 ©ATLUS ©SEGA
