How-toAnalytics

How to measure internal tool adoption: metrics, instrumentation, and what good looks like

"Is anyone using the new tool?" is the most-asked and least-answered question in internal software. This is the practical guide: the four metrics that matter, how to collect them across a whole portfolio without an engineering quarter, and how to read the numbers once you have them.

July 21, 2026 · 7 min read

The four metrics that matter (and two that don't)

Metric	What it answers	Watch out for
Active usage — pageviews and distinct visitors per period	Is the tool alive at all? Is the trend up or down?	Absolute numbers mean little; trend and share of the eligible audience mean everything.
Function adoption — usage of specific features/actions	Which parts of the tool earn their maintenance cost?	Without this, "the app is used" hides that 80% of its features aren't. Your dead-feature list writes itself.
Sentiment — in-context ratings on real pages	Do the people using it want to?	Annual surveys measure memory, not experience. Rate the page they're on, at the moment they're on it.
Reach into workflows — funnels across key paths	Do users complete the journeys the tool exists for?	A used tool with a broken core path is worse than an unused one — it wastes time and trust.

Two metrics to ignore: logins (SSO auto-login makes them meaningless) and ticket volume (silence usually means abandonment, not satisfaction — see the captive user fallacy).

Instrumentation: the portfolio-friendly way

The classic failure mode is treating instrumentation as a per-app project — taxonomy workshop, tracking plan, sprint. That works for one app and dies at ten. The portfolio-friendly rules:

Pageviews come free or not at all. A script tag in the shared layout should capture pageviews and SPA route changes with zero configuration. If step one needs a meeting, coverage will never happen.
Feature tracking is declarative. Tagging a button with an attribute — data-feedback-action="export-csv" — is a one-line PR any team merges in passing. A JS event pipeline is a project they'll defer. (Details: feature analytics with one HTML attribute.)
Feedback rides the same snippet. If ratings and comments need a second tool, they'll never be deployed. One install, both signals.
Anonymous by default. Identity turns a two-week rollout into a two-quarter legal review, and you don't need it to answer adoption questions. (See anonymous by design.)

What "good" looks like

Benchmarks for internal tools are scarce, so use these as starting heuristics, not gospel:

Reach: a tool serving a defined audience (e.g. "all managers") should see 60%+ of that audience monthly; a daily-workflow tool, 80%+ weekly. Below 30%, treat it as a retirement candidate pending investigation.
Ratings: on a 5-star in-context scale, portfolio averages land around 3.8–4.2. Under 3.0 sustained for a month is a fire; over 4.5 with high usage is a tool worth studying and copying. (For NPS specifics: what's a good NPS for an internal tool?)
Trend beats level. A 3.6 rising from 3.1 is a success story; a 4.0 falling from 4.4 is an incident. Review period-over-period movers, not league tables.
Function spread: if under 20% of tracked functions get 80% of use, you've found your simplification roadmap.

Close the loop or don't bother

Measurement that ends in a dashboard changes nothing. The numbers need two standing rituals: a monthly portfolio review (movers, bottom-rated, retirement candidates — see the portfolio audit playbook) and a feedback-to-backlog pipeline so user comments become triaged, evidence-backed work items instead of a read-only sadness feed (see from stars to sprint).

Where Morvero fits: everything above is Morvero's default behavior — one script tag per product, SPA-aware pageviews, declarative function tracking, in-context ratings, funnels on already-collected data, and dashboards that rank every product by usage and sentiment. Instrument your first two products free.