Analysis Rate
How much of your query volume is real analysis, and how much is orientation and upkeep.
47 percent of the activity we observed is actual analysis. The rest is maintenance and exploration. Fewer than half of the queries this team ran answered a business question. The other 53 percent went on finding out what data exists and keeping the estate tidy.
More than half of the query volume you read as output is your team finding its way around an estate nobody ever documented. It still gets counted, and it still gets reported. Volume tells you how much your team produces. Analysis Rate tells you how much of that production lays down precedent someone else can build on.
You do not know your own split yet. Last week's query log holds it, off your own history, for free.
What it tells us
What a person runs by hand falls into three kinds. Analysis is a decision about how to answer a real business question. Exploration is finding out what data exists. Maintenance is the scratch tables, one-off backfills, and ad hoc fixes that never became a model. Somewhere in your warehouse there is a table called tmp_final_v2, and something in production is reading from it.
Only analysis lays down reusable precedent. Exploration and maintenance are necessary, and no team works without them, but they teach a new hire or an AI agent nothing worth keeping. The analysis share is the instructive part, the record of how the work actually gets done. It is also the only part worth handing to an agent, because the rest teaches it your housekeeping.
What we found
In one estate we assessed, the analysis rate landed at 47%, slightly less than half. The remaining 53 percent split between exploration, analysts orienting in the undocumented corners of the warehouse, and maintenance.
The exploration share is the one that tells you something. When a large part of the effort goes to re-discovering what data exists, the map for that estate lives in people's heads rather than in documentation. The two queries below are twins. Both are SELECTs, and only intent tells them apart.
-- what does this table cover?
SELECT date_trunc('month', fill_date) AS m,
count(*)
FROM pharmacy_claims
GROUP BY m
ORDER BY m;
Someone is looking to see what is in the table. It checks which months the data covers and stops there. Nothing downstream reuses it.
-- statin adherence for the enrolled cohort
SELECT member_id,
covered_days::float / eligible_days AS pdc
FROM fct_medication_adherence
WHERE drug_class = 'statin';
A real decision about how to define the metric. It sets what counts as adherence, covered days over eligible days, for one drug class. This is the logic worth keeping.
Both filter or group. One is orientation. The other lays down a definition. Statement shape sees no difference between them, and only intent does. Your query log will happily count them as two queries and call it a productive morning.
Why it matters to you
Half the output is orientation tax. You pay it because the data is undocumented, and you pay it again every time the last discovery evaporated before the next person needed it.
This is a capacity number. Less time re-learning the warehouse means more of each week becomes net-new analysis, without adding a head.
Only the analysis half teaches the agent. Feed it the whole history raw and it learns your housekeeping alongside your judgment.
Better documentation lowers the exploration tax for everyone. The map moves out of people's heads and into a place the next analyst can read.
What good looks like
Analysts spend less of each day re-discovering the warehouse, so a higher share of the week becomes net-new analysis, the work someone is actually paying for. The 47% that is real analysis stops being a number in a log and starts being a record the next person can read: what the team decided, and why. That is the difference between knowledge sitting in people's heads and an institutional knowledge asset, a set of files readable by humans and machines that meets five criteria. And the agent answering on top learns from the analysis, not from the DROP TABLE habits sitting next to it.
What to do about it
- Run Neuron on your query history.
- Read the split across analysis, exploration, and maintenance.
- Find the undocumented domains driving the exploration share, and document those first.
- Publish the definitions carried by the analysis queries into the semantic model, so your BI tools and your agent both read the same map.
- Pull a week of queries from one team. Most warehouses keep 365 days, so any recent week will do.
- Sort them into analysis, exploration, and maintenance.
- Read the analysis share against the total.
- Note which tables the exploration keeps returning to, and write those up first.