Работа с данными трекинговых устройств. Интеграции и структура данных

В прошлом посте рассказал наш общий подход к работе с данными трекеров.
Сегодня подробнее про первый шаг - формирование общей структуры базы данных.

Мы планируем поэтапно интегрироваться с разными видами трекинговых устройств и в конечном счете охватить все.

Мы закладываем, что пользователь может сменить устройство. А в редких случаях — пользоваться несколькими одновременно.

Поэтому нам важно было сформировать единую структуру базы данных, которая учитывает все возможные данные и приводит их к одному формату.

Для этого изучили, какую информацию и в каком виде можно получать с Apple Health, Google Health Connect, Whoop, Oura и Garmin — основных и наиболее популярных устройств.

Все данные с трекеров мы делим на три большие группы:

1. Показатели

Разделены на несколько доменов:

Пульс и сердце — пульс дневной, пульс покоя, HRV, пульс при ходьбе
Сон — длительность, время отбоя и подъёма, стадии, время в постели
Активность и движение — шаги, минуты интенсивности, этажи, набор высоты, калории
Дыхание и кислород — SpO₂, суточный и мгновенный
Температура — температура кожи, базальная температура

Показатели бывают разной гранулярности измерения:
мгновенные значения
дневные, средние, ночные
фиксация по триггеру, когда пользователь сам запускает замер

2. События

Тоже делятся на группы: сон, тренировки, бытовая и профессиональная активность, сессии восстановления (баня, массаж, ...)

Показатели связываются с событиями, для этого у нас отдельная таблица связей.
Это важно и для хранения данных, и для их дальнейшей интерпретации: пульс во время сна, пульс на тренировке и пульс в бане — интерпретируются по разному.

3. Расчётные показатели вендора

Это уже не базовые показатели, а алгоритмические — скор активности, восстановление, оценка качества сна, оценка уровня стресса и другие.
Каждый вендор считает их по своей закрытой модели, поэтому для каждого устройства они свои.

Мы их тоже сохраняем — в том объёме, в каком вендор их отдаёт. Но храним в отдельной структуре, потому что интерпретировать их и внедрять в ассистента нужно иначе, чем обычные показатели.

По всем данным обязательно фиксируем id устройства, чтобы отдельно обрабатывать сценарии смены (даже по базовым показателям между данными с разных устройств будут погрешности).

Поставьте реакции, если тема интересна — в следующих постах расскажу про:
• базу общих нормативных значений показателей
• расчёт медианных значений пользователя и зачем они нужны
• определение отклонений разных типов
• наборы правил интерпретации, подкреплённые источниками
• как из всего этого формируются инсайты передачи данных в ассистент
• как эти данные внедряются в контекст диалогов и рекомендательной системы