Розробка мобільного додатку для обліку фінансів (Personal Finance)

Ми створюємо мобільні додатки для обліку фінансів, які вирішують проблеми банківської інтеграції, категоризації транзакцій та мультивалютності. Клієнт очікує, що фінансовий трекер буде автоматично розпізнавати категорії витрат. Банк надав API, але транзакції приходять у різних форматах, а одна помилка в зберіганні сум призводить до розбіжностей у звітах. Наша команда — 8 інженерів з досвідом роботи у фінансових мобільних додатках. Ми реалізували 15+ проектів, включаючи рішення з Open Banking, ML-категоризацією та синхронізацією через iCloud/Google Drive. Ми гарантуємо, що ваш додаток пройде рев'ю App Store та Google Play з першого разу. Наш мобільний додаток для обліку фінансів забезпечує повний контроль над доходами та витратами.

Чому мобільний додаток для обліку фінансів потребує глибокої експертизи?

Чому банківська інтеграція — найскладніша частина?

Використовуємо три підходи:

• Open Banking / PSD2 (Європа). Стандартизовані API: Nordigen (GoCardless), Salt Edge, TrueLayer. Авторизація через OAuth2 з redirect назад через Deep Link (ASWebAuthenticationSession на iOS, Custom Tabs на Android). Транзакції приходять у JSON, але кожен банк інтерпретує поля по-своєму: сума може бути рядком або числом, pending-транзакції дублюються. Нам доводиться писати адаптери під кожен банк. Економія від використання Open Banking замість парсингу може сягати $10,000 на інтеграцію.

• Імпорт виписок (CSV/OFX/MT940). Якщо у банку немає API — парсимо виписки. MT940 — формат, який кожен банк реалізує по-своєму. Для OFX використовуємо готові бібліотеки, для CSV — конфігурований парсер з маппінгом колонок. Цей підхід економить до 30% бюджету порівняно з Open Banking.

• Ручне введення. Основа будь-якого додатку. Швидке введення через віджет на екрані блокування (WidgetKit з intent на iOS 16+) або Dynamic Island на iPhone 14 Pro. Введення через віджет у 2 рази швидше, ніж запуск додатку. Користувач не повинен відкривати додаток, щоб записати витрату.

ML-категоризація для обліку фінансів

On-device ML — наш вибір. CoreML на iOS, TensorFlow Lite на Android. Навчаємо кастомну модель на розмічених транзакціях: на вході creditorName та transactionAmount, на виході категорія. Наш CoreML-класифікатор працює у 3 рази швидше за хмарні аналоги та не потребує інтернету. Якщо впевненість нижча за 0.7 — підключаємо rules-engine та пропонуємо користувачу підтвердити категорію. ML-категоризація у 5 разів швидша за ручне визначення категорій. Так ми донавчаємо модель без збору даних на сервер.

Мультивалютність для обліку фінансів

Зберігаємо суми в minor units (цілі числа), щоб уникнути втрати точності при накопиченні транзакцій. Курси валют кешуємо з ExchangeRates API або Fixer.io, оновлюємо раз на день. Для звітів конвертуємо за курсом на дату транзакції, а не на поточний момент.

Безпека: що під капотом

Транзакції шифруються в базі через SQLCipher (React Native / Flutter) або NSFileProtection.completeUnlessOpen (iOS). Біометричне блокування — через LocalAuthentication / BiometricPrompt. Токени банківських API зберігаються в Keychain (iOS) / Android Keystore. Для зберігання токенів використовуємо Keychain з атрибутом kSecAttrAccessibleWhenUnlockedThisDeviceOnly та додатковим шифруванням AES-256. Для синхронізації даних застосовуємо CRDT (Conflict-free Replicated Data Types). Жодних UserDefaults або SharedPreferences. Стандарт Open Banking описано в PSD2 Directive. Для забезпечення консистентності даних застосовуємо ACID транзакції та optimistic concurrency control. Використовуємо протокол OAuth2 з PKCE та доказом володіння ключем.

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

• Аудит вимог і вибір стеку (iOS/Android/Flutter/React Native).
• Проектування accounting model (подвійний запис або спрощена).
• Розробка та тестування на sandbox-акаунтах банків.
• Інтеграція push-сповіщень (APNs/FCM) та deep linking (Universal Links/App Links).
• In-app purchases (StoreKit 2 / Billing 6) для преміум-функцій.
• Публікація в App Store Connect та Google Play Console, включаючи налаштування TestFlight.
• Документація та навчання вашої команди.

Як ми проводимо інтеграцію з банком: покроково

1. Аналіз документації API банку.
2. Розробка адаптера на Swift або Kotlin.
3. Тестування на sandbox-акаунтах.
4. Валідація на продуктивному середовищі.
5. Моніторинг і підтримка.

Процес роботи

Починаємо з аудиту: які банки, цільові країни, чи потрібна мультивалюта, модель монетизації. Проектуємо схему даних, розробляємо, тестуємо на реальних банківських акаунтах у sandbox-режимі, потім на продуктивних. Після публікації — підтримка та доопрацювання. Ми пропонуємо розробку під ключ, включаючи підтримку після запуску.

Вартість і терміни

Вартість розраховується індивідуально після аналізу вимог. Орієнтовні терміни: базова версія — 5–8 тижнів, повний функціонал — 16–24 тижні. Базова версія коштує від $15,000, повний функціонал — від $50,000. Пишіть нам, і ми оцінимо ваш проект за 1 день. Пропонуємо розробку під ключ, включаючи підтримку після запуску.

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

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