Qui a cessé d’apparaître a un nom, une date et une liste

Le tableau de bord de rétention a un bloc qui ne renvoie pas de pourcentage : il renvoie des gens. L’endpoint applique deux seuils en même temps. La dernière présence enregistrée du membre est tombée entre 14 et 44 jours plus tôt. Et il a publié ou commenté au moins trois fois dans la fenêtre de 30 jours qui se termine à ce seuil de 14 jours.

Les deux seuils ensemble sont le point clé. Qui n’a jamais participé n’entre pas dans la liste — inutile de réclamer le retour de qui n’est jamais arrivé. Qui a disparu hier n’entre pas non plus. Il reste le membre qui était dedans, qui participait, et qui s’est arrêté.

Chaque ligne porte le nom, l’avatar ou les initiales, l’XP accumulé, combien de fois il a participé avant de disparaître, depuis combien de temps il est silencieux et la date exacte de la dernière présence. Qui s’est tu en dernier apparaît en premier. Par défaut, vingt noms, et le paramètre de limite va jusqu’à cent — c’est un extrait des silences les plus récents, pas un balayage de toute la base. Le même bloc sort en CSV, avec nom, date et activité antérieure par ligne.

Trois chiffres avec comparaison : D7, D30 et D90. La définition est étroite exprès, et ça vaut la peine de la lire lentement. La cohorte D7, ce sont les membres inscrits dans la fenêtre d’un jour qui s’est terminée il y a sept jours — ce n’est pas tout le monde entré cette semaine-là. Rester actif signifie avoir une présence enregistrée, un post, un commentaire ou un like dans les sept derniers jours. Chacun des trois est aussi recalculé tel qu’il était trente jours plus tôt, pour que vous lisiez la direction et pas seulement la valeur.

La taille de la cohorte apparaît sur la carte, à côté du pourcentage. C’est le détail qui empêche la métrique de mentir : une rétention pleine sur une cohorte de deux inscriptions, c’est du bruit, et l’écran indique qu’ils sont deux.

Un quatrième bloc montre la répartition des séries d’étude — combien de membres n’ont aucune série, combien en ont une d’un à trois jours, et ainsi de suite — à partir de la série actuelle et du record de chaque élève.

Tout l’axe s’exporte en CSV, avec un bouton.

L’axe de rétention dit qui a disparu. La fiche du membre dit où.

Dans le tableau de bord d’un seul élève, le système assemble, sur un écran : la dernière leçon regardée, avec le titre de la leçon, le titre du cours et la date où il s’est arrêté. Le pourcentage terminé de chaque cours auquel il a un accès actif, calculé sur le total des leçons du cours. Chaque inscription à un parcours avec son statut actuel — active, en pause, terminée ou abandonnée — avec étapes totales et terminées. Les certificats de parcours émis, avec numéro de série, statut et date. La dernière présence. Le niveau de confiance avec jours actifs, posts, commentaires et likes comptabilisés. Et combien de ses sessions restent ouvertes, comptées par les jetons d’accès encore valides.

Au niveau agrégé, la même donnée devient un entonnoir. Chaque parcours a son propre analytique : combien d’inscrits ont atteint chaque étape, combien l’ont terminée ou sautée, et le temps moyen de complétion de ceux qui ont terminé. Le parcours d’onboarding a un entonnoir par mission et marque seul les transitions où la chute est la plus forte, avec le nom de la mission d’origine et de la mission de destination.

Le backend de votre communauté a douze planificateurs enregistrés. Ce sont eux tous.

Digest par e-mail, chaque jour à neuf heures du matin — le job se réveille quotidiennement et envoie à qui a choisi ce jour de la semaine, en sautant les membres bannis, avec pause entre les envois et enregistrement dans l’historique. L’accès à un cours échu passe à EXPIRED toutes les heures, et émet un événement. L’accès à un parcours, pareil. L’étape de parcours avec libération par date est débloquée toutes les heures. La classe avec une date passe seule à RUNNING et fait avancer le calendrier de déverrouillage, toutes les heures. Rétrogradation pour inactivité à minuit : trente jours sans date d’activité enregistrée dans la progression de confiance et le membre descend d’un niveau, avec l’historique enregistré et le motif. La pénalité échue est désactivée toutes les heures. Le séquestre du marketplace et la mise en avant payante expirent toutes les heures. La taille des vidéos se synchronise toutes les cinq minutes. La file du générateur de cours par IA est balayée toutes les vingt secondes — elle reprend une tâche bloquée, clôt un job inactif — et les fichiers source joints sont supprimés du CDN à quatre heures du matin.

Séparément, le push : chaque notification créée déclenche un envoi web push, en respectant l’interrupteur par type du membre et les clés VAPID de votre propre backend.

Il n’existe pas de rappel automatique de leçon arrêtée. Aucun des vingt-huit types de notification n’y correspond, et aucun planificateur ne cherche de progression bloquée. La liste de qui s’est arrêté existe ; l’e-mail de retour ne part pas seul.

Le rappel d’onboarding calcule qui est éligible — durée d’inactivité, mission incomplète, jours depuis l’entrée — et exclut déjà qui l’a déjà reçu. Mais il n’a ni expéditeur ni planificateur : l’envoi de test renvoie un aperçu, et la fonction qui enregistre le journal d’envoi n’a aucun appelant dans le dépôt. Aujourd’hui, c’est une règle de segmentation, pas une règle d’envoi.

Il n’existe pas d’envoi en masse pour un segment. Le modèle d’e-mail de communiqué existe dans le CRUD de modèles, avec variables documentées et versionnage, et aucun code ne l’envoie.

La liste de risque n’est pas cliquable. Voir le nom là et ouvrir la fiche de cet élève sont deux gestes distincts : l’élément de la liste n’a ni lien ni action, et l’admin recherche la personne à la main dans l’écran des membres.

La présence qui alimente le « depuis combien de temps disparu » est enregistrée en un seul point : la connexion et la déconnexion du socket du chat de la communauté. Post, commentaire et like entrent dans les calculs de D7, D30 et D90 ; dans la liste de risque, le seul signal est la présence.

Le digest n’atteint que qui a une préférence enregistrée, et cette ligne naît quand le membre ouvre l’écran de notifications pour la première fois — pas à l’inscription.