Реалізація бота для трекінгу звичок у мобільному застосунку

Трекер звичок: де ламається утримання на третій день

Трекер звичок майже ніколи не втрачає користувача на першій сесії — він втрачає його на третій. Людина встановлює застосунок, увечері відмічає «випив воду» і «прочитав розділ», другого дня повторює, а третього просто не відкриває. Ззовні це виглядає як «інтерес зник», всередині — як три конкретні місця, де механіка ламається.

Перше місце — нагадування. Сповіщення, поставлене локально на конкретний час, приходить невчасно: часовий пояс змінився під час перельоту, пристрій добу лежав у режимі економії, система відклала чергу фонових завдань.

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

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

Користувач бачить чистий календар замість тридцяти днів поспіль і не починає заново — втрачати нічого.

Третій фактор — вартість повернення. Якщо після відвалу на старті людині нічого відновити, повертатися нікуди: ні прогресу, ні статистики, ні нагадування про себе.

Утримання аудиторії тут тримається не на геймифікації, а на синхронізації стану й передбачуваних сповіщеннях — розбираємо, як це закривається в архітектурі застосунку.

Що дає опрацьований трекер: ефект у вимірюваних числах

Трекер звичок оцінюють не за кількістю встановлень, а за поверненням на другому й четвертому тижні — це дві різні криві відтоку. На другому тижні йдуть ті, кому не підійшов перший сценарій, на четвертому — ті, у кого застосунок розійшовся з реальним розкладом.

Якщо нагадування будуються на локальному планувальнику Android і системних механізмах платформи, а не на серверній розсилці, доставка не залежить від мережі та режиму енергозбереження: стабільність нагадувань стає відтворюваним параметром, а не лотереєю.

Частка тих, хто дійшов до відмітки, чутлива до кожного зайвого кроку: нагадування, відкриття, вибір звички, підтвердження.

Прибираємо обов’язковий вхід на старті, відкриваємо екран відмітки прямо зі сповіщення, а сам запис робимо ідемпотентним — повторний тап не створює дубль і не скидає серію. У телеметрії це видно як зростання частки активних відміток за тієї самої кількості відкриттів.

Навантаження на підтримку падає не від «покращення інтерфейсу», а від вирізання цілого класу відмов: зниклі відмітки після офлайн-періоду, задвоєні серії після переінсталяції, розбіжність дат під час зміни часового поясу.

Раніше такий випадок приходив скаргою без відтворення; тепер він або не виникає, або логується з ідентифікатором операції — розбір займає хвилини замість листування.

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

Варіанти трекера звичок: нативний модуль, гібрид, веб-шар

Усі три варіанти розв’язують одну задачу — вчасно показати нагадування й не втратити відмітку.

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

На практиці вибір упирається у дві речі: як часто доведеться доопрацьовувати логіку нагадувань і наскільки сильно застосунок зав’язаний на зовнішні сервіси. Нижче — порівняння за цими осями.

Обмеження підходу проявляються не на старті, а на зростанні: чим більше звичок і нагадувань у користувача, тим помітніша різниця в точності спрацювання та в обсязі робіт, якщо логіку потім доведеться переносити.

Тому ми спочатку фіксуємо, де проходить межа між ядром продукту й допоміжними функціями, і лише після цього обираємо варіант.

Етапи впровадження: від аудиту сценаріїв до передачі команді

Роботу над трекером звичок починаємо не з коду, а з розбору того, як людина вже поводиться в застосунку: які звички заводить, де кидає, які відмітки пропускає. Аудит сценаріїв задає обсяг першої ітерації та позбавляє від переробок наприкінці. Далі йдемо за кроками — від схеми даних до передачі проєкту.

1. Аудит сценаріїв. Розбираємо поточні шляхи: створення звички, щоденна відмітка, статистика, повернення після пропуску. На виході — карта шляхів для реалізації та список того, що свідомо залишаємо на потім.
2. Схема даних. Описуємо, як зберігається звичка, її розклад, історія відміток і часовий пояс. Вирішуємо, що живе на пристрої, що синхронізується і як розв’язуються конфлікти при офлайн-відмітці з двох пристроїв.
3. Схема нагадувань. Фіксуємо типи повторення, тихі години, реакцію на пропуск і поведінку при вимкнених сповіщеннях. Уже тут видно, де користувач отримає зайве нагадування й вимкне їх зовсім.
4. Налаштування та інтеграції. Підключаємо облікові записи, віджети, календар і дані про кроки, розмічаємо події аналітики за звичками — щоб ефект вимірювався, а не обговорювався.
5. Перевірка на пристроях. Проганяємо сценарії на живих апаратах різних поколінь: зміна часового поясу, переведення годинників, відкликання дозволів, фон, перезавантаження, переїзд на новий пристрій. Так ловляться помилки, невидимі на емуляторі.
6. Передача проєкту. Віддаємо документацію зі схеми даних і налаштувань нагадувань, інструкцію з випуску оновлень, доступи до кабінетів розробника й аналітики та проводимо розбір із командою замовника.

Що залишається в проєкті після здачі та як цим користуватися

Передача проєкту — це не видача доступу до репозиторію, а набір артефактів, за якими ваша команда може розвивати модуль трекера звичок самостійно.

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

• Вихідний код модуля цілком: логіка серій і нагадувань, міграції локального сховища, коректна робота без мережі та черга відкладеної синхронізації.
• Схема даних і синхронізації: що живе на пристрої, що йде на сервер, як розв’язується конфлікт, якщо одну й ту саму звичку відмітили з двох пристроїв.
• Документація з архітектури: призначення модулів, точки розширення, формати подій, з яких збираються сповіщення та статистика.
• Правила доступу: ролі в репозиторії та середовищі збірки, хто володіє ключами підпису збірок, як права передаються при зміні відповідального.
• Регламент перевірки: які автоматичні перевірки запускаються на кожну зміну, що блокує випуск і за яким порядком блокування знімається.
• Порядок доопрацювань власними силами: як підняти середовище, зібрати гілку та випустити оновлення без нашої участі.
• Інструкція з відкату та журнал змін: як повернути користувачам попередню версію й зрозуміти, що і коли змінювалося.

Ми залишаємося на зв’язку на період приймання та розбираємо разом із вашими інженерами спірні місця — далі модуль живе у вашому контурі та за вашими правилами.

Кейс: застосунок із щоденною аудиторією та його результати

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

Історія зберігалася локально й синхронізувалася цілком, тому при зміні телефону частина відміток губилася, а в конфлікті двох копій перемагала записана пізніше.

Що перебудували

Нагадування перевели на тригерну схему: наступне сповіщення рахується від фактичного моменту виконання звички, а не від налаштувань за замовчуванням.

Розклад перезбирається на пристрої при кожній зміні серії, сервер лише доставляє команду — затримка між подією та нагадуванням зникла.

Синхронізацію історії замінили журналом подій: відмітка отримує ідентифікатор і мітку часу, повторне надсилання не створює дубль, конфлікти розв’язуються за часом події, а не за часом приходу на сервер. Відновлення на новому пристрої йде за журналом і переносить усю історію.

Через два релізи частка користувачів, які утримують серію довше тижня, зросла в 1,7 раза, а звернення до підтримки про «зниклі» звички майже припинилися.

Чим тригерний сценарій відрізняється від нагадування за розкладом?

Розклад нагадувань — це фіксовані мітки часу: приймання вітамінів о 8:30, вечірнє зведення, нагадування відмітити воду. Планувальник на пристрої зберігає список таких моментів і віддає сповіщення, коли системний годинник доходить до потрібної мітки. Цього достатньо, коли дія не залежить від поведінки людини й зворотного зв’язку не потребує.

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

Нагадування приходить після пропуску, а не за дзвінком будильника, і не дублюється, якщо людина сама відкрила застосунок за хвилину до надсилання.

Наочніше різниця проявляється на часовому поясі користувача. Розклад у фіксованій зоні ламається при перельоті та переході на літній час: відмітки зсуваються або приходять повторно, бо зміщення змінилося.

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

На практиці обидва механізми доповнюють один одного: розклад задає базову сітку, сценарій її коригує.

Якщо звичку відмічено раніше за нагадування — надсилання скасовується; якщо пропущено два дні — беремо інтервал, у який людина зазвичай відмічає звичку, і сповіщення йде в це вікно.

Журнал спрацювань і захист від повторного надсилання закривають обриви зв’язку та перезапуск пристрою, тому частка виконаних нагадувань зростає, а відписок від сповіщень стає менше.

Сумніви щодо навантаження, приватності даних і строків

Сумніви щодо навантаження, приватності й роботи без зв’язку виникають майже на кожному проєкті трекера звичок — їх дешевше зняти до старту розробки, ніж на етапі зростання аудиторії. Нижче — як ми відповідаємо на них інженерно та що саме перевіряємо.

Що бачить серверна частина?

Проєктуємо так, щоб на сервері не було зайвого: журнал звичок залишається на пристрої, синхронізуються знеособлені записи й агрегати, прив’язані до внутрішнього ідентифікатора.

Ім’я, пошта та інші персональні дані лежать окремо й не потрапляють в аналітику — це закриває більшість питань під час перевірки приватності.

Як трекер поводиться без зв’язку?

Локальне сховище — джерело істини для користувача: відмітку можна поставити і в метро, і в літаку. Зміни накопичуються в черзі й ідуть на сервер при появі мережі, конфлікти розв’язуються за часом останньої правки, а повторне надсилання не створює дублів.

Що відбувається при оновленні системи?

Реліз застосунку та зміна схеми даних ідуть разом: міграції локальної бази виконуються при першому запуску й не втрачають історію відміток.

Старі версії застосунку продовжують працювати із серверною частиною, поки користувач не оновиться сам, а відкат на попередній реліз залишається можливим.

Обговоримо задачу: що надіслати для оцінки та плану робіт

Для оцінки строків не потрібен документ на 40 сторінок — достатньо ввідних, за якими видно обсяг робіт і ризики. Опишіть правила звичок: типи відміток (щоденна, лічильник, інтервальні серії), як рахуються серії та що відбувається при пропуску. Від цих правил залежать і модель даних, і логіка нагадувань.

Далі — межі системи: платформи, чи потрібна синхронізація між пристроями, чи є вхід через зовнішні сервіси та перенесення даних із поточного рішення.

Макети або посилання на працюючий застосунок скорочують етап проєктування: частина спірних місць знімається на розборі, а не в розробці.

Що надіслати, щоб ми повернулися з оцінкою:

• сценарій звичок: типи відміток, періодичність, поведінка при пропуску, робота з часовими поясами;
• платформи та мінімальні підтримувані версії операційних систем — від них залежить обсяг перевірок;
• модель облікового запису: локальний профіль або серверна синхронізація між пристроями;
• нагадування та сповіщення: розклади, реакція на невиконання, тихі години;
• макети, прототип або перелік того, що не влаштовує в поточному застосунку;
• вимоги до аналітики, доступи до магазинів застосунків і хто ухвалює рішення на вашому боці.

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