Розробка трекінгу калорій у мобільному додатку

Трекінг калорій у застосунку: де ламається підрахунок

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

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

Друга точка відмови — розмиті порції. «Середня тарілка», «ложка», «жменя» не мають маси, а похибка підрахунку накопичується: 20% помилки на кожному прийомі їжі за день дають розходження, через яке щоденник харчування перестає відображати реальність. Користувач бачить стабільну вагу при «дефіциті» й робить висновок, що метод не працює.

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

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

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

Що дає користувачеві коректний трекінг калорій

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

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

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

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

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

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

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

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

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

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

Способи введення даних: ручний, сканер, фото, голос

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

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

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

Голосове введення ми підключаємо як доповнення, а не заміну: воно зручне для серії позицій підряд, але розпізнавання формулювань на кшталт «півтарілки» або «шматок» потребує словника порцій під конкретний продукт.

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

Ми проєктуємо введення так, щоб кожен запис приводився до єдиної одиниці вимірювання, а користувач міг перемкнути спосіб прямо в момент додавання.

Як ми будуємо застосунок для трекінгу калорій: етапи

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

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

База продуктів, порції та перерахунок нутрієнтів

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

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

Тоді «половина склянки», «скибка» та «столова ложка» розкладаються в грами через таблицю мір, а не через здогадки.

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

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

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

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

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

Синхронізація з носимыми пристроями та здоров'ям

Синхронізація будується на штатних платформних сховищах здоров'я — HealthKit в iOS та Health Connect в Android. Застосунок запитує доступ лише до потрібних типів даних: кроки, активна енергія, тренування, сон, пульс.

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

Apple Health та аналогічний сервіс на Android виступають єдиною точкою обміну: годинник, браслет, ваги та сторонні застосунки пишуть туди, а трекінг читає звідти.

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

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

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

Що відбувається при розсинхронізації

Дані пишуться порціями з мітками часу, тому конфлікти вирішуються за джерелом і часом запису, а не «хто останній». Якщо пристрій відключився на день, застосунок довантажує історію при наступному підключенні та перераховує баланс. Користувач бачить актуальну картину, а не розрив у статистиці.

Межі доступу та приватність

Ми запитуємо мінімальний набір дозволів і обробляємо дані на пристрої. На сервер іде лише агрегат для синхронізації між гаджетами — без сирих записів про здоров'я. Такий підхід проходить перевірки магазинів застосунків і не створює ризиків при відкликанні доступу.

Що робити, якщо застосунок уже випущено

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

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

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

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

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

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

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

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

Так доопрацювання відбувається поверх працюючого продукту, без переписування і без втрати користувачів.

Що замовник отримує на руки

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

• Конфігурації збірки та середовищ. Окремі профілі для розробки, тестового контуру та продакшену, змінні середовища, ключі доступу до зовнішніх сервісів, правила підпису та версіонування збірок. Розгортання відтворюється на чистій машині однією командою.
• Схеми даних. Структура зберігання профілів, щоденника прийому їжі, порцій та історії ваги: таблиці, зв'язки, індекси, правила міграцій. Окремо — як розраховується добова норма та як зберігаються перевизначення користувача.
• Довідник продуктів. Формат записів, поля порцій та мір, правила зіставлення при ручному введенні та при скануванні штрихкоду, порядок поповнення бази та обробки дублів.
• Регламенти оновлення. Як випускається нова версія, що перевіряється перед публікацією в магазинах, як відкочується проблемний реліз і як зміни довідника потрапляють до користувачів без перезбирання застосунку.
• Документація для підтримки. Опис модулів, точки інтеграції із сторонніми сервісами, типові звернення та порядок дій за ними, перелік відомих обмежень.
• Доступи та права. Облікові записи, ролі, прив'язка до акаунтів магазинів і панелей зовнішніх сервісів, порядок ротації ключів.
• Набір перевірок. Автотести на розрахунок норми, синхронізацію щоденника та роботу з офлайн-режимом — зі звітом про те, які шляхи покриті, а які ні.

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

Кейс: щоденник харчування з ручним введенням і втратами даних

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

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

Що показав розбір

Ми вивантажили воронку за подіями і побачили, що 68% записів створювалися вручну, а середня сесія введення розтягувалася до 2 хвилин 40 секунд. Утримання на другому тижні трималося на 19%, а підтримка отримувала скарги одного класу: «ввів їжу, застосунок закрився, все зникло».

Виявилося, чернетка прийому їжі жила тільки в пам'яті екрана — згортання застосунку або втрата мережі стирали введене.

Що змінили

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

Метрики до і після

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

Обговоримо ваше завдання з трекінгу калорій

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

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

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

Якщо зовнішнє — як кешувати відповіді, щоб щоденник відкривався миттєво і не залежав від чужої доступності.

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

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

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

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

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