Статистика угод торговельного бота в мобільному додатку

Торговельний бот щоденно обробляє тисячі угод, але без візуалізації метрик визначити його ефективність неможливо. Ми реалізували модуль статистики, який відображає PnL, Win Rate, Profit Factor та інші показники в реальному часі, дозволяючи трейдеру швидко виявити слабкі місця стратегії. Наприклад, після впровадження нашого дашборду один із клієнтів виявив, що його бот показує Win Rate 65%, але Profit Factor лише 1.1 — це означало, що прибуткові угоди занадто малі, а збиткові великі. Ми допомогли оптимізувати параметри, і Profit Factor зріс до 1.8 — це в 1.6 рази краще за попередній показник, що призвело до зростання загальної дохідності на 40%. Зв'яжіться з нами, щоб оцінити, як такий аналіз покращить вашу торгівлю.

Проблеми, які вирішуємо

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

Як реалізована статистика угод торговельного бота?

Ключові показники, без яких статистика безглузда:

• Total PnL (реалізований) — сумарний дохід/збиток за всіма закритими позиціями
• Win Rate — частка прибуткових угод
• Profit Factor — відношення суми прибуткових угод до суми збиткових (значення > 1.5 вважається прийнятним, > 2 — відмінним)
• Max Drawdown — максимальне падіння балансу від піку до дна у відсотках (детальніше див. Wikipedia)
• Average RR — середнє співвідношення ризик/дохідність
• Sharpe Ratio — опціонально, для досвідчених користувачів

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

Основні екрани — статистика угод торговельного

// iOS, SwiftUI — перемикач періоду та завантаження даних
struct StatsDashboard: View {
    @StateObject private var viewModel = StatsDashboardViewModel()

    var body: some View {
        VStack {
            Picker("Період", selection: $viewModel.period) {
                Text("7д").tag(StatsPeriod.week)
                Text("30д").tag(StatsPeriod.month)
                Text("Все").tag(StatsPeriod.all)
            }
            .pickerStyle(.segmented)
            .onChange(of: viewModel.period) { _ in
                Task { await viewModel.reload() }
            }

            switch viewModel.state {
            case .loading: ProgressView()
            case .loaded(let stats):
                PnLChart(dataPoints: stats.cumulativePnl)
                StatsGrid(stats: stats)
            case .error(let msg): ErrorView(message: msg)
            }
        }
        .task { await viewModel.reload() }
    }
}

Як відобразити історію угод з пагінацією?

Список з пагінацією (cursor-based, не offset — обсяг даних може бути великим). Кожен запис: пара, сторона, розмір, PnL, дата. Фільтр по парі, по стороні (long/short), по результату (profit/loss). Сортування за датою або за розміром PnL. На Android LazyColumn з Pager (Jetpack Paging 3). Завантажує сторінки по 50 записів при прокрутці:

val deals = botRepository.getDeals(botId, filter)
    .cachedIn(viewModelScope)
    .collectAsLazyPagingItems()

LazyColumn {
    items(deals, key = { it.id }) { deal ->
        DealRow(deal = deal)
    }
    item {
        if (deals.loadState.append is LoadState.Loading) {
            CircularProgressIndicator()
        }
    }
}

Чому Profit Factor важливіший за Win Rate?

Високий Win Rate (60%+) може вводити в оману, якщо середня збиткова угода в 2 рази більша за середню прибуткову. Profit Factor враховує розміри угод: значення 1.5 означає, що на кожен втрачений долар припадає 1.5 зароблених. Для автоматичної торгівлі рекомендуємо підтримувати Profit Factor не нижче 1.5, а Win Rate може бути 50–70%. Наприклад, Profit Factor 1.8 в 1.6 рази краще, ніж 1.1, що підвищує дохідність.

Порівняння стратегій

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

Така таблиця будується з агрегованих даних API та рендериться через DataTable (Flutter статистика) або UICollectionView з compositional layout (iOS).

Як влаштована обробка даних на клієнті?

Для прискорення відображення кешуємо агреговані метрики на клієнті (Room/SQLite або CoreData). Це дозволяє відкривати дашборд миттєво, без очікування запиту. При оновленні даних фонова синхронізація підтягує свіжі метрики. Також реалізовано експорт історії в CSV для аналізу в Excel.

Типовий ендпоінт: GET /api/bots/{id}/stats?period=30d. Відповідь: { totalPnl: 1240.0, winRate: 0.58, profitFactor: 1.82, maxDrawdown: 0.12, tradesCount: 142, cumulativePnl: [{"date":"2024-01-15","value":100}, ...] }. На клієнті модель декодується через Codable (iOS) або Moshi (Android).

Як аналізувати статистику покроково?

1. Визначте період (7д/30д/All) для отримання актуальних даних.
2. Оцініть Total PnL та Win Rate на summary-картках.
3. Перегляньте графік кумулятивного PnL для візуальної оцінки динаміки.
4. Перевірте Profit Factor: якщо <1.5, потребує оптимізації.
5. Використовуйте таблицю порівняння для виявлення найслабших пар.
6. Експортуйте історію в CSV для глибокого аналізу.

Що входить в роботу

• Дашборд з summary-метриками та графіком кумулятивного PnL
• Перемикач періоду (7d/30d/All)
• Історія угод з пагінацією, фільтрами та сортуванням
• Таблиця порівняння по парах/стратегіях
• Експорт історії в CSV
• Кешування даних на клієнті для миттєвого відгуку

Терміни та вартість

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

Наш досвід — 5+ років на ринку, понад 20 успішних проектів для торгових додатків на iOS та Android, включаючи реалізацію SwiftUI графіків та Jetpack Compose статистики. Ми гарантуємо дотримання метрик та оптимізацію продуктивності під великі обсяги даних. Оцініть наші послуги — замовляйте розробку зараз.

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

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