Розробка мобільного додатку для моніторингу блокчейн-транзакцій

Уявіть: OTC-трейдеру потрібно миттєво дізнатися про вхідний USDT на $100k, інакше угода піде конкуренту. Десятки гаманців, сотні транзакцій на день — ручна перевірка блок-експлорера неможлива. Ми розробляємо мобільні додатки, які вирішують це завдання: підписуються на ончейн-події через WebSocket, фільтрують за сумою та типом, і надсилають push за 1-2 секунди. Така система економить години ручної роботи та знижує ризик пропуску великої угоди.

За п'ять років ми реалізували понад 15 проектів для DeFi-протоколів та криптофондів, включаючи рішення для моніторингу стейблкоїнів з фільтрацією за порогами. Кожен додаток проходить навантажувальне тестування на 1000+ сповіщень за хвилину та аудит безпеки. Результат — стабільна робота під високим навантаженням та гарантована доставка сповіщень.

Як влаштований моніторинг транзакцій?

Є чотири основні підходи, і вибір залежить від вимог до швидкості, навантаження та складності.

WebSocket через Infura забезпечує затримку 1-2 секунди, що в 30 разів швидше за HTTP polling. Для мобільного додатку з push-сповіщеннями оптимальний третій варіант: Alchemy Notify → бекенд webhook → FCM/APNs → телефон.

Чому фільтрація транзакцій критична?

Сповіщення при кожній транзакції — це занадто багато для активних адрес (whale-гаманці роблять сотні транзакцій на день). Потрібні фільтри:

• Мінімальна сума (наприклад, сповіщати тільки при > $500)
• Тип події (тільки incoming, або тільки DEX swap)
• Тихі години: з 23:00 до 08:00 — батчити сповіщення, показати одним зведеним push вранці

На iOS кастомізація сповіщень через UNNotificationContent з UNNotificationServiceExtension — можна збагатити push даними перед показом. На Android — NotificationCompat.Builder з InboxStyle для батчингу. Така фільтрація дозволяє суттєво економити трафік та енергію батареї, а також зменшити навантаження на сервер.

Підтримувані блокчейни

Різні ланцюжки — різні RPC, різні формати адрес, різні стандарти токенів. Ethereum та EVM-сумісні (Polygon, BSC, Arbitrum, Base) — один адаптер з різним RPC URL та chain ID. Solana — окремий SDK, адреси base58, токени через SPL.

Для кожної ланцюжка — окремий адаптер:

interface ChainMonitor {
    val chainId: Int
    suspend fun subscribeToAddress(address: String, listener: TxEventListener)
    suspend fun unsubscribe(address: String)
    suspend fun getRecentTransactions(address: String, limit: Int): List<Transaction>
}

class EthereumMonitor(private val alchemyWsUrl: String) : ChainMonitor {
    override val chainId = 1
    // ...
}

class SolanaMonitor(private val heliusApiKey: String) : ChainMonitor {
    override val chainId = 101 // Solana mainnet
    // ...
}

Порівняння RPC-провайдерів для push-сповіщень

Для мобільного додатку з push ми рекомендуємо використовувати Alchemy або QuickNode через низьку затримку та вбудовану підтримку webhook. Вибір провайдера впливає на бюджет: Alchemy та QuickNode дорожчі за Infura, але забезпечують меншу затримку та вбудовані webhooks, що економить час розробки.

Архітектура додатку

Головний екран — хронологічна стрічка всіх відстежуваних подій. Фільтри: за ланцюжком, за адресою, за типом події. Пошук за tx hash. Тап — детальна картка з посиланням на блок-експлорер. Дані завантажуються з власного бекенду, який зберігає історію подій (тому що блокчейн не дає зручного «дай мені події цієї адреси за місяць» без архівної ноди). Пагінація cursor-based.

struct FilterConfig: Codable {
    var minAmountUSD: Double
    var eventTypes: [EventType]
    var quietHoursStart: Date?
    var quietHoursEnd: Date?
}

enum EventType: String, Codable {
    case incoming, outgoing, swap, contractInteraction
}

Процес налаштування моніторингу

• Збір вимог — визначаємо ланцюжки, адреси, фільтри та сценарії сповіщень.
• Вибір RPC-провайдера — Alchemy, QuickNode або Infura з урахуванням бюджету та навантаження.
• Розробка адаптерів — створюємо модулі для кожної ланцюжка з підтримкою WebSocket та webhook.
• Конфігурація фільтрів — налаштовуємо пороги, тихі години та батчинг.
• Інтеграція з бекендом — бекенд отримує події, зберігає їх та надсилає push через FCM/APNs.
• Тестування під навантаженням — симулюємо 1000 транзакцій за хвилину, перевіряємо стабільність.
• Деплой та моніторинг — розгортаємо на продакшн та відстежуємо метрики.

Що входить в роботу під ключ

• Мультичейн архітектура (EVM + Solana опціонально)
• Управління списком відстежуваних адрес та контрактів
• Стрічка подій з фільтрами та пошуком
• Push-сповіщення з фільтрами за сумою та типом, тихі години
• Детальна картка транзакції з посиланням на блок-експлорер
• Offline-режим з кешуванням останніх подій
• Інтеграція з Alchemy Notify, QuickNode, Moralis (за вибором)

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

Терміни — 7–12 робочих днів залежно від кількості підтримуваних ланцюжків та глибини інтеграції. Вартість розраховується індивідуально після аналізу вимог. В середньому окупність проекту становить 2-3 місяці за рахунок зниження витрат на ручний моніторинг та зменшення простоїв. Зв'яжіться з нами для попередньої оцінки — ми підготуємо архітектуру та оптимізуємо бюджет під ваш стек. Замовте консультацію, щоб обговорити деталі.

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

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