Le modèle de saturation des notifications push en 4 niveaux

Les notifications push sont le moyen le moins cher de perdre un utilisateur. La courbe de rétention à 1 push par jour paraît acceptable — les données sectorielles de Localytics et Urban Airship se situent autour de 88 % de rétention à trois mois. À 3 pushs par jour, la courbe baisse de 17 points de pourcentage. À 5 pushs par jour, elle baisse de 34. La forme est abrupte et irréversible : 46 % des utilisateurs se désinscrivent complètement des pushs quand une application leur en envoie 2 à 5 par semaine qu'ils ne souhaitent pas.

La réponse de Soulwise est un modèle de saturation à 4 niveaux. Il détecte la baisse du taux d'ouverture sur une fenêtre glissante de 14 jours et réduit progressivement le volume des notifications avant que l'utilisateur ne se désinscrive définitivement.

Cet article présente le design, les seuils et la logique de récupération.

Les quatre niveaux

La machine à états est simple. Chaque utilisateur se trouve toujours dans exactement un niveau à la fois.

• T0 - Sain. Programme complet. Rappel du rituel matinal, nudge contextuel de milieu de matinée, réflexion du soir, plus des prompts ancrés sur des événements.
• T1 - Rétrogradé. Le nudge contextuel de milieu de matinée est suspendu. Tout le reste continue.
• T2 - Ancrage seul. Seuls le rappel du rituel matinal et la rétrospective du dimanche subsistent. Toutes les pushs discrétionnaires sont suspendues.
• T3 - Hebdomadaire seul. Une seule push hebdomadaire survit. La cadence quotidienne est suspendue.

L'ordre compte. La milieu de matinée est la première à disparaître car elle porte le poids événementiel le plus faible : c'est un nudge contextuel, pas le rituel quotidien en lui-même. Le rappel matinal est conservé le plus longtemps car les pushs quotidiennes ancrées sur des événements produisent environ 2,85 fois la rétention des pushs génériques ; le supprimer revient à supprimer l'application.

Ce qui déclenche un changement de niveau

Une fenêtre glissante de 14 jours de données de taux d'ouverture par utilisateur. Chaque jour, le modèle analyse les 14 derniers jours et calcule le taux d'ouverture de l'utilisateur pour les pushs envoyées pendant cette fenêtre.

Le seuil de Soulwise est une baisse de 30 % du taux d'ouverture par rapport à la référence personnelle de l'utilisateur. Si un utilisateur ouvre habituellement 60 % des pushs et que la fenêtre glissante descend à 42 % ou moins, le modèle le descend d'un niveau. La baisse doit persister pendant au moins 3 jours pour éviter de réagir à une seule mauvaise semaine (vacances, maladie, semaine chargée au travail).

La promotion est symétrique. Si un utilisateur est en T2 et que son taux d'ouverture remonte au-dessus de sa référence moins le seuil de 30 % pendant 3 jours consécutifs, il passe en T1. La récupération vers T0 suit la même étape.

Pourquoi les pushs ancrées sur des événements résistent le plus longtemps

La donnée de Localytics / Urban Airship qui guide le design : les pushs quotidiennes ancrées sur des événements produisent environ 2,85 fois la rétention des pushs quotidiennes génériques. Un générique « revenez nous voir ! » à 9 h est oubliable. Un rappel matinal ancré à la phase de cycle du jour (« Début en douceur. Qu'avez-vous au programme aujourd'hui ? ») est ancré sur un événement — il apporte une information nouvelle.

T2 conserve le rappel matinal parce que le supprimer détruit le rituel quotidien entier. Tout le reste de l'application est construit autour de l'idée que l'utilisateur se connecte une fois le matin et une fois le soir. Sans le rappel, la boucle se brise.

L'UX de la bannière de saturation

Quand un utilisateur est rétrogradé, l'application affiche une petite bannière à l'intérieur de l'app la prochaine fois qu'il l'ouvre :

« Nous avons levé le pied pendant 7 jours — vous voulez que ça reprenne ? »

Cette phrase fait trois choses : elle reconnaît le changement, l'attribue au comportement de l'application (pas à l'échec de l'utilisateur), et offre de l'autonomie. L'utilisateur peut annuler la rétrogradation en un seul geste s'il souhaite retrouver ses notifications.

Cela compte parce qu'une rétrogradation silencieuse donne l'impression que l'application abandonne l'utilisateur. Une rétrogradation explicite donne l'impression que l'application tient à lui. La même action avec un cadrage différent.

Les anti-patterns que nous avons délibérément évités

Les spécifications produit sont explicites sur ce qui est interdit :

• Pas de push culpabilisante « ne brisez pas votre série ». Les séries jouent sur l'aversion à la perte. Le modèle de saturation rétrograde les utilisateurs ; il ne les culpabilise pas.
• Pas de push de réactivation « vous nous manquez » en fin de T3. Un utilisateur en T3 envoie déjà un message à l'application. Ajouter d'autres pushs est la mauvaise réponse.
• Pas de faux compteurs ni de rareté artificielle dans le contenu des pushs. « X personnes viennent de s'inscrire » est du théâtre de dark patterns, pas une notification.
• Pas de contenu menstruel ou astrologique dans les titres ou le corps des pushs. Les pushs passent par un lint CI qui rejette les builds contenant des patterns interdits ; le modèle de saturation ne le contourne jamais.

À quoi ressemblent les données dans le système

Le modèle stocke l'état par utilisateur avec trois champs :

tier: 'T0' | 'T1' | 'T2' | 'T3'
rolling_open_rate_14d: 0.0 à 1.0
baseline_open_rate: 0.0 à 1.0 (calculé à partir des 30 premiers jours)
last_tier_change_at: timestamp

C'est l'intégralité de l'état de saturation. Pas d'historique de navigation, pas de score d'engagement au-delà du taux d'ouverture, pas de modèle de machine learning entraîné sur l'utilisateur. La simplicité est intentionnelle : les règles sont auditables, les seuils sont documentés, les conséquences UX sont prévisibles.

Ce que ce système n'est pas

Une précision sur le périmètre.

Le modèle de saturation est par utilisateur, pas par cohorte. Nous n'analysons pas les « utilisateurs comme vous » et ne menons pas d'expériences qui rétrogradent des utilisateurs pour étudier la rétention. Le modèle sert l'individu.

Il ne remplace pas non plus les paramètres contrôlés par l'utilisateur. Les heures silencieuses, la mise en sourdine par catégorie et la désactivation explicite de toutes les pushs fonctionnent indépendamment du modèle de saturation. Les deux systèmes se composent ; le choix explicite de l'utilisateur l'emporte toujours sur l'inférence du modèle.

Pourquoi c'est important pour le reste de l'application

Les notifications push sont la façon dont un rituel quotidien reste quotidien. Une application de check-in qui perd ses droits push perd sa principale boucle de rétention. Le modèle à 4 niveaux existe pour que l'application n'abuse pas de ce privilège et ne le perde pas lentement — en étant juste légèrement agaçante pendant trop longtemps.

Le contexte plus large du rituel quotidien se trouve dans le hub Soulwise. Le modèle de saturation est l'une des raisons pour lesquelles le rituel reste réciproque plutôt qu'exigeant.

La version courte : le bon nombre de pushs est le plus grand nombre qui ne provoque pas de désinscription. Le modèle de saturation est la façon dont l'application trouve ce nombre, par utilisateur, tous les 14 jours.