Моделът за умора от push известия на 4 нива

Push известията са най-евтиният начин да изгубиш потребител. Кривата на задържане при 1 push на ден изглежда добре - данните от индустрията на Localytics и Urban Airship се групират около 88 процента тримесечно задържане. При 3 push известия на ден кривата спада с 17 процентни пункта. При 5 push известия на ден тя спада с 34. Формата е стръмна и необратима: 46 процента от потребителите се отказват напълно от push, когато приложението им изпраща от 2 до 5 нежелани push известия седмично.

Отговорът на Soulwise е модел за умора с 4 нива. Той засича спада в честотата на отваряне в подвижен прозорец от 14 дни и постепенно намалява обема на известията, преди потребителят да се откаже окончателно.

Тази публикация преминава през дизайна, праговете и логиката на възстановяване.

Четирите нива

Машината на състоянията е малка. Всеки потребител е точно в едно ниво в даден момент.

• T0 – Здраво. Пълен график. Подкана за сутрешен ритуал, контекстуален тласък посред сутринта, вечерна равносметка, плюс подкани, обвързани със събития.
• T1 – Понижено. Контекстуалният тласък посред сутринта е поставен на пауза. Всичко останало продължава.
• T2 – Само котви. Остават единствено подканата за сутрешен ритуал и неделната ретроспекция. Всички по избор известия са поставени на пауза.
• T3 – Само седмично. Оцелява едно-единствено седмично известие. Дневният ритъм е спрян.

Редът има значение. Тласъкът посред сутринта си отива пръв, защото носи най-малка тежест на събитие: той е контекстуален тласък, а не част от самия дневен ритуал. Сутрешната подкана се запазва най-дълго, защото дневните известия, обвързани със събития, водят до около 2.85x по-висока задръжка от общите; премахнеш ли я, убиваш приложението.

Какво задейства промяна на ниво

Плъзгащ се прозорец от 14 дни с данни за честотата на отваряне за всеки потребител. Всеки ден моделът разглежда последните 14 дни и изчислява честотата, с която потребителят отваря push известията, изпратени през този период.

Прагът на Soulwise е спад от 30 процента в честотата на отваряне спрямо личната базова стойност на потребителя. Ако даден потребител обикновено отваря 60 процента от push известията и в плъзгащия се прозорец стойността падне до 42 процента или по-ниско, моделът го премества с едно ниво надолу. Спадът трябва да се задържи поне 3 дни, за да не се реагира на една-единствена лоша седмица (отпуска, болест, натоварена седмица в работата).

Повишаването е симетрично. Ако потребител е на ниво T2 и честотата му на отваряне се изкачи отново над базовата стойност минус прага от 30 процента в продължение на 3 последователни дни, той се премества нагоре на T1. Връщането до T0 става по същия начин.

Защо пушовете, обвързани със събитие, оцеляват най-дълго

Данните на Localytics / Urban Airship, които стоят зад този дизайн: ежедневните пушове, обвързани със събитие, носят около 2.85 пъти по-добро задържане в сравнение с общите ежедневни пушове. Едно общо "наглеждай ни!" в 9 часа сутринта се забравя. Сутрешен подкан, обвързан с реалната фаза на цикъла днес ("Спокойно начало. С какво си се захванал днес?"), е обвързан със събитие — носи нова информация.

T2 запазва сутрешния подкан, защото премахването му премахва целия ежедневен ритуал. Всичко останало в приложението е изградено около това потребителят да влиза веднъж сутрин и веднъж вечер. Без подкана веригата се къса.

UX на банера за умора

Когато потребител бъде понижен, при следващото отваряне приложението показва малък банер вътре в него:

„Намалихме темпото за 7 дни — да го върнем ли?"

Това изречение прави три неща: признава промяната, отдава я на поведението на приложението (а не на провал на потребителя) и дава свобода на избор. Потребителят може да отмени понижението само с едно докосване, ако иска да върне известията.

Това има значение, защото мълчаливото понижение усеща се като приложение, което изоставя потребителя. Гласното — като приложение, което го е грижа. Едно и също действие, поднесено по различен начин.

Анти-модели, които съзнателно не изградихме

Спецификацията на продукта е изрична за това какво е забранено:

• Без чувство за вина от типа „не прекъсвай серията си“. Сериите са засрамване чрез страх от загуба. Моделът за умора понижава потребителите; не ги засрамва.
• Без реактивиращо подканване „липсваш ни“ в края на T3. Потребител при T3 вече казва нещо на приложението. Да добавяш още известия е грешен отговор.
• Без фалшиви броячи или изкуствен недостиг в текста на известията. „X души току-що се регистрираха“ е театър на тъмни модели, не известие.
• Без съдържание за менструация или астрология в заглавията или текста на известията. Известията минават през CI lint, който отхвърля компилации със забранени модели; моделът за умора никога не го заобикаля.

Как всъщност изглеждат данните в системата

Моделът съхранява състоянието за всеки потребител с три полета:

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

Това е цялото състояние на умората. Без история на сърфирането, без оценка на ангажираността отвъд процента на отваряне, без модел за машинно обучение, трениран върху потребителя. Простотата е целта: правилата подлежат на одит, праговете са документирани, а последиците за UX са предвидими.

Какво не е това

Бележка за обхвата.

Моделът на умората е за всеки потребител поотделно, а не за цели групи. Не гледаме „потребители като теб“ и не правим експерименти, които ограничават показването на едни потребители, за да научим нещо за задържането. Моделът служи на отделния човек.

Той също така не замества настройките, които управляваш сам. Тихите часове, заглушаването по категории и пълното изключване на всички известия работят независимо от модела на умората. Двете (2) системи се допълват; твоят изричен избор винаги има превес над преценката на модела.

Защо това е важно за останалата част от приложението

Push известията са начинът, по който един ежедневен ритуал си остава ежедневен. Приложение за check-in, което изгуби push привилегиите си, губи основния си цикъл на задържане. Моделът с 4 нива съществува, за да не злоупотребява приложението с тази привилегия и да не я изгуби по бавния начин — като е съвсем леко досадно за съвсем достатъчно дълго.

По-пълният контекст около ежедневния ритуал живее в хъба Soulwise. Моделът на умора е една от причините ритуалът да остане взаимен, вместо да изисква.

По-кратката версия: правилният брой известия е най-големият брой, който не води до отписване. Моделът на умора е начинът, по който приложението намира това число за всеки потребител на всеки 14 дни.