Membership analytics (admin)
Retention ops for the deployment owner: who's using their skills, whose usage is falling, and whose tool connection is broken, all from your existing telemetry.
Overview
Membership analytics is a read-only admin surface (deployment owners only, gated on ADMIN_EMAILS). It turns the control-plane telemetry your skills already emit (plugin runs, entitlements, and the MCP audit log) into three retention lenses, computed live each time you open the page. No new data collection, no cron. It sits next to the revenue-focused Dashboard and links each subscriber through to Users.
"Subscriber" here means a user with an active, trialing, or past-due subscription. To stay fast on large deployments, the page aggregates the most-recently-active subscribers up to a per-request cap and tells you when the cap is hit.
Per-subscriber usage
- Runs by plugin. How many skill runs each subscriber logged, broken down per plugin, busiest first.
- Average run duration. Mean run time across the subscriber's runs that reported a duration.
- Licensed plugins. The plugins the account currently holds an active entitlement for.
- Last active. When their most recent run landed.
Licensed-but-idle accounts still appear, with zeroed usage. A paid account that never runs anything is exactly what you want to catch.
Churn risk
Flags active subscribers whose plugin runs fell more than 40% from the previous 7 days to the last 7 days, sorted biggest drop first. A subscriber with no prior-week activity is skipped (a new or never-active account can't have "dropped"), and flat or growing usage is never flagged. A full drop to zero (with prior activity) reads as a 100% drop.
MCP health
- Silent accounts are subscribers who are licensed and have connected their tools but have run nothing in the last 14 days. That combination ("paid, set up to connect, not using it") is the strongest churn precursor, so it's called out separately from generic idleness.
- Failing connections are accounts with repeated denied MCP calls (3 or more) in the last 14 days, with the denied share of their total calls.
Why "denied" and not 401? The MCP audit log only records authenticated calls. A 401 from an unknown or revoked connection is never attributed to an account, so there's no row to count. "Failing connections" therefore counts denied calls: a connection that authenticates but is repeatedly refused for a missing scope. For unknown or wrong-endpoint problems, the account simply never appears in the audit log at all, which surfaces instead as a silent account or in each user's own Connect troubleshooting panel.
When a number here is not a measurement
Every lens on this page is a separate query. If one of them fails, the section it feeds falls back to empty so the rest of the page still renders, and a red banner at the top names the read that did not land along with the error.
Read that banner before you read the numbers. Without it, a query that never ran looks exactly like a healthy zero, and on a retention page a fake zero reads as churn. When the banner is absent, every count on the page is a real measurement.
Why it matters
Activation is only half the retention story. The other half is catching accounts that activated and then drifted. This view gives the operator a weekly worklist: who to re-engage (churn risk), who never got going (silent accounts), and whose setup is quietly broken (failing connections), before any of them shows up as a cancellation.
Related
- Admin Dashboard, sign-ups, revenue, seats, and the enterprise pipeline.
- Connect your tools, the per-user activation state these analytics roll up.
- API Keys & MCP, the connections and MCP server the health view watches.