Розробка мобільного додатку для порівняння цін

Компанія має 10+ років досвіду та реалізувала 40+ проєктів у сфері мобільної розробки. Ми спеціалізуємося на розробці iOS Android додатків для порівняння цін.

Користувач стоїть біля полиці супермаркету, сканує штрих-код товару, а наш додаток показує ціну з сусіднього магазину, яка на 30% нижча. Якщо дані застарілі або відсутні — довіра втрачається. Ми будуємо конвеєр даних, який доставляє свіжі ціни із затримкою не більше 5 хвилин. Рішення потребує комбінації партнерських API, парсингу цін та користувацького краудсорсингу.

Чому дані — вузьке місце додатку для порівняння цін

Три джерела даних мають свої особливості та обмеження. Партнерські API магазинів (Яндекс.Маркет, Google Shopping) дають актуальні дані з офіційним SLA, але їх охоплення обмежене афілійованими магазинами. Скрапінг (Playwright/Puppeteer) покриває будь-які магазини, але потребує постійної боротьби з анти-ботами: Cloudflare, CAPTCHA, fingerprinting, rate limiting. Користувацький краудсорсинг (сканування штрих-кодів) — єдине джерело для локальних ринків, але дані потрібно верифікувати: ціна від одного користувача недостовірна, від трьох різних протягом доби — достатньо.

Як працює агрегація цін

Партнерські API — офіційні фіди від великих рітейлерів та агрегаторів. Потребують інтеграції за протоколом, налаштування ключів та обробки rate limits. Скрапери — headless-браузери збирають дані з сайтів без API. Ми використовуємо ротацію User-Agent та IP через proxy-пул, обробляємо динамічний контент. Краудсорсинг — користувачі самі фіксують ціни через сканер штрих-кодів. Система перевіряє достовірність: якщо три користувачі протягом доби вказали одну ціну, вона приймається з точністю 97%.

Як реалізувати сканер штрих-кодів?

На iOS використовуємо AVCaptureSession + AVMetadataObjectTypeEAN13Code, EAN8Code, UPCECode, QRCode. Додаємо haptic feedback через UIImpactFeedbackGenerator — користувач не завжди дивиться на екран. Пошук товарів за штрих-кодом спочатку перевіряє локальний LRU-кеш (останні 100 товарів), потім надсилає API-запит. Кеш останніх 100 товарів прискорює пошук у 5 разів порівняно з повним API-запитом — це критично, коли користувач стоїть біля полиці.

Історія цін

Кожна зміна ціни зберігається як новий рядок у таблиці PriceHistory з полями productId, shopId, price, currency, recordedAt. Графік за 30/90/365 днів будується з цієї таблиці. На мобільному клієнті кешуємо історичну криву в компактному бінарному форматі (MessagePack або Protocol Buffers) — JSON роздуває трафік. MessagePack у 2–3 рази компактніший, що прискорює завантаження на повільних з'єднаннях.

Як налаштувати push-сповіщення про зниження ціни?

Користувач створює PriceAlert з цільовою ціною. Бекенд перевіряє умову newPrice <= targetPrice при кожному оновленні прайсу. Доставка через FCM (Android) або APNs (iOS). Затримка більше 30 хвилин знижує конверсію покупки на 15% — тому ми оптимізуємо pipeline перевірки та відправки. Користувачі заощаджують у середньому 400 грн на місяць завдяки моніторингу цін.

Чи можна уникнути юридичних ризиків скрапінгу?

Так, використання партнерських API та уважне вивчення ToS магазинів знижує ризики. Ми завжди дотримуємося App Store Review Guidelines (Section 5.1) та GDPR.

Типові помилки на старті

• Недооцінка складності парсингу: анти-бот системи змінюються кожні кілька місяців, що збільшує трудозатрати вдвічі.
• Відсутність нормалізації одиниць вимірювання: 1 кг vs 500 г × 2.
• Ігнорування юридичних аспектів скрапінгу (ToS магазину, авторські права). Ми шифруємо всі персональні дані згідно з App Store Review Guidelines (Section 5.1).

Процес роботи та що входить

1. Аналітика та проєктування — визначаємо джерела даних, категорії товарів, регіон, цільову базу магазинів. Створюємо архітектурну документацію.
2. Розробка бекенду — налаштування скрапінг-інфраструктури, інтеграція з API, база даних цін, кешування.
3. Мобільна розробка — екрани пошуку, картки товару, фільтри, історія цін, сповіщення, офлайн-кеш.
4. Тестування — навантажувальне тестування парсингу (до 1000 запитів за хвилину), юзабіліті-тести, перевірка на реальних пристроях.
5. Деплой та підтримка — публікація в App Store та Google Play, налаштування моніторингу, навчання команди замовника.

До роботи входить: повна архітектурна документація, налаштовані pipelines збору даних, доступ до репозиторію, навчання вашої команди, гарантійна підтримка 3 місяці. Типовий бюджет на MVP стартує від $15,000. Для повного продукту з кошиковим порівнянням та списком бажань — індивідуально.

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

Орієнтири за термінами

Мобільний додаток (без бекенду) з пошуком, картками, історією цін з готового API — 4–7 тижнів. Повний продукт із власним бекендом збору цін, алертами та кошиковим порівнянням — 14–22 тижні. Вартість розраховується індивідуально.

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

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