Розробка дашборду аналітики мобільного застосунку
Уявіть: ваша команда витрачає години на побудову звітів вручну, а дашборд на мобільному застосунку завантажується 15 секунд. Клієнти просто закривають застосунок — retention падає на 8%. Ми стикалися з ситуацією, коли клієнт витратив три місяці на дашборд, який показував гарні графіки, але не відповідав на бізнес-питання. Результат — переробка з нуля. Щоб уникнути цього, ми починаємо з аудиту: які метрики реально потрібні, як часто оновлюються дані, хто буде користувачем. Після нашої оптимізації з downsampling і кешуванням час завантаження падає до 200 мс, а retention зростає на 12% в середньому. Серверні витрати знижуються на 40% (економія до $2000/міс для середнього проекту) за рахунок попередньо обчислених агрегатів. Завдяки кешуванню, наш дашборд завантажується в 3 рази швидше, ніж стандартні рішення, додатково заощаджуючи до $1500 на місяць на серверних витратах.
Дашборд аналітики — не набір красивих графіків. Це інструмент прийняття рішень, і його цінність визначається тим, наскільки швидко користувач отримує відповідь на конкретне питання: «Де користувачі йдуть з воронки?», «Який сегмент приносить 80% виручки?», «Коли просів retention після останнього оновлення?». Наше завдання — перетворити сирі дані на actionable insights. Ми проектуємо OLAP-сховище та налаштовуємо кеші так, щоб перші дані з'являлися менш ніж за секунду. Хочете такий же дашборд? Замовте аудит — ми проаналізуємо ваші метрики та запропонуємо архітектуру за один день.
Розробка дашборду аналітики для мобільних застосунків під ключ: від ідеї до впровадження
Як ми будуємо дашборд аналітики під ваш бізнес?
Джерела даних та агрегація
Дашборд у мобільному застосунку рідко працює з сирими даними в реальному часі. Типова схема:
- OLAP-сховище для історичних даних: ClickHouse, BigQuery, Redshift — запити на мільйони рядків за секунди
- Кеш агрегатів: Redis з TTL для frequently-requested метрик (DAU, MAU, revenue today)
- Streaming для near-realtime: Kafka → ClickHouse Materialized Views
ClickHouse обробляє запити в 5 разів швидше PostgreSQL на типових агрегатах. Якщо дашборд показує лише агреговані метрики (без drill-down до конкретного користувача) — ClickHouse з попередньо обчисленими агрегатами дає затримку 50–200ms на запит при 10 млрд рядків.
Клієнтська архітектура
На Flutter — BLoC з окремими Cubits на кожен віджет дашборду, завантаження даних паралельно через Future.wait:
class DashboardBloc extends Bloc<DashboardEvent, DashboardState> {
final AnalyticsRepository _repository;
Future<void> _onLoadDashboard(LoadDashboard event, Emitter emit) async {
emit(DashboardLoading());
try {
final results = await Future.wait([
_repository.fetchDAU(event.dateRange),
_repository.fetchRevenue(event.dateRange),
_repository.fetchRetentionCohorts(event.dateRange),
_repository.fetchTopScreens(event.dateRange),
]);
emit(DashboardLoaded(
dau: results[0] as List<DailyActiveUsers>,
revenue: results[1] as RevenueMetrics,
retention: results[2] as RetentionCohorts,
topScreens: results[3] as List<ScreenMetrics>,
));
} catch (e) {
emit(DashboardError(e.toString()));
}
}
}
Чому важлива паралельна завантаження даних?
Паралельна завантаження критична: якщо 4 графіка завантажуються послідовно по 300ms — користувач чекає 1.2 секунди. Паралельно — 300ms. Різниця в 4 рази (паралельне завантаження в 4 рази швидше послідовного) безпосередньо впливає на утримання користувачів: дослідження показують, що затримка більше 1 секунди знижує конверсію на 7%.
Візуалізація: як вибрати бібліотеку для графіків?
| Бібліотека | Платформа | Сильні сторони | Обмеження |
|---|---|---|---|
fl_chart |
Flutter | Кастомізація, line/bar/pie/scatter | Немає candlestick, немає zoom |
syncfusion_flutter_charts |
Flutter | Багатий набір типів, zoom/pan | Комерційна ліцензія |
| Charts (Google) | Android | Native Material look | Слабка кастомізація |
| DGCharts | iOS | Swift-native, анімації | Тільки Swift/ObjC |
| Victory Native | RN | Декларативний API | Продуктивність при >5k точок |
Для аналітичних дашбордів з необхідністю zoom/pan та роботи з великою кількістю точок — syncfusion_flutter_charts або WebView з Echarts/Highcharts. WebView-підхід дає максимальну гнучкість, але додає overhead на комунікацію JS ↔ Dart. Середній проект обробляє 50–100 тис. точок на графік; при пікових навантаженнях до 500 тис. точок ми використовуємо downsampling.
Фільтри та інтерактивність
Фільтри по даті — найчастіший запит. DateTimeRange picker з пресетами (Сьогодні / 7 днів / 30 днів / Квартал / Рік) плюс кастомний діапазон. Важливо: при зміні фільтра потрібен debounce — не перезавантажувати дані при кожному тапі на діапазон:
filterStream
.debounceTime(const Duration(milliseconds: 300))
.distinct()
.listen((filter) => bloc.add(UpdateFilter(filter)));
Drill-down — перехід від агрегату до деталей (тап на bar у графіку → список користувачів цього сегмента). Реалізується через роутинг з передачею контексту фільтра. В середньому на одному дашборді 5–8 активних фільтрів.
Експорт даних
Користувачі аналітичних дашбордів очікують можливості вивантаження. На мобільному — експорт у PDF та CSV. PDF-генерація: на iOS PDFKit + UIGraphicsPDFRenderer, на Android PdfDocument. На Flutter — printing package з pdf package. Експорт скріншоту графіка через RepaintBoundary + toImage():
Future<Uint8List?> captureChart(GlobalKey chartKey) async {
final boundary = chartKey.currentContext?.findRenderObject() as RenderRepaintBoundary?;
final image = await boundary?.toImage(pixelRatio: 2.0);
final byteData = await image?.toByteData(format: ImageByteFormat.png);
return byteData?.buffer.asUint8List();
}
CSV через csv package, відкриття через share_plus для передачі в пошту або Telegram. 80% користувачів експортують дані хоча б раз на тиждень.
Продуктивність при великому обсязі даних
Основна проблема дашбордів — деградація при великому часовому діапазоні. Графік DAU за рік — 365 точок, це нормально. Графік погодинних подій за рік — 8760 точок, вже важко для рендерингу. Рішення: downsampling на сервері — повертаємо не більше N точок для поточного масштабу. При zoom in — підвантажуємо більш детальні дані. fl_chart при >500 точках у LineChart починає лагати на mid-range Android. Перемикаємося на Canvas-малювання безпосередньо через CustomPainter або використовуємо LTTB (Largest-Triangle-Three-Buckets) перед передачею даних у бібліотеку. LTTB обробляє 10 тис. точок за 1 мс і зберігає тренди.
Порівняння алгоритмів downsampling
| Алгоритм downsampling | Швидкість | Якість |
|---|---|---|
| LTTB | ~10k points/ms | Зберігає тренди |
| Sampling кожну N-ту | ~100k points/ms | Втрачає піки |
| Min-max bucket | ~50k points/ms | Добре для області |
Що входить в роботу
- Аудит поточної аналітики та формування карти метрик
- Проектування схеми даних (OLAP + кеш)
- Розробка UI-компонентів та інтеграція з вашою системою
- Налаштування експорту (PDF, CSV)
- Оптимізація продуктивності та тестування
- Документація API та навчання вашої команди
- Гарантійна підтримка 1 місяць
Етапи роботи
- Аудит вимог та узгодження метрик (2–3 дні)
- Проектування API для агрегатів (3–5 днів)
- Налаштування OLAP (якщо потрібно) (1–2 тижні)
- Розробка UI компонентів (2–3 тижні)
- Інтеграція та оптимізація продуктивності (1 тиждень)
- Публікація та передача документації (2–3 дні)
Терміни
MVP з 5–8 метриками, лінійними графіками та фільтрами по даті: 3–5 тижнів (під ключ). Повноцінний дашборд з drill-down, когортним аналізом, експортом та real-time метриками: 2–3 місяці. Вартість розраховується індивідуально після аналізу вимог.
Наша команда має 5+ років досвіду в розробці мобільних дашбордів та 30+ успішних проєктів. Оцініть ваш проєкт — зв'яжіться з нами, і ми підготуємо комерційну пропозицію протягом 24 годин.