Repository navigation
Description
Objectif
Chaque jour, détecter les joueurs en train de décrocher mais encore récupérables, et leur envoyer une notification personnalisée qui leur donne une raison concrète de revenir.
Critères « perdu mais récupérable » (stricts, anti-spam)
Cible : un joueur régulier qui casse son habitude pour la première fois depuis longtemps. Les joueurs qui alternent souvent pauses et reprises sont exclus : ils reviennent d'eux-mêmes.
Un joueur est éligible le jour où toutes ces conditions sont vraies :
| # | Critère | Valeur |
|---|---|---|
| 1 | Niveau | ≥ 4 (a fini le tutoriel) |
| 2 | Joueur régulier | ≥ 10 jours joués sur les 30 jours précédant sa dernière commande |
| 3 | Habitude récente | ≥ 4 jours joués sur les 7 jours précédant sa dernière commande |
| 4 | Pause inhabituelle | aucune absence de plus de 5 jours sur les 180 jours précédant sa dernière commande |
| 5 | Absence actuelle | dernière commande il y a exactement 5 jours (jour J+5 uniquement, aucun rattrapage) |
| 6 | Une seule fois | aucune notification de ce type déjà reçue dans les 180 derniers jours |
| 7 | Autres | non banni, type de notification activé |
Garde-fous supplémentaires :
- Pas d'envoi rétroactif au lancement : la condition 5 ne vise que le jour J+5 exact, donc les joueurs déjà partis ne reçoivent rien.
- Plafond global : au maximum 20 envois par exécution quotidienne (sécurité en cas de bug de requête ; le volume attendu est d'environ 1 par jour).
- Si le DM échoue (DMs fermés), ne pas réessayer et marquer quand même la notification comme envoyée.
Volume et intérêt (calculé sur les 12 derniers mois)
| Critères | Envois / an | Joueurs | Envois / jour | Perdus sans relance |
|---|---|---|---|---|
| ≥ 5 j/mois (version initiale) | 1 717 | 681 (2,5 envois chacun) | 4,7 | 32 % |
| ≥ 10 j/mois | 1 014 | 478 | 2,8 | 28 % |
| + ≥ 4 j sur les 7 derniers | 545 | 390 | 1,5 | 28 % |
| + aucune pause > 5 j sur 180 j (retenu) | 267 | 266 | 0,7 | 37 % (31 % ne reviennent jamais) |
| pour comparaison : 1 pause sur 180 j | 85 | 83 | — | 22 % (15 % ne reviennent jamais) |
| pour comparaison : 2 pauses ou plus sur 180 j | 193 | 121 | — | 19 % (8 % ne reviennent jamais) |
→ Avec ces critères, on envoie environ 1 notification tous les 1 à 2 jours, en pratique une seule fois par joueur, et uniquement aux joueurs les plus à risque.
Pourquoi J+5 : avant, la plupart reviennent d'eux-mêmes. Après J+10, les retours tiennent mal (part des joueurs qui rejouent au moins 5 jours dans les 30 jours suivant le retour : 73 % après 3-4 j d'absence, 61 % après 5-7 j, 49 % après 8-10 j, 37 % après 11-21 j).
Contenu de la notification
Une seule notification, dont la phrase d'accroche est choisie selon l'état du joueur, par ordre de priorité (la première qui s'applique) :
- Objectif de campagne en cours (lien avec Afficher l'objectif de campagne en cours (avec la commande à utiliser) dans /report #5036) : « Votre prochain objectif vous attend : {mission} ({command}). »
- Voyage terminé : « Vous êtes arrivé à {destination} depuis plusieurs jours, de nouvelles aventures vous y attendent. »
- Familier : « {familier} attend votre retour pour repartir en expédition. »
- Guilde : « Votre guilde {guilde} a continué de progresser en votre absence. »
- Par défaut : « Vos jetons sont rechargés et de nouvelles rencontres vous attendent sur les routes. »
Règles de rédaction : uniquement en FR (les autres langues via Crowdin), pas de discours direct, emojis via {emote:…}, commande cliquable via {command:…}.
Implémentation proposée
- Core : nouvelle tâche dans
CrowniclesDailyqui :- sélectionne dans la base de logs (
players_commands) les joueurs dont la dernière commande date d'exactement 5 jours et qui vérifient les critères 2, 3 et 4 ; puis filtre par niveau ≥ 4 et non banni dans la base de jeu ; - exclut les joueurs déjà relancés dans les 180 derniers jours (nouvelle colonne
lastComebackNotificationAtsurplayers, ou petite table dédiée, via migration), puis applique le plafond global ; - détermine l'accroche (
hook) et envoie unComebackNotificationPacketviaPacketUtils.sendNotifications.
Ne pas s'appuyer sur
players.lastActivityAt: elle ne reflète pas la dernière commande, et la base de jeu contient des valeurs aberrantes. - sélectionne dans la base de logs (
- Lib :
ComebackNotificationPacket(keycloakId,hook: union typée dérivée d'un objetas const, plus les paramètres de l'accroche : id de mission, id de lieu, nom du familier ou de la guilde). - Discord : nouveau
NotificationsTypes.COMEBACK(activé par défaut, envoi en DM) + colonnescomebackEnabled/comebackSendType/comebackChannelIddansNotificationsConfiguration(migration), visible et désactivable dans/notifications; traitement dansNotificationsHandler.
Mesure de l'effet
- Groupe témoin : 20 % des joueurs éligibles, tirés au hasard, ne reçoivent pas la notification. Logguer chaque envoi, en distinguant envoyé et témoin. Sans ce groupe, l'effet est impossible à mesurer, puisque 63 % des éligibles reviennent déjà d'eux-mêmes sous 35 jours.
- Indicateurs, envoyés contre témoin :
- % de retours sous 7 j et sous 30 j (référence : ~63 % sous 35 j) ;
- % qui rejouent au moins 5 jours dans les 30 jours suivant le retour (référence : 61 %) ;
- taux de désactivation de la notification.
Hors périmètre
- Cadeau / bonus de retour (à envisager dans un second temps si l'effet est faible).
- Relances multiples, joueurs absents depuis plus de 5 jours au lancement, joueurs occasionnels ou habitués des pauses.
- Joueurs n'ayant pas atteint le niveau 4 (cf. tutoriel, Refonte du système de tutoriel / onboarding #4125).
Activity
[-]Notification de relance quotidienne pour les joueurs en train de décrocher mais encore récupérables (absents depuis 5 j)[/-][+]Notification de relance pour les joueurs réguliers qui décrochent pour la 1re fois (J+5, environ 1 envoi par jour)[/+]