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
Below the funnel, the quality line counts the stalled-setup email. Once per account, when a setup has not moved for two days (and no more than seven) at a step before the first draft, the daily lifecycle run emails the founder from the platform's own address. The email names the step they stopped at and the one thing to do next. When SETUP_CALL_URL holds an https booking link, it offers a 20-minute setup call; when it is unset, it asks for a reply. Accounts that opted out of either platform email, or whose address bounced or complained, get nothing. The line shows how many were sent and how many of those accounts reached a first draft afterwards. Bookings and replies are not counted, because neither reaches the platform. The email ends with the same signed unsubscribe link the weekly digest uses, and carries it in a List-Unsubscribe header. The link opens a page with an Unsubscribe button, and one press, with no sign-in, stops both emails.
The page opens with the founder funnel for accounts created in the last 90 days. Each count sits beside its versioned definition. Select a metric to inspect its evidence, denominator, deduplication and exclusions: each account counts once per stage, and every stage leaves out the @example.invalid test accounts plus its own named cases. Undecided accounts stay separate from measured failures, and while any stage holds them the notice at the top becomes a warning to keep them out of the qualified funnel; an unavailable funnel displays no fallback zero counts. Usage, retention and the detailed funnel charts remain in the disclosure below.
Trace the cohort lets you choose the period: the last 30, 90 or 180 days, or quarter to date. The funnel, its heading and the denominator follow the choice, and 90 days stays the default. Data freshness is the newest evidence row the funnel read for that cohort (sign-ups, onboarding events, runs, drafts, sends, opportunities and payment receipts), so a quiet source shows as an old time rather than as the moment the page loaded. Review receipt model opens the receipts guide.
Onboarding by source splits the same cohort by where each account first came from: the utm_source tag on the link it arrived by, else the site that sent it, else direct. The source is the first page view the visitor's browser recorded after they accepted analytics, copied onto the account at signup and never changed afterwards. Each row shows signups, confirmed briefs, first drafts, verified checkouts and the share that paid, so you can see which source converts for any period you pick. Accounts with no record read "not recorded": they signed up before October 2026, declined analytics, or never saw the cookie banner.
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 an account holding at least one entitlement that someone paid for, live and not expired. The seat every account is granted at signup is excluded, so signing up does not put a row on this page; buying something does. To stay fast on large deployments, the page aggregates the most-recently-granted 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 a live paid entitlement for. The signup seat is not one, and does not appear here.
- 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.
Why customers cancelled
Counts by reason over the last 30 and 90 days, one reason per account. Reasons come from two places. The Cancel subscription button on Settings and Team admin asks one optional question before Stripe opens: too expensive, did not see results, missing a feature, switching to another tool, taking a break, or other, with a note. The billing webhook also reads Stripe's own cancellation_details (reason, feedback, comment) from the subscription events it already receives. When an account answered both, the answer in the app counts, because its list is ours. Stripe's "not using it" counts as did not see results, and its raw value is kept beside the mapped one.
An answer in the app is saved before the customer reaches Stripe, so it counts even if they then kept the subscription. Payment failures and disputes are not counted here; the cancellations queue on the admin dashboard lists those. Under the table sit the newest notes from the last 90 days, one per account, up to ten. This section is visible to the deployment admin only, and the table it reads is closed to the tenant database role.
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.
Release acceptance
Release acceptance uses the same administrator access check. Choose a provider and operation to read its recorded state, repository paths and live-verification receipt or blocker. The ledger lists the selected provider's operations. When several operations share one blocker, the ledger states it once above the table and those rows point at it. The full matrices and journey coverage remain in a disclosure below.
When the selected row is open because of something outside the repository, usually a vendor account nobody here holds, the notice changes to External access blocks this acceptance row: prepare the exact verification action, keep the row open and carry on with other work. Inspect blocked row jumps to such a row, in the selected provider first. It is disabled, with the reason on hover, when no row is blocked that way.
Built means a repository implementation has been recorded. It does not mean a live operation passed. This read-only page does not change acceptance records, approve a release or contact a provider.
Status incidents
Status incidents uses the same administrator access check. It is where you tell customers about a problem the automatic checks on the public status page cannot describe. Open an incident with a title, a state (Investigating, Identified or Monitoring) and a first update. Each later update adds a timed line under the incident, and choosing Resolved closes it. The public page shows every open incident and those resolved in the last seven days, newest first, with each incident's updates newest first. While an incident is open, the public headline reads Incident in progress. A post can take up to 45 seconds to appear for every visitor, because the status page keeps its incident list for that long between reads. An incident keeps its 50 most recent updates; older ones drop off. The audit log records each post's state, title and message text.
Updates are public as soon as you post them, so write them for customers: what they will notice and what to do meanwhile. The page does not show who posted; the audit log records that. If another administrator posts at the same moment, your post is refused with a request to reload, rather than one update silently replacing the other.
The public page also reports four automatic conditions. Research, work delivery and connection sync come from scheduled job receipts. Draft placement comes from the last 24 hours of Gmail and Outlook draft placements: Delayed when the latest one could not be confirmed by the mailbox provider, No recent data when none was placed. A refusal for one account's own reason, such as an expired connection, does not count against it. Configuration checks, such as a test payment key on production, appear in the admin views and the uptime monitor but not in the public headline.