Membership analytics (admin)
Retention ops for the deployment owner: who's using their plugins, whose usage is falling, and whose Cowork 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 plugins 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 — subscribers who are licensed and have an active API key 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 keys — keys 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 key is never attributed to an account, so there's no row to count. "Failing keys" therefore counts denied calls: a key that authenticates but is repeatedly refused for a missing scope. For unknown-key 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.
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 keys), before any of them shows up as a cancellation.
Related
- Admin Dashboard — sign-ups, revenue, seats, and the enterprise pipeline.
- Connect to Cowork — the per-user activation state these analytics roll up.
- API Keys & MCP — the keys and MCP server the health view watches.