Designing Enterprise Analytics for AI Adoption and Cost Visibility
Turning fragmented usage reports into clearer analytics surfaces for users, teams, and admins managing AI adoption at scale.
- Analytics UX
- Enterprise Admin
- AI Usage
- Data-heavy UI
- Product Strategy
Status: this case study covers work that moved from research and UX direction into active development. Some surfaces are in progress or staged behind review links, so I describe them as product direction and implementation work rather than fully released outcomes.
Tabnine Analytics needed to evolve from a set of fragmented reports into a clearer system of analytics surfaces. Admins, team leads, and individual users were asking different questions — who is using Tabnine, how teams are adopting AI tools, what it costs, and which models or tools are driving usage.
My role was to connect research, benchmark analysis, IA direction, and UI design into implementation-ready analytics surfaces: personal usage, team-level comparison, improved user reports, and deeper agent/tool breakdowns.
The challenge was not to add more charts. It was to create a more trustworthy analytics model.
Analytics was spread across multiple surfaces — an in-app section, exported CSVs, dashboards derived from other data pipelines, and a usage API. The same conceptual metric could appear differently depending on source, timeframe, or surface, which made it hard for anyone — admin, team lead, or engineer — to point at one number and trust it.
Several distinct problems sat under the same “analytics” umbrella:
- Admins needed team-level adoption and cost visibility across the org.
- Individual users had no way to see their own usage, quota context, or cost.
- The existing user report used terminology and structure that made scanning slow.
- Technical usage — agent, MCP servers, tools — didn’t have a clear place to live.
- Not every event that existed in the pipeline was ready to become a customer-facing metric.
The core work wasn’t adding charts — it was deciding which questions each surface should answer, and only promoting the metrics we could defend.
Four audiences, four questions.
The research used competitor benchmarks as a clarity reference, not a feature checklist. For Tabnine, the opportunity was in the enterprise admin experience: governance, cost and model visibility, team reporting, and deployment flexibility. Reframing the work around audiences — rather than reports — gave the analytics IA a spine, and turned scattered reporting needs into a structure each audience could navigate.
Individual user
“How am I using Tabnine?” — their own activity, quota context, and token/cost visibility.
Team lead / manager
“How is my team adopting AI tools?” — active users, activity mix, and where adoption is landing vs. lagging.
Admin
“Who is active, what does it cost, and where is usage concentrated?” — cross-team comparison plus per-user detail.
Technical / product owner
“Which models, tools, MCP servers, and platforms drive usage?” — normalised breakdowns across supported agent surfaces.
Existing surfaces, mapped to real questions.
The redesign did not start from a blank slate. Tabnine already had several analytics surfaces: Overview, Chat Usage, Agent Usage, Usage per User, and Account Utilization. The problem was that these pages were organized around existing reports more than around the questions admins, team leads, and users needed to answer.
I mapped the existing pages to the questions they already answered, then identified the missing surfaces and report improvements needed to complete the analytics story.
Surface 01: Overview
A broad admin-facing view of usage across users and the account.
Surface 02: Chat Usage
A workflow-specific view into chat activity and usage patterns.
Surface 03: Agent Usage
A workflow-specific view into agent activity, including deeper technical usage such as tools and MCP.
Surface 04: Usage per User / Users
A user-level admin report. The redesign renamed it to Users and improved scanability, columns, sorting, tokens, cost, and terminology.
Surface 05: Account Utilization
An account-level view of utilization and quota context.
0104
My Analytics
A personal analytics page for individual users to understand their own usage, activity, quota context, tokens, and cost.
0204
Teams Overview
A new team-level comparison surface that helps admins understand adoption, activity, cost, tokens, and platform usage across teams.
0304
Users
An improved version of Usage per User, redesigned for faster scanning and clearer terminology.
0404
MCP / tools breakdown
A deeper technical analytics layer inside Agent Usage, showing MCP server activity and tool-level drill-downs where the data supports it.
The calls that shaped the work.
Six decisions shaped the analytics model before the first table was drawn.
Reframe existing analytics pages around user questions.
We decided
I mapped each existing report to the question it helped answer, then identified the missing pieces: personal analytics, team comparison, clearer user reporting, and deeper MCP/tool breakdowns.
Why it worked
This kept the redesign grounded in the existing product while giving the analytics IA a clearer logic. The work became less about adding pages and more about connecting existing and new surfaces into a trusted analytics experience.
Make Teams Overview the main comparison surface for admins.
We decided
Create a team-level comparison surface first, focused on team identity, active usage, activity mix, and adoption signals. Additional metrics such as models, tokens, cost, and platform context can expand the surface where the data supports them.
Why it worked
Admins consistently framed their question as “how do teams compare?” not “show me every user.” The comparison view had to come before the drill-down.
Add personal analytics without making it a leaderboard.
We decided
My Analytics is visible to user roles including members. It shows personal usage, activity, tokens/cost, and quota context — designed as self-awareness, not performance ranking.
Why it worked
Individual users had no way to see what they were consuming. Framing this as personal awareness — not comparison — kept the surface useful without turning analytics into a scoreboard.
Make the existing user report more scannable.
We decided
Rename “Usage per User” to “Users.” Clearer columns and order, sortable columns, Active + Last Seen, Total Tokens and Estimated Cost, Productivity Factor in place of Automation Factor, “interactions” in place of “messages.”
Why it worked
The old terminology carried baggage from earlier product phases. Renames were the cheapest way to lift comprehension for admins reading rows top-to-bottom.
Move MCP / tool visibility into the right analytics context.
We decided
Pull the tool/MCP breakdown out of the old Usage tab and re-home it in the analytics surface, with a table by MCP server plus a drill-down sheet exposing per-tool activity — normalised across supported agent sources where the data supports it.
Why it worked
MCP usage was surfacing in a tab that people didn’t read as analytics. Moving it in-context made the technical view discoverable for the audience that actually asks about it.
Treat metric readiness as a UX constraint.
We decided
Only validated metrics are promoted to customer-facing analytics. Candidate metrics stay internal or deferred. Reliability, freshness, and insufficient-data states are part of the design, not a footnote.
Why it worked
Event existence isn’t the same as metric readiness. Showing a number we couldn’t defend was a bigger risk than showing fewer numbers.
New and improved surfaces, moving through implementation.
The analytics model resolved into four surfaces, each mapped to an audience. Screenshots below show the current implementation state — some pieces are in review, some are rolling out.
My Analytics
A personal analytics page available to admin, manager, team lead, and member roles. Timeframe filter, monthly utilization, tokens and cost, activity, model usage, and MCP/tools — sized to first-phase scope where utilization and tokens/cost are the strongest must-haves.
Teams Overview
A new admin surface for comparing adoption and activity across teams. The first phase covers team identity, registered and active users, % active, agent/chat activity, interactions, and lines of code. Later additions extend the surface with models, tokens, cost, and platform context where supported — with search, sorting, filtering, and pagination aligned to the data model.
Users report
The existing per-user admin report, reshaped for scanability. Renamed to Users. Clearer columns and order. Active and Last Seen. Sortable columns. Total Tokens and Estimated Cost. Productivity Factor in place of Automation Factor. “Interactions” replaces “messages.”
MCP / tools breakdown
A table by MCP server for a chosen timeframe — calls, share of total, active users, and trend. A drill-down sheet exposes tool-level usage for a selected server without leaving the analytics context. Naming is normalised across supported agent sources where the data supports it, and native tools are separated from MCP server activity.
What the model is set up to enable.
Because the work is still moving through development, the outcomes below are qualitative and forward-looking rather than measured. They’re framed by what the analytics model is set up to enable once each surface is fully rolled out.
Outcomes
- Turned analytics discovery into implementation-ready work — opportunity framing and IA direction became specs for personal, team, user, and MCP analytics surfaces.
- Created a clearer analytics model — existing and new surfaces were connected into a model that matches how each audience asks their question.
- Helped admins compare AI adoption across teams — the comparison surface comes before drill-down, so admins can start at the level where their question lives.
- Gave individual users personal usage visibility — quota context, tokens, cost, activity, and model usage can be understood without turning the surface into a leaderboard.
- Improved scanability of existing reports — clearer naming, sortable columns, and additional token/cost/productivity context make user-level reporting easier to read.
- Made metric readiness a design constraint — data availability is treated separately from what’s ready to surface, so only defensible metrics move into the UI.