El model de fatiga de notificacions push de 4 nivells

Les notificacions push són la manera més barata de perdre un usuari. La corba de retenció amb 1 push al dia té bon aspecte: les dades del sector de Localytics i Urban Airship s'agrupen al voltant del 88 per cent de retenció als tres mesos. Amb 3 pushes al dia, la corba cau 17 punts percentuals. Amb 5 pushes al dia, cau 34. La forma és pronunciada i irreversible: el 46 per cent dels usuaris desactiven completament les notificacions push quan una aplicació els n'envia de 2 a 5 a la setmana que no volen.

La resposta de Soulwise és un model de fatiga de 4 nivells. Detecta la davallada de la taxa d'obertura en una finestra mòbil de 14 dies i redueix progressivament el volum de notificacions abans que l'usuari les desactivi per sempre.

Aquest article repassa el disseny, els llindars i la lògica de recuperació.

Els quatre nivells

La màquina d'estats és senzilla. Cada usuari es troba exactament en un nivell alhora.

• T0 - Sa. Calendari complet. Recordatori del ritual matinal, indicació contextual a mig matí, reflexió vespertina i, a més, recordatoris ancorats a esdeveniments.
• T1 - Degradat. La indicació contextual de mig matí queda en pausa. Tota la resta continua.
• T2 - Només àncores. Només queden el recordatori del ritual matinal i la retrospectiva del diumenge. Totes les notificacions discrecionals queden en pausa.
• T3 - Només setmanal. Sobreviu una única notificació setmanal. La cadència diària queda suspesa.

L'ordre importa. El de mig matí és el primer a desaparèixer perquè és el que té menys pes d'esdeveniment: és una indicació contextual, no pas part del ritual diari en si. El recordatori matinal es preserva més temps perquè les notificacions diàries ancorades a esdeveniments generen unes 2.85 vegades la retenció de les genèriques; eliminar-lo equival a matar l'aplicació.

Què activa un canvi de nivell

Una finestra mòbil de 14 dies de dades de la taxa d'obertura per usuari. Cada dia el model mira els últims 14 dies i calcula la taxa d'obertura de l'usuari per a les notificacions push enviades durant aquesta finestra.

El llindar de Soulwise és un decaïment del 30 per cent en la taxa d'obertura respecte de la línia de base personal de l'usuari. Si un usuari normalment obre el 60 per cent dels push i la finestra mòbil cau al 42 per cent o menys, el model el baixa un nivell. La caiguda ha de persistir com a mínim 3 dies per evitar reaccionar a una sola mala setmana (unes vacances, una malaltia, una setmana carregada de feina).

La promoció és simètrica. Si un usuari és al T2 i la seva taxa d'obertura torna a pujar per sobre de la seva línia de base menys el llindar del 30 per cent durant 3 dies consecutius, puja al T1. La recuperació fins al T0 segueix el mateix pas.

Per què els avisos ancorats a esdeveniments duren més

La dada de Localytics / Urban Airship que guia el disseny: els avisos diaris ancorats a esdeveniments generen aproximadament 2.85 vegades més retenció que els avisos diaris genèrics. Un genèric "vine a fer una ullada!" a les 9 del matí és fàcil d'oblidar. Un avís matinal ancorat a la fase real del cicle d'avui ("Comença suau. Què tens entre mans avui?") va lligat a un esdeveniment: aporta informació nova.

T2 manté l'avís matinal perquè treure'l elimina tot el ritual diari. Tota la resta de l'aplicació gira al voltant que l'usuari hi entri un cop al matí i un cop al vespre. Sense l'avís, el bucle es trenca.

La UX del bàner de fatiga

Quan un usuari és degradat, l'aplicació mostra un petit bàner dins de l'app el següent cop que l'obre:

"Hem afluixat durant 7 dies, vols pujar-ho de nou?"

Aquesta frase fa tres coses: reconeix el canvi, l'atribueix al comportament de l'app (no a un fracàs de l'usuari) i ofereix capacitat de decisió. L'usuari pot anul·lar la degradació amb un sol toc si vol recuperar les notificacions.

Això importa perquè una degradació silenciosa fa la sensació que l'app abandona l'usuari. Una de visible fa la sensació que l'app s'hi amoïna. La mateixa acció amb un enfocament diferent.

Antipatrons que vam decidir no construir

L'especificació del producte és explícita sobre què està prohibit:

• Cap notificació de culpabilització del tipus «no trenquis la teva ratxa». Les ratxes són una vergonya basada en l'aversió a la pèrdua. El model de fatiga degrada els usuaris; no els avergonyeix.
• Cap notificació de reactivació del tipus «t'enyorem» al final de T3. Un usuari a T3 ja li està dient alguna cosa a l'aplicació. Afegir-hi més notificacions és la resposta equivocada.
• Cap comptador fals ni escassetat en el cos de les notificacions. «X persones s'acaben de registrar» és teatre de patró fosc, no una notificació.
• Cap contingut menstrual ni astrològic en els títols o el cos de les notificacions. Les notificacions passen per un lint de CI que rebutja les builds que contenen patrons prohibits; el model de fatiga mai no se'l salta.

Quina pinta tenen realment les dades dins del sistema

El model desa l'estat de cada usuari amb tres camps:

tier: 'T0' | 'T1' | 'T2' | 'T3'
rolling_open_rate_14d: 0.0 to 1.0
baseline_open_rate: 0.0 to 1.0 (computed from first 30 days)
last_tier_change_at: timestamp

Això és tot l'estat de fatiga. Sense historial de navegació, sense puntuació d'interacció més enllà de la taxa d'obertura, sense cap model d'aprenentatge automàtic entrenat amb l'usuari. La simplicitat és l'objectiu: les regles són auditables, els llindars estan documentats i les conseqüències per a l'experiència d'usuari són previsibles.

Què no és això

Una nota sobre l'abast.

El model de fatiga és per usuari, no per cohort. No mirem els "usuaris com tu" ni fem experiments que perjudiquin certs usuaris per aprendre sobre la retenció. El model serveix l'individu.

Tampoc no substitueix la configuració que controla l'usuari. Les hores de silenci, el silenciament per categoria i la desactivació explícita de totes les notificacions funcionen amb independència del model de fatiga. Els dos sistemes es complementen; l'elecció explícita de l'usuari sempre preval per damunt de la inferència del model.

Per què això importa per a la resta de l'aplicació

Les notificacions push són el que fa que un ritual diari segueixi sent diari. Una aplicació de check-in que perd els privilegis de push perd el seu principal bucle de retenció. El model de 4 nivells existeix perquè l'aplicació no abusi d'aquest privilegi i el perdi de la manera lenta: sent una mica massa molesta durant prou temps.

El context complet del ritual diari el trobaràs al centre de Soulwise. El model de fatiga és una de les raons per què el ritual segueix sent recíproc en lloc de exigent.

La versió curta: el nombre adequat de notificacions push és el nombre més gran que no provoca que et donis de baixa. El model de fatiga és la manera com l'aplicació troba aquest nombre, per a cada usuari, cada 14 dies.