Measuring whether anyone actually uses your BI platform

Licences assigned goes up because IT assigns licences. Dashboards published goes up because publishing is easy. Total views goes up because a handful of power users refresh a lot. All three are reported monthly in a lot of organisations, and none of them can distinguish a healthy deployment from an abandoned one.

The question they are standing in for is simple to state and awkward to measure: did people stop doing the thing the platform replaced. Usually that thing is a spreadsheet somebody rebuilds by hand every month, and the honest adoption metric is how many of those still exist.

Everything below is a proxy for that question. The proxies are worth tracking because they are cheap and continuous, but keep the real question visible, because a dashboard nobody trusts gets viewed and then ignored, and the view still counted.

Report the distribution, not the average, on every row that has one. An average days-since-login of eleven can mean everybody logs in fortnightly, or it can mean half the organisation logs in daily and half stopped in March. Those need different responses and the average hides which one you have.

Six measures is the ceiling for a monthly report somebody actually reads. If you add a seventh, drop one.

Nothing here needs to be built. Tableau's engagement guidance names the exact questions and the exact data: how many times users have logged in, how many logged in once and did not return, how many never logged in, and how many days since each user's last login, sourced from Tableau Server Insights on Server or Admin Insights on Cloud.

For content-level usage, Traffic to Views shows total view count by day and by time of day, which views are seen the most, and which users access views most often. The inverse question is answered by the Stale Content view, which identifies content not accessed within a threshold from one to 120 days and reports the disk space it uses.

On Power BI, usage metrics in workspaces track daily report views and viewer patterns to show which reports drive engagement. Read the prerequisites before promising anyone a number: running the report needs a Pro or Premium Per User licence and edit access to the report, and an administrator has to have enabled usage metrics for content creators, with per-user data a separate setting again.

That last detail is the one that catches teams. Per-user detail is off by default in a lot of tenants, which means your return-rate metric is unavailable until somebody changes a tenant setting. Find that out in week one of the reporting design, not week four.

A finance director who receives a subscription email every Monday and reads it on their phone has adopted the platform completely. They will also appear in a login report as dormant.

Tableau's framing counts both: direct engagement means viewing, interacting, connecting and web authoring, while indirect engagement means subscriptions and alerts delivered to a user. Both belong in the report, labelled separately.

This matters more than it sounds, because the response to each is different. Low direct engagement with high indirect engagement is a working deployment with a distribution model. Low on both is a problem. Reporting them as one number makes those two situations look identical.

It also affects what you build. If most of your executive audience is on subscriptions, then a change to a dashboard layout that breaks the emailed rendering is an outage for them, and nobody will report it as one.

Adoption reporting almost always shows a cumulative line, and cumulative lines only go up. Plot month three against month one for the same cohort of users instead, and you get the shape that actually predicts the next year.

The expected pattern after a launch is a spike, a fall, and then a plateau. The number that matters is the plateau, not the spike, and you cannot see it until about month four. So do not declare success at week six, and do not panic at week ten.

If the plateau is well below the spike, the cause is nearly always the same and it is not the tool. Somebody's first real task on the platform did not work, they went back to the spreadsheet, and nothing brought them back. That is a training and support failure, which is why the fix lives in the training plan and who answers questions after go-live rather than in the platform configuration.

Microsoft's adoption material is useful here because it refuses to treat adoption as a single number, describing organisational adoption, user adoption and solution adoption as distinct maturity questions. A deployment can be strong on one and weak on another, and a single percentage cannot show that.

Any metric attached to a target gets managed. View counts rise when somebody sets a dashboard as a browser homepage. Published content counts rise when an analyst splits one workbook into four. Licence utilisation rises when unused licences get reassigned rather than reclaimed.

The defence is not more metrics, it is a named owner who reads them and asks about the exceptions. Six numbers with a person attached beats twenty with a distribution list.

Do not tie individual performance to any of these. The moment a team's usage is a performance measure, the numbers stop describing reality and the report becomes worthless for the decision it exists to support.

And keep asking the unglamorous question directly. Once a quarter, ask each team which reports they still maintain by hand and why. On a multi-location reporting engagement covering 15 or more clinics with quarterly reporting produced from live data, the measure that mattered was that the manual assembly step disappeared, not that view counts went up. That is what automated client reporting is for, and it is the only adoption evidence a sponsor genuinely believes.

Report the six measures monthly for two quarters after a platform move, then drop to quarterly and keep going. Adoption reporting that stops after the launch celebration measures the celebration.