Чотирирівнева модель втоми від push-сповіщень

Чотирирівнева модель втоми від push-сповіщень

Push-сповіщення — найдешевший спосіб втратити користувача. Крива утримання при одній push на день виглядає нормально — галузеві дані Localytics і Urban Airship дають близько 88% тримісячного утримання. При трьох push на день крива падає на 17 відсоткових пунктів. При п'яти — на 34. Форма кривої крута й незворотна: 46% користувачів повністю вимикають push, коли застосунок надсилає їм від 2 до 5 сповіщень на тиждень, яких вони не хочуть.

Відповідь Soulwise — чотирирівнева модель втоми. Вона відстежує зниження відкриваності в ковзному 14-денному вікні й поступово зменшує обсяг сповіщень до того, як користувач вимкне їх назавжди.

У цій статті описані дизайн моделі, порогові значення та логіка відновлення.

Чотири рівні

Автомат станів простий. Кожен користувач у будь-який момент перебуває рівно на одному рівні.

• T0 - Здоровий. Повний розклад. Нагадування про ранковий ритуал, контекстний нодж у середині ранку, вечірня рефлексія, а також push, прив'язані до подій.
• T1 - Знижений. Контекстний нодж середини ранку призупинено. Все інше продовжується.
• T2 - Тільки якір. Залишаються лише нагадування про ранковий ритуал і недільний ретроспектив. Всі дискреційні push призупинено.
• T3 - Тільки щотижневий. Виживає єдина щотижнева push. Щоденний ритм призупинено.

Порядок важливий. Першою прибирається середина ранку, бо вона має найменшу вагу подій: це контекстний нодж, а не частина самого щоденного ритуалу. Ранкове нагадування зберігається найдовше, бо щоденні push, прив'язані до подій, забезпечують приблизно в 2,85 рази вище утримання, ніж звичайні; прибрати його — означає прибрати головне в застосунку.

Що запускає зміну рівня

Ковзне 14-денне вікно даних про відкриваність для кожного користувача. Щодня модель дивиться на останні 14 днів і обчислює відкриваність push, надісланих у цьому вікні.

Поріг Soulwise — зниження відкриваності на 30% від особистого базового рівня користувача. Якщо користувач зазвичай відкриває 60% push, а ковзне вікно падає до 42% або нижче, модель знижує його на один рівень. Зниження повинно тривати не менше 3 днів, щоб не реагувати на єдиний невдалий тиждень (відпустка, хвороба, напружений робочий тиждень).

Підвищення симетричне. Якщо користувач перебуває на T2 і його відкриваність протягом 3 послідовних днів перевищує його базовий рівень мінус поріг 30%, він переходить на T1. Відновлення до T0 слідує тому ж кроку.

Чому push, прив'язані до подій, тримаються найдовше

Дані Localytics / Urban Airship, що лежать в основі дизайну: щоденні push, прив'язані до подій, забезпечують приблизно в 2,85 рази вище утримання, ніж звичайні щоденні push. Звичайне «зазирни до нас!» о 9-й ранку легко забудеться. Ранкове нагадування, прив'язане до актуальної фази циклу («М'який старт. Що у тебе сьогодні в планах?»), прив'язане до події — воно несе нову інформацію.

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

UX банера втоми

Коли користувач знижується в рівні, при наступному відкритті застосунку в ньому з'являється невеликий банер:

«Ми знизили активність на 7 днів — хочеш повернути сповіщення?»

Ця фраза робить три речі: визнає зміну, пов'язує її з поведінкою застосунку (а не з помилкою користувача) і пропонує вибір. Користувач може скасувати зниження одним торканням, якщо хоче повернути сповіщення.

Це важливо, бо тихе зниження відчувається як покинутість з боку застосунку. Явне — як турбота. Одна й та сама дія з різною подачею.

Антипатерни, які ми свідомо не реалізували

Продуктова специфікація прямо вказує, що заборонено:

• Жодних push-маніпуляцій «не переривай серію». Серії — це сором через уникнення втрат. Модель втоми знижує користувачів у рівні; вона не маніпулює ними.
• Жодних реактиваційних push «ми сумуємо» в кінці T3. Користувач на T3 вже говорить застосунку щось важливе. Додавати більше push — неправильна відповідь.
• Жодних підроблених лічильників або штучного дефіциту в текстах push. «X осіб щойно зареєструвалися» — це театр темних патернів, а не сповіщення.
• Жодного контенту про менструальний цикл або астрологію в заголовках чи текстах push. Push проходять через CI-лінтер, що відхиляє збірки із забороненими патернами; модель втоми ніколи його не обходить.

Як виглядають дані всередині системи

Модель зберігає стан кожного користувача в трьох полях:

tier: 'T0' | 'T1' | 'T2' | 'T3'
rolling_open_rate_14d: від 0.0 до 1.0
baseline_open_rate: від 0.0 до 1.0 (обчислюється за перші 30 днів)
last_tier_change_at: timestamp

Це весь стан втоми. Жодної історії перегляду, жодних оцінок залученості, крім відкриваності, жодних ML-моделей, навчених на даних користувача. Простота навмисна: правила піддаються аудиту, порогові значення задокументовані, наслідки для UX передбачувані.

Чим ця система не є

Уточнення сфери застосування.

Модель втоми — на рівні користувача, а не когорти. Ми не аналізуємо «користувачів, схожих на вас» і не проводимо експерименти, що знижують користувачів заради вивчення утримання. Модель служить конкретній людині.

Вона також не замінює налаштування, керовані користувачем. Години тиші, вимкнення звуку за категоріями та явне вимкнення всіх push працюють незалежно від моделі втоми. Обидві системи сумісні; явний вибір користувача завжди переважає над висновком моделі.

Чому це важливо для решти застосунку

Push-сповіщення — це те, що утримує щоденний ритуал щоденним. Застосунок для чекінів, що втратив права на push, втрачає свій головний механізм утримання. Чотирирівнева модель існує для того, щоб застосунок не зловживав цією привілегією і не втрачав її повільним шляхом — будучи лише злегка дратівливим достатньо довго.

Ширший контекст щоденного ритуалу знаходиться в хабі Soulwise. Модель втоми — одна з причин, з яких ритуал залишається взаємним, а не вимогливим.

Коротка версія: правильна кількість push — це найбільша кількість, яка не призводить до відключення. Модель втоми — це спосіб, яким застосунок знаходить це число для кожного користувача кожні 14 днів.