Відображення результатів бектестування в мобільному додатку

Відображення результатів бектестування в мобільному додатку

Ми стикаємося з ситуацією: бектест запускається годинами на сервері, перебираючи історичні дані. Мобільний додаток отримує готові результати і повинен показати їх так, щоб трейдер зрозумів: стратегія працює чи ні, за яких умов просідає, наскільки гірше реальної торгівлі. Наші інженери мають 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 (Firebase) та Wikipedia (Amplitude).

Як вирішити проблему мультиканальної атрибуції з 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 успішних проектів у сфері мобільної розробки. Ми гарантуємо коректність даних і прозорість кожного етапу.

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