Моніторинг торгового бота в реальному часі: WebSocket, PnL, сповіщення

Вступ

Уявіть: бот відкрив позицію, ринок різко розвертається, а ви дізнаєтесь про це через 5 секунд — коли ціна вже пішла на позначку стоп-лосу. Затримка в мобільному моніторингу напряму конвертується у втрати. Ми розробляємо мобільні додатки, які підключаються до вашого торгового бота через WebSocket — затримка менше 200 мс, тобто в 25 разів швидше, ніж REST-полінг кожні 5 секунд. Наш досвід показує, що правильно реалізований транспорт з exponential backoff і синхронізацією стану гарантує актуальність даних навіть при нестабільній мережі. Команда сертифікованих iOS, Android та Flutter-розробників реалізує проект під ключ за 5–7 робочих днів. Більше 5 років ми створюємо high-performance рішення для фінансового сектору, і цей кейс — один з типових.

Як працює WebSocket-транспорт?

REST-полінг кожні 5 секунд створює затримку до 5 секунд і безкорисне навантаження. WebSocket — постійне з'єднання, дані приходять по події. Бекенд бота розсилає події: position_opened, position_closed, order_filled, pnl_updated. В офіційній документації Apple URLSessionWebSocketTask підтримується з iOS 13.

Порівняємо підходи:

На iOS реалізація через URLSessionWebSocketTask:

actor BotMonitorConnection {
    private var webSocketTask: URLSessionWebSocketTask?
    private let session = URLSession.shared
    var onEvent: ((BotEvent) -> Void)?

    func connect(botId: String, token: String) {
        let url = URL(string: "wss://api.example.com/bots/\(botId)/stream?token=\(token)")!
        webSocketTask = session.webSocketTask(with: url)
        webSocketTask?.resume()
        startListening()
    }

    private func startListening() {
        webSocketTask?.receive { [weak self] result in
            switch result {
            case .success(let message):
                if case .string(let text) = message,
                   let data = text.data(using: .utf8),
                   let event = try? JSONDecoder().decode(BotEvent.self, from: data) {
                    self?.onEvent?(event)
                }
                self?.startListening()
            case .failure(let error):
                self?.scheduleReconnect()
            }
        }
    }

    private func scheduleReconnect() {
        Task {
            try? await Task.sleep(nanoseconds: 3_000_000_000)
            connect(botId: botId, token: token)
        }
    }
}

Чому exponential backoff критичний для мобільного трейдингу?

Мобільна мережа нестабільна: метро, ліфт, перемикання вишок. Якщо просто намагатися перепідключатися кожну секунду, ви ризикуєте розрядити батарею та заблокувати сокет. Exponential backoff — це коли інтервал перепідключення зростає: 1с, 2с, 4с, 8с... до 30с. Після успішного підключення інтервал скидається. Додатково, після відновлення з'єднання клієнт запитує поточний стан через REST (GET /bots/{id}/state), щоб заповнити пропущені події.

На Flutter з Riverpod зручно винести з'єднання в StreamProvider:

@riverpod
Stream<BotEvent> botEventStream(BotEventStreamRef ref, String botId) {
  final channel = WebSocketChannel.connect(
    Uri.parse('wss://api.example.com/bots/$botId/stream'),
  );
  ref.onDispose(channel.sink.close);
  return channel.stream
      .map((data) => BotEvent.fromJson(jsonDecode(data as String)))
      .handleError((e) => ref.invalidateSelf());
}

Що робити при обриві з'єднання?

Користувач повинен бачити індикатор стану: зелена точка (live), сіра (reconnecting), червона (offline). Це ключовий елемент довіри. Ми реалізуємо покроковий алгоритм:

1. При розриві: очікування 1 секунду, потім спроба підключення.
2. При невдачі: подвоєння таймауту до максимуму 30 секунд.
3. При успішному підключенні: запит поточного стану через REST.
4. Оновлення UI з індикатором.

Які дані відображаються на екрані?

Додаток розділено на три основні зони:

Відкриті позиції. Пара, сторона (Long/Short), розмір, ціна входу, поточна ціна, unrealized PnL у % та USD. PnL оновлюється по кожній події pnl_updated — ми не перемальовуємо весь список, тільки змінений рядок. На Android — DiffUtil в RecyclerView, на Flutter — ListView.builder з ключами.

Стрічка подій. Останні N подій: «Відкрито позицію BTC/USDT long 0.01 BTC @ 67,430», «Ордер виконано», «Стоп-лос спрацював». Усі з часовими мітками.

Метрики сесії. Кількість угод, сумарний реалізований PnL, win rate. Оновлюється при кожному position_closed.

Типи подій детально:

Push-сповіщення для критичних подій

WebSocket — основний канал для активного екрану. Але коли додаток згорнуто, події доставляються через FCM/APNs: стоп-лос спрацював, помилка бота, значне змінення PnL. Push-сповіщення не замінюють real-time, а доповнюють його. Ми налаштовуємо фільтрацію, щоб не спамити: тільки події, позначені бекендом як critical.

Довіра та досвід

Наші інженери мають сертифікати Apple (iOS) та Google (Android). За 5+ років ми реалізували більше 20 проектів для фінансової сфери, включаючи торгові термінали, моніторинг портфелів та ботів. Кожен додаток проходить код-рев'ю, навантажувальне тестування та перевірку на безпеку.

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

• WebSocket-клієнт з exponential backoff перепідключенням
• Індикатор стану з'єднання (live/reconnecting/offline)
• Список відкритих позицій з live PnL (ефективне оновлення)
• Стрічка подій з автоскролом
• REST-синхронізація стану при перепідключенні
• Push через FCM/APNs для фонових алертів
• Документація та інструкція з інтеграції

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

Термін розробки — 5–7 робочих днів. Якщо бекенд вже розсилає WebSocket-події, вистачить 4–5 днів на мобільну частину. Вартість розраховується індивідуально після аналізу вимог та архітектури.

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

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

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