Розробка AI-рекомендацій здоров'я для мобільних додатків
Більшість health-додатків показують користувачеві цифри — і той закриває додаток, так і не змінивши звичок. Ми змінюємо сценарій: замість «ось ваші дані» даємо «ось що ці дані значать для вас сьогодні». За даними HealthKit, середня щоденна активність користувача — 5 423 кроки, сон — 7.1 год. На основі цих даних rule engine генерує 12–20 кандидатів на день, ML-ранжування вибирає 3–5 найбільш релевантних. Наприклад, якщо пульс спокою вище 80 bpm і сон менше 6.5 год, рекомендація — знизити інтенсивність тренувань.
У цій статті я розповім, як ми будуємо систему рекомендацій: від збору даних до доставки push-повідомлень. Ви дізнаєтеся, чому rule engine — не пережиток, а фундамент, і як ML додає персоналізацію без втрати прозорості. Ми розробили 15+ health-додатків, 5+ років досвіду, один із проектів досяг 500 000+ встановлень. Якщо вам потрібна аналогічна система, пишіть нам — ми допоможемо спроектувати та впровадити її під ключ.
Чому rule engine — основа персоналізованих рекомендацій?
Rule-based підхід — не застарілий, а практичний. Правила прозорі, тестовані, не потребують датасету для навчання. ML поверх правил додає персоналізацію в ранжуванні. Комбіновані умови важливі: пульс спокою 85 bpm сам по собі може бути нормою, але в поєднанні з недосипом — маркер перетренованості. Згідно з дослідженнями Американської кардіологічної асоціації, таких комбінацій десятки.
Архітектура системи рекомендацій
Персоналізовані рекомендації здоров'я — це pipeline з кількох шарів, а не один алгоритм. У таблиці нижче — основні компоненти та їх призначення.
| Слой | Призначення | Приклад технології |
|---|---|---|
| Збір даних | Отримання сирих показників | HealthKit, Health Connect, Core Bluetooth |
| Профіль користувача | Вік, цілі, поведінкові патерни | Realm / Core Data |
| Feature engineering | Агрегація в осмислені метрики | Swift Combine / Kotlin Flow |
| Rule engine | Прозорі умови з пріоритетами | Кастомний на Swift/Kotlin |
| ML-ранжування | Персоналізація кандидатів | Gradient boosting (XGBoost) |
| Відображення | In-app / push з оптимальним таймінгом | UNNotification / FCM |
Дані: HealthKit як єдина точка на iOS
class HealthDataAggregator { private let store = HKHealthStore() func weeklyStats() async throws -> HealthWeekSnapshot { async let steps = fetchSum(.stepCount, days: 7) async let sleepHours = fetchCategorySamples(.sleepAnalysis, days: 7) async let restingHR = fetchAverage(.restingHeartRate, days: 7) async let activeEnergy = fetchSum(.activeEnergyBurned, days: 7) return try await HealthWeekSnapshot( avgDailySteps: steps / 7, avgSleepHours: sleepHours, avgRestingHR: restingHR, totalActiveKcal: activeEnergy ) } } На Android — Health Connect SDK з HealthConnectClient.readRecords(StepsRecord::class) для запиту кроків за період. Ми також підключаємо сторонні пристрої через Core Bluetooth на iOS та BLE на Android, щоб отримувати дані з ваг, тонометрів та фітнес-браслетів.
Як ML покращує персоналізацію?
Rule engine генерує список кандидатів-рекомендацій. ML-модель ранжує їх за ймовірністю виконання конкретним користувачем. Використовуємо градієнтний бустинг на фічах: історичний CTR, патерн дня тижня, streak виконання. Навчаємо на імпліцитному зворотному зв'язку: показано → відкрито → виконано (дані з HealthKit). ML-ранжування в 1.5–2 рази ефективніше за чисто rule-based підхід за показником CTR.
Як підбирається час для push-повідомлень?
Правильний момент важливіший за зміст. «Лягайте спати раніше» о 20:00 працює, о 23:30 — ні.
func scheduleRecommendation(_ rec: Recommendation) { let content = UNMutableNotificationContent() content.title = rec.title content.body = rec.shortBody content.sound = .default let bestTime = optimalDeliveryTime(for: rec, userSchedule: userProfile.typicalSchedule) let trigger = UNCalendarNotificationTrigger( dateMatching: Calendar.current.dateComponents([.hour, .minute], from: bestTime), repeats: false ) let request = UNNotificationRequest(identifier: rec.id, content: content, trigger: trigger) UNUserNotificationCenter.current().add(request) } optimalDeliveryTime аналізує патерни користувача: час відкриття додатку, сон, тренування. Прив'язка до контексту: якщо CMMotionActivityManager показує, що користувач іде — рекомендацію по активності не показуємо.
Принципи ефективних рекомендацій
Одна конкретна рекомендація на день краща за п'ять загальних. «Пройдіть 2 000 кроків до 18:00, у вас зараз 1 200» — працює. «Більше рухайтесь» — ні. Прив'язка до контексту та персоналізація — ключові фактори залучення. Ми використовуємо A/B тестування, щоб відбирати найбільш ефективні формати та контент.
Поетапний процес роботи над рекомендаціями
- Аналіз джерел даних та проектування схеми HealthKit/Health Connect.
- Розробка 20–50 правил на основі медичних протоколів та типових сценаріїв.
- Реалізація ML-ранжування на синтетичних даних для навчання.
- Система доставки: in-app віджети + push з оптимальним таймінгом.
- A/B тестування ефективності (мінімум 2 тижні).
- Документація API та навчання команди адмініструванню правил.
Що входить в роботу
- Документація API з інтеграції та управління правилами.
- Навчання команди замовника адмініструванню та доопрацюванню рекомендацій.
- Підтримка після запуску протягом 3 місяців.
- Гарантія на код: виправлення помилок у рамках заданої архітектури.
Вартість такого рішення під ключ — від $5 000 до $15 000 залежно від складності інтеграції. Економія на міграції до нашого рішення складає до 40% порівняно з альтернативами.
Орієнтири за термінами
| Етап | Термін |
|---|---|
| Rule-based MVP з базовими рекомендаціями | 1–2 тижні |
| Повна система з ML-ранжуванням та таймінгом | 3–5 тижнів |
| A/B тестування та доопрацювання | +2 тижні |
Точна оцінка залежить від складності інтеграції та кількості джерел даних. Напишіть нам для консультації — ми проаналізуємо ваш проект за 1 день. Отримайте індивідуальну пропозицію, зв'язавшись з нами.







