Analytics

The Analytics section has two reports. Adoption answers how much of your organization is using PulsVault at all; Feature usage answers which parts of it.

Every figure comes from records the platform already keeps — memberships, the second-factor enrolment flag, session activity and the audit trail. Nothing extra is collected to produce these pages. That is a deliberate limit, not an oversight: PulsVault adds no telemetry to measure your people. Adoption reads only whether each member has been active recently, and Feature usage adds up actions the audit trail already records for your administrators, per area and never per person.

Adoption#

Reports → Analytics → Adoption Metrics shows, for the last 7, 30 or 90 days, each figure together with its gap, and links the gap to the place where you can act on it. The period is the same one Feature usage uses — whole days, today included — so "the last 30 days" means the same span on both pages.

• Active in the last N days — members who used PulsVault in the period, against your total, with the number who did not. A member who has never signed in is not counted: never-used is not recently-used, and a session an administrator ended does not count as use. A link opens the Security posture on the members with no sign-in for 90 days. That is its own measure, so its list is not the gap for a 7- or 30-day period, and the link says so.
• Have a second factor — members with a completed enrolment, labelled with the rule your organization set:
  • Required for everyone — the card turns amber when anyone has not enrolled, and links to the Security posture, which splits them into members, administrators and those still in a grace window.
  • Required for administrators — neutral; the link lists administrators without a second factor.
  • Not required — neutral and unlinked. This is adoption, not compliance: nobody is out of line with a rule you did not set, so the page does not colour it as a failure.
• Where people use PulsVault — distinct people per platform (web, desktop, mobile) active in the same period. Somebody who uses two platforms appears under both, so these deliberately do not add up to your member count.

Adoption shows no up or down arrows. A session keeps only the last time it was used, so someone active in both periods would drop out of the earlier one, and every comparison would read as a decline that did not happen.

Which features do they use? opens Feature usage. A link to a screen your plan does not include still shows, marked with a lock, and explains what would open it rather than leaving the gap with no next step.

Feature usage#

Reports → Analytics → Feature Usage shows, for the last 7, 30 or 90 days, how many people used each area of PulsVault — vaults, credentials, sharing, secure links, secure notes, two-factor, trusted devices, import and export, and on plans that include them tasks, projects, DevOps secrets, credential validation, travel mode and breach monitoring.

It is read from your organization's audit trail, which already records these actions for your administrators — nothing extra is collected to draw it, and it shows counts per area, never what a given person did. Only deliberate, successful actions count: signing in, browsing a vault list, a share expiring on its own or an attempt that was refused is not "using" anything. Confirming a sign-in code is the one exception, and only for Two-factor: it is real use of your second factor.

Every figure counts your current members. People, actions and active people are all taken from the successful actions of members who are active in your organization today, and reach divides by that same number — so reach can never pass 100%. Active people are the members who used at least one of the areas listed; signing in, even with a code, does not make someone active — that is what Adoption's Active figure shows. Actions by someone who has since left, by support staff, or by a pipeline are not in these figures.

• People — distinct current members who used the area in the window. An arrow shows the change against the same length of time just before, when your audit retention covers all of it and the area is fully recorded.
• Reach — those people as a share of every member of your organization, so seats nobody uses show as low reach rather than dropping out of the figure.
• Actions — with its own arrow, by the same rule. Select the number to open the Trace explorer on exactly the rows counted: the same actions, successful ones only, by current members, over the same period to the second. Change the dates there and you leave the report's period.
• Untouched areas are included in your plan and fully recorded for the whole period, but nobody used them. If people did use one in the period just before, the row says how many, so a drop to zero stays visible.
• No recorded use is what a zero says when the page could not see the whole picture — some of the area's actions are switched off in your audit settings, or your retention starts after the period does. It is not counted as untouched, because a zero there is not evidence nobody used it.
• Not recorded areas are ones your audit settings switch off — a count of zero there would mean nothing, so none is shown. An area marked Partly recorded has some of its actions switched off, so its figures are a floor and it shows no arrow. This reflects your settings as they are now — so if you changed them during the period, the page says when, treats every zero as no recorded use, and shows no arrows.
• Since … appears when your audit retention is shorter than the period you picked; the figures start on that date.
• Machine activity — on plans with DevOps secrets, what your machine identities did, shown on its own. The DevOps secrets row counts people, not pipelines.
• Areas your plan does not include are listed with a lock, never as "0 people".

Team Business Enterprise

What these reports do not show#

• Browser extension use. A sign-in from the extension is recorded as a web session like any other, so the platform cannot distinguish them. It is left out rather than approximated from the web figure.
• Click-level behaviour. No telemetry is collected; feature usage counts only the actions the audit trail already records.
• When people work. There is no access-pattern heatmap by hour. These reports count areas and periods, not anyone's working hours.

Turning numbers into action#

• Low sign-in rate — re-onboard dormant accounts, or reclaim seats nobody is using. The Security Center's Members with no sign-in for 90 days count opens the list of exactly who.
• Low second-factor adoption — asking rarely moves it. Requiring it does, via Authentication policies; the Security posture then tracks who has not enrolled and whose grace window is still open.