Modellen for push-varslingstretthet i 4 nivåer

Push-varsler er den billigste måten å miste en bruker på. Retensjonskurven ved 1 push per dag ser fin ut – bransjedata fra Localytics og Urban Airship samler seg rundt 88 prosent retensjon over tre måneder. Ved 3 push per dag faller kurven med 17 prosentpoeng. Ved 5 push per dag faller den med 34. Formen er bratt og uopprettelig: 46 prosent av brukerne melder seg helt av push når en app sender dem 2 til 5 push i uken de ikke vil ha.

Soulwise svarer med en trettelsesmodell i 4 nivåer. Den oppdager fall i åpningsrate over et rullerende vindu på 14 dager og reduserer gradvis varslingsvolumet før brukeren melder seg av for godt.

Dette innlegget går gjennom designet, tersklene og gjenopprettingslogikken.

De fire nivåene

Tilstandsmaskinen er liten. Hver bruker befinner seg på nøyaktig ett nivå om gangen.

• T0 – Sunn. Full plan. Et morgenrituale, en kontekstuell dytt midt på formiddagen, en kveldsrefleksjon, pluss hendelsesforankrede varsler.
• T1 – Nedgradert. Den kontekstuelle dytten midt på formiddagen settes på pause. Alt annet fortsetter.
• T2 – Bare forankring. Kun morgenritualet og søndagsoppsummeringen er igjen. Alle valgfrie push-varsler settes på pause.
• T3 – Bare ukentlig. Ett enkelt ukentlig push-varsel overlever. Den daglige rytmen settes på vent.

Rekkefølgen betyr noe. Formiddagsvarselet ryker først fordi det bærer den laveste hendelsesvekten: det er en kontekstuell dytt, ikke en del av selve det daglige ritualet. Morgenvarselet bevares lengst fordi hendelsesforankrede daglige push-varsler gir omtrent 2.85x så høy oppslutning som generiske; å fjerne det dreper appen.

Hva som utløser en nivåendring

Et rullerende vindu på 14 dager med data om åpningsrate per bruker. Hver dag ser modellen på de siste 14 dagene og beregner brukerens åpningsrate for push-varsler sendt i det vinduet.

Soulwises terskel er 30 prosent fall i åpningsrate fra brukerens personlige grunnlinje. Hvis en bruker vanligvis åpner 60 prosent av push-varslene og det rullerende vinduet faller til 42 prosent eller lavere, flytter modellen brukeren ned et nivå. Fallet må vedvare i minst 3 dager for å unngå å reagere på én enkelt dårlig uke (en ferie, sykdom, en travel uke på jobben).

Opprykk er symmetrisk. Hvis en bruker ligger på T2 og åpningsraten klatrer tilbake over grunnlinjen minus terskelen på 30 prosent i 3 påfølgende dager, flyttes brukeren opp til T1. Tilbakegang til T0 skjer på samme måte.

Hvorfor hendelsesforankrede push-varsler overlever lengst

Datapunktet fra Localytics / Urban Airship som ligger bak designet: hendelsesforankrede daglige push-varsler gir omtrent 2.85x så høy retensjon som generiske daglige varsler. Et generisk «sjekk inn med oss!» klokka 9 er lett å glemme. En morgenmelding forankret i dagens faktiske syklusfase («Myk start. Hva står på agendaen i dag?») er hendelsesforankret – den har ny informasjon.

T2 beholder morgenmeldingen, fordi å fjerne den fjerner hele det daglige ritualet. Alt annet i appen er bygget rundt at brukeren logger seg på én gang om morgenen og én gang om kvelden. Uten meldingen brytes løkka.

UX-banneret ved tretthet

Når en bruker nedgraderes, viser appen et lite banner neste gang den åpnes:

"Vi har trappet ned i 7 dager – skru opp igjen?"

Den setningen gjør tre ting: den anerkjenner endringen, tilskriver den appens oppførsel (ikke brukerens feil) og gir brukeren handlingsrom. Brukeren kan oppheve nedgraderingen med ett enkelt trykk hvis hen vil ha varslene tilbake.

Dette betyr noe fordi en stille nedgradering føles som at appen svikter brukeren. En tydelig nedgradering føles som at appen bryr seg. Samme handling, men med ulik innramming.

Antimønstre vi bevisst ikke bygde

Produktspesifikasjonen er tydelig på hva som er forbudt:

• Ingen skyldbasert «ikke bryt streaken»-varsling. Streaks er skambelegging gjennom tapsaversjon. Slitenhetsmodellen nedprioriterer brukere; den skammer dem ikke.
• Ingen «vi savner deg»-reaktivering på slutten av T3. En bruker ved T3 forteller allerede appen noe. Å sende flere varsler er feil respons.
• Ingen falske tellere eller knapphet i varseltekster. «X personer registrerte seg nettopp» er teater fra mørke mønstre, ikke et varsel.
• Ingen menstruasjons- eller astrologiinnhold i varseltitler eller -tekster. Varsler går gjennom en CI-lint som avviser bygg med forbudte mønstre; slitenhetsmodellen omgår den aldri.

Hvordan dataene inne i systemet faktisk ser ut

Modellen lagrer tilstanden per bruker med tre felter:

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

Det er hele utmattelsestilstanden. Ingen nettleserhistorikk, ingen engasjementsscore utover åpningsrate, ingen maskinlæringsmodell trent på brukeren. Enkelheten er hele poenget: reglene kan revideres, terskelverdiene er dokumentert, og konsekvensene for brukeropplevelsen er forutsigbare.

Hva dette ikke er

En merknad om omfang.

Slitenhetsmodellen er per bruker, ikke per gruppe. Vi ser ikke på «brukere som deg» eller kjører eksperimenter som nedprioriterer brukere for å lære om hvor lenge de blir værende. Modellen tjener den enkelte.

Den erstatter heller ikke innstillinger du selv styrer. Stille timer, demping per kategori og uttrykkelig avslåing av alle varsler fungerer alle uavhengig av slitenhetsmodellen. De to systemene utfyller hverandre; brukerens uttrykkelige valg vinner alltid over modellens slutning.

Hvorfor dette betyr noe for resten av appen

Push-varsler er det som holder et daglig ritual daglig. En innsjekkingsapp som mister push-tilgangen, mister sin viktigste sløyfe for å holde på brukerne. 4-nivåmodellen finnes for at appen ikke skal misbruke privilegiet og miste det på den langsomme måten – ved å være litt for irriterende litt for lenge.

Den fyldigere konteksten rundt det daglige ritualet finner du på Soulwise-knutepunktet. Tretthetsmodellen er én del av hvorfor ritualet forblir gjensidig i stedet for krevende.

Den korte versjonen: riktig antall push-varsler er det høyeste antallet som ikke får brukeren til å melde seg av. Tretthetsmodellen er måten appen finner det tallet på, for hver bruker, hver 14 dag.