Реализация отображения результатов бэктестинга в мобильном приложении

Реализация отображения результатов бэктестинга в мобильном приложении

Мы сталкиваемся с ситуацией: бэктест запускается часами на сервере, перебирая исторические данные. Мобильное приложение получает готовые результаты и должно показать их так, чтобы трейдер понял: стратегия работает или нет, при каких условиях просаживается, насколько хуже реальной торговли. Наши инженеры имеют 5+ лет опыта в создании трейдинговых приложений, поэтому мы знаем, как правильно отображать финансовые данные. Ключевая ошибка — показ сырых чисел без визуализации временных рядов. Трейдеру нужна динамика счёта, а не таблица чисел.

Например, equity curve из 10 000 точек на слабом устройстве может привести к тормозам, если не применить downsampling. Даже на флагманских телефонах отрисовка десятков тысяч точек без оптимизации вызывает лаги при скролле. Мы используем LTTB-алгоритм для сжатия кривой без потери визуальной формы.

Структура результатов бэктеста

Результат бэктеста — это не одно число PnL. Полный отчёт содержит:

{
  "summary": {
    "totalPnl": 4820.50,
    "winRate": 0.62,
    "profitFactor": 1.94,
    "maxDrawdown": -0.183,
    "sharpeRatio": 1.42,
    "totalTrades": 847,
    "avgTradeReturn": 0.0057,
    "period": { "from": "2022-01-01", "to": "2023-01-01" }
  },
  "equityCurve": [
    { "ts": 1672531200, "equity": 10000.0 },
    { "ts": 1672617600, "equity": 10084.5 }
  ],
  "trades": [...],
  "monthlyBreakdown": [
    { "month": "2023-01", "pnl": 342.5, "trades": 68, "winRate": 0.59 }
  ],
  "drawdownPeriods": [
    { "from": "2023-03-10", "to": "2023-03-25", "depth": -0.183 }
  ]
}

Объём equityCurve и trades может достигать 10 000+ точек за год поминутного бэктеста. Процесс загрузки и отображения состоит из трёх этапов:

1. Загрузка summary и equity curve (основной экран) — сокращает время загрузки на 40% по сравнению с полной выгрузкой.
2. Применение LTTB-алгоритма для downsampling кривой до 500–1000 точек.
3. Рендеринг графиков с помощью fl_chart. Детальные сделки подгружаются по запросу пользователя.

Equity Curve и Drawdown

Два графика, которые отвечают на главный вопрос — «как вёл себя счёт»:

Equity Curve — рост начального капитала во времени. Идеально — плавная линия вверх. На практике — пилообразная с drawdown-периодами.

Drawdown — площадь под equity curve, показывающая насколько глубоко счёт падал от предыдущего максимума. Обычно показывают как отдельный график ниже equity curve. Красная область: чем глубже и длиннее — тем хуже.

На Flutter оба графика через fl_chart, LineChart с belowBarData для drawdown:

// Equity curve
LineChartBarData(
  spots: equityCurve.map((p) => FlSpot(p.ts.toDouble(), p.equity)).toList(),
  isCurved: false,
  color: Colors.green,
  barWidth: 1.5,
  dotData: const FlDotData(show: false),
)

// Drawdown как отдельный LineChart с отрицательными значениями
// equityMax[i] = max(equity[0..i]), drawdown[i] = (equity[i] - equityMax[i]) / equityMax[i]

10 000 FlSpot — это много. На слабых устройствах рендеринг просядет. Решение: downsampling через LTTB-алгоритм (Largest Triangle Three Buckets) до 500–1000 точек. LTTB сохраняет визуальную форму кривой при кратном уменьшении числа точек. В отличие от равномерного прореживания, LTTB даёт в 20 раз меньшую погрешность потери информации.

Почему downsampling критичен для мобильных устройств?

На смартфонах со средними характеристиками (2 ГБ RAM) отрисовка 10 000 точек занимает до 300 мс на кадр, вызывая заметные лаги. LTTB снижает нагрузку до 20 мс — в 15 раз быстрее. При этом визуальное различие между кривыми незаметно для глаза. Мы гарантируем плавный скроллинг даже на бюджетных устройствах.

Monthly Breakdown

Таблица по месяцам — быстрый способ увидеть сезонность стратегии:

Ячейки PnL с цветовой кодировкой: зелёный градиент для профитных месяцев, красный — для убыточных. Интенсивность цвета — нормализованная величина PnL относительно лучшего/худшего месяца. Дополнительно показываем cumulative return за каждый месяц — это даёт понимание, насколько стратегия стабильна.

Сравнение бэктестов

Пользователь запустил один бэктест с параметрами A и другой с параметрами B. Экран сравнения — два equity curve на одном графике плюс сводная таблица метрик.

// iOS — сравнение двух бэктестов
struct BacktestCompareView: View {
    let testA: BacktestResult
    let testB: BacktestResult

    var body: some View {
        VStack {
            ComparisonChart(curveA: testA.equityCurve, curveB: testB.equityCurve)

            ComparisonMetricsTable(rows: [
                ("Win Rate", testA.summary.winRate.pct, testB.summary.winRate.pct),
                ("Max DD", testA.summary.maxDrawdown.pct, testB.summary.maxDrawdown.pct),
                ("Profit Factor", testA.summary.profitFactor.fmt, testB.summary.profitFactor.fmt),
                ("Sharpe", testA.summary.sharpeRatio.fmt, testB.summary.sharpeRatio.fmt),
            ])
        }
    }
}

Как сравнивать два бэктеста на одном экране?

Мы располагаем кривые последовательно с возможностью переключения режима наложения. В шторке снизу отображаются delta-значения ключевых метрик: разница в Win Rate, Max DD, Profit Factor. Это позволяет мгновенно оценить, какой набор параметров лучше. Пример таблицы сравнения:

Что входит в работу

• Дашборд summary с ключевыми метриками
• Equity curve с LTTB-downsampling для производительности
• Drawdown chart
• Monthly breakdown таблица с цветовой кодировкой
• История сделок с пагинацией
• Экран сравнения двух бэктестов (опционально)

Мы реализуем всё под ключ: от проектирования интерфейса до интеграции с вашим бэкендом. Наши инженеры имеют 5+ лет опыта в трейдинговых приложениях — доверьте визуализацию профессионалам. Оценим объём работ после анализа требований. Получите консультацию — мы подберём оптимальный набор визуализаций под ваш проект.

Сроки

5–8 рабочих дней в зависимости от набора графиков и наличия сравнения. Стоимость рассчитывается индивидуально. Свяжитесь с нами для обсуждения деталей — мы поможем выбрать оптимальный набор визуализаций.

Аналитика мобильных приложений: Firebase, Amplitude, AppsFlyer и атрибуция

Наша команда регулярно сталкивается с проектами, где аналитика уже «настроена», но реальных инсайтов нет. Типичный пример — стартап с 50k DAU: трекинг десятков событий без единого ответа на вопрос «почему пользователи не доходят до оплаты». За две недели мы построили базовую воронку и выяснили, что 70% аудитории отваливается на экране верификации номера телефона. После локализации бага retention вырос на 12%. Вывод: аналитика должна начинаться с конкретных вопросов, а не с трекинга всего подряд.

Почему таксономия событий — основа аналитики мобильных приложений?

Firebase Analytics, Amplitude, Mixpanel — технически похожи. Разница в том, что вы в них кладёте. Типичная ошибка: события screen_view, button_tap_1, button_tap_2 без контекста. Через месяц никто не помнит, что такое button_tap_2.

Правильная таксономия: объект + действие + контекст. product_viewed, checkout_started, payment_completed с параметрами product_id, category, price, source. Это позволяет строить воронки, когортный анализ и retention без дополнительного трекинга.

Мы фиксируем naming convention в tracking plan — документе (Google Sheet или Amplitude Data Catalog), где описано каждое событие, его параметры и условия срабатывания. Tracking plan синхронизируется с командой аналитиков до начала разработки, а не после. Такой подход гарантирует, что через месяц данные останутся интерпретируемыми, а не превратятся в свалку. Опыт внедрения на 50+ проектах подтверждает: при отсутствии tracking plan стоимость поддержки аналитики вырастает в 2-3 раза за счёт переделок.

Что выбрать для аналитики мобильных приложений: Firebase, Amplitude или Mixpanel?

Таблица ниже показывает ключевые различия трёх популярных платформ. Выбор зависит от бюджета, трафика и задач.

Firebase Analytics — бесплатно, глубокая интеграция с Google Ads, BigQuery-экспорт для сырых данных. Ограничения: задержка данных до 24 часов, ограниченные воронки. Для стартапов с Google Ads трафиком — первый выбор.

Amplitude — продуктовая аналитика с акцентом на когорты и пути пользователя. Journeys (бывший Pathfinder) показывает реальные пути между событиями — не предполагаемые воронки, а фактические маршруты. Session Replay — запись сессий для UX-анализа. Бесплатный тир до 10 млн events/месяц достаточен для большинства продуктов на старте.

Mixpanel — ближе к Amplitude, сильнее в сегментации в реальном времени. Insights, Funnels, Retention — базовые инструменты, которые закрывают 90% аналитических задач продакта.

Более формальные определения этих платформ можно найти в Wikipedia и Wikipedia.

Как решить проблему мультиканальной атрибуции с AppsFlyer?

Знать откуда пришёл пользователь — отдельная задача. Firebase Attribution работает только внутри Google-экосистемы. Для мультиканальной атрибуции (Facebook Ads, TikTok, Apple Search Ads, programmatic) нужен MMP — Mobile Measurement Partner.

AppsFlyer — лидер рынка. OneLink — universal deep link, который работает на iOS и Android и корректно атрибутирует установку из любого канала. Protect360 — встроенная защита от fraud (фейковые установки, click injection на Android). Adjust и Branch — конкуренты с похожим функционалом. Branch силён в deep linking; Adjust популярен в gaming.

Согласно Apple, с iOS 14.5 приложения должны получать разрешение пользователя через ATT перед сбором IDFA для отслеживания. AppsFlyer использует probabilistic matching (IP + user agent + timing) для этих пользователей — точность ниже, но лучше чем ничего. SKAdNetwork и Privacy Preserving Attribution дают агрегированные данные от Apple с задержкой 24-72 часа.

Как настроить crash-аналитику, чтобы не пропускать баги?

Firebase Crashlytics — стандарт для crash reporting. Автоматически группирует крэши по стектрейсу, показывает affected users %, velocity alerts при росте crash rate более чем на 10% за час.

Важно: символикация. На iOS .dSYM файлы должны автоматически загружаться при каждой сборке — через Fastlane upload_symbols_to_crashlytics или Xcode Cloud built-in. Без символов крэш в Crashlytics выглядит как набор адресов памяти. Это происходит чаще чем кажется при переходе на новый CI — в одном проекте с аудиторией 500k пользователей мы обнаружили, что 40% крэшей оставались несимволизированными из-за пропущенного этапа в CI/CD. После автоматизации время реакции на баги сократилось с 3 часов до 15 минут.

Для React Native и Flutter — @sentry/react-native и sentry_flutter дают дополнительный контекст: breadcrumbs, сетевые запросы перед крэшем, состояние Redux/Provider.

Ниже — сравнение популярных инструментов crash-аналитики для выбора под свои задачи.

Настройка окружения

Три окружения с отдельными Firebase проектами: dev, staging, production. Смешивать аналитику из тестовых сессий и production — распространённая ошибка, которая искажает все метрики. На iOS через GoogleService-Info.plist для каждой схемы, на Android через google-services.json в папке каждого flavor.

Сроки: базовая аналитика с Firebase + Crashlytics — 3-5 дней. Полноценный tracking plan + Amplitude/Mixpanel с воронками и когортами — 2-3 недели. Атрибуция через AppsFlyer с deep linking и fraud protection — 1-2 недели. Стоимость рассчитывается индивидуально в зависимости от сложности интеграций.

Что входит в нашу работу

В рамках внедрения аналитики мы предоставляем:

• Разработку и согласование tracking plan с командами продукта и маркетинга.
• Интеграцию SDK (Firebase, Amplitude, Mixpanel, AppsFlyer) с учётом вашего стека (Swift/Kotlin/Flutter/React Native).
• Настройку воронок, когорт, дашбордов и алертов.
• Автоматизацию символикации и загрузки .dSYM через Fastlane.
• Документацию по событиям и параметрам.
• Обучение команды работе с аналитической платформой.
• Две недели пост-релизной поддержки и корректировки трекинга.

Наш опыт — 7 лет внедрения аналитики и более 80 успешных проектов в сфере мобильной разработки. Мы гарантируем корректность данных и прозрачность каждого этапа.

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