Whoever stopped showing up has a name, a date, and a list

The retention dashboard has a block that doesn't return a percentage: it returns people. The endpoint applies two cutoffs at once. The member's last recorded presence fell between 14 and 44 days ago. And they posted or commented at least three times in the 30-day window ending at that 14-day cutoff.

The two cutoffs together are the point. Whoever never participated doesn't make the list — there's no point chasing the return of someone who never showed up. Whoever disappeared yesterday doesn't make it either. What's left is the member who was in, participating, and stopped.

Each row carries the name, the avatar or initials, accumulated XP, how many times they participated before disappearing, how long they've been quiet, and the exact date of their last presence. Whoever went quiet most recently shows up first. The default is twenty names, and the limit parameter goes up to a hundred — it's a snapshot of the most recent silences, not a scan of the entire base. The same block exports as CSV, with name, date, and prior activity per row.

Three numbers with a comparison: D7, D30, and D90. The definition is narrow on purpose, and it's worth reading slowly. The D7 cohort is the members who signed up in a one-day window that ended seven days ago — it isn't everyone who joined that week. Staying active means having recorded presence, a post, a comment, or a like in the last seven days. Each of the three is also recalculated as it stood thirty days ago, so you read the direction, not just the value.

The cohort size shows up on the card, next to the percentage. It's the detail that keeps the metric from lying: full retention on a cohort of two signups is noise, and the screen says it's two.

A fourth block shows the study-streak distribution — how many members have no streak, how many have one to three days, and so on — based on each student's current streak and record.

The whole lens exports to CSV, with one button.

The retention lens says who disappeared. The member profile says where.

In a single student's dashboard, the system puts together, on one screen: the last lesson watched, with the lesson title, the course title, and the date they stopped. The percentage completed for each course they have active access to, calculated over the course's total lessons. Every track enrollment with its current status — active, paused, completed, or abandoned — with total and completed steps. Issued track certificates, with serial number, status, and date. Last presence. Trust level with active days, posts, comments, and likes counted. And how many of their sessions are still open, counted from still-valid access tokens.

In aggregate, the same data becomes a funnel. Each track has its own analytics: how many enrolled reached each step, how many completed or skipped it, and the average completion time for those who finished. The onboarding journey has a funnel by mission and flags on its own the transitions with the biggest drop-off, with the name of the origin mission and the destination mission.

Your community's backend has twelve registered schedulers. This is all of them.

Email digest, every day at nine in the morning — the job wakes up daily and sends to whoever chose that day of the week, skipping banned members, with a pause between sends and a record in the history. Expired course access turns to EXPIRED hourly, and fires an event. Track access, the same. Track steps with date-based release unlock hourly. A dated class flips to RUNNING on its own and advances the unlock schedule, hourly. Inactivity demotion at midnight: thirty days with no recorded activity date in trust progress and the member drops a level, with history and reason recorded. An expired penalty is deactivated hourly. Marketplace escrow and paid featuring expire hourly. Video size syncs every five minutes. The AI course generator queue is swept every twenty seconds — resumes a stuck task, closes an idle job — and attached source files are deleted from the CDN at four in the morning.

Separate from that, push: every notification created triggers a web push send, respecting the member's per-type on/off setting and your own backend's VAPID keys.

There's no automatic reminder for a stalled lesson. None of the twenty-eight notification types cover that, and no scheduler looks for stuck progress. The list of who stopped exists; the come-back email doesn't go out on its own.

The onboarding reminder calculates who's eligible — inactivity time, incomplete mission, days since joining — and already excludes whoever received one before. But it has no sender and no scheduler: the test send returns a preview, and the function that logs the send has no caller anywhere in the repository. Today it's a segmentation rule, not a sending rule.

There's no bulk send to a segment. The announcement email template exists in the template CRUD, with documented variables and versioning, and no code sends it.

The at-risk list isn't clickable. Seeing the name there and opening that student's profile are two separate moves: the list item has no link and no action, and the admin looks the person up on the members screen by hand.

The presence that feeds "how long since they disappeared" is recorded at a single point: the connection and disconnection of the community chat socket. Posts, comments, and likes feed into the D7, D30, and D90 counts; on the at-risk list, the only signal is presence.

The digest only reaches whoever has a saved preference, and that record is created when the member opens the notifications screen for the first time — not at signup.