Як пришвидшити публікацію оголошення до 2 хвилин?
Користувач заходить на дошку оголошень, хоче продати диван. Відкриває застосунок — і бачить порожню форму з десятком полів. Фотографії завантажуються по одній, кнопка «Опублікувати» неактивна 30 секунд. Він закриває застосунок і йде до конкурентів. За даними Statista, 70% користувачів покидають застосунок, якщо публікація триває понад 3 хвилини. Наш досвід — понад 8 років у мобільній розробці, 12+ запущених маркетплейсів. У цій статті розберемо, як уникнути таких сценаріїв і побудувати застосунок, який конвертує. Одного разу ми переписали форму публікації для великого класифайду: після впровадження динамічної форми та паралельного завантаження фотографій конверсія у публікацію зросла на 40%. Отримайте консультацію — оцінимо ваш проект.
Публікація оголошення: мінімум тертя
Форма оголошення — категорія → заповнення полів → фото → ціна → публікація. Поля залежать від категорії (для авто — VIN, пробіг, рік; для нерухомості — площа, поверх, тип угоди). Динамічна форма: при зміні категорії поля перемальовуються. JSON Schema від сервера → генерація форми на клієнті (позбавляє від хардкоду полів у коді).
Завантаження фото — найвужче місце. Користувач хоче завантажити 10 фото. Порівняємо підходи:
| Підхід | Час завантаження 10 фото (5 MB each) | Навантаження на мережу | UX |
|---|---|---|---|
| Послідовне | ~50 сек | Низьке | Поганий: чекати |
| Паралельне (10 потоків) | ~8 сек | Високе | Середній: може впасти |
| Оптимальне (3 потоки + компресія) | ~12 сек | Помірне | Відмінний: прогрес-бари |
Компресія перед завантаженням: UIImage.jpegData(compressionQuality: 0.8) або Bitmap.compress(Bitmap.CompressFormat.JPEG, 80, stream). Фото з камери сучасного смартфона — 8–15 MB у RAW. Після компресії — 1–2 MB. Для оголошення достатньо, трафік економиться в 5–10 разів. 90% оголошень з фотографіями приваблюють на 60% більше переглядів.
Визначення геолокації оголошення
Місцезнаходження оголошення — або поточні координати, або вибір на карті, або введення адреси з геокодуванням. Для продажу речей зазвичай достатньо району/міста без точної адреси — це важливо для безпеки продавця. Точні координати потрібні для нерухомості та авто.
Чому пошук по карті — must-have для класифайду?
Користувачі хочуть бачити оголошення поруч із домом. Пошук по карті — ключовий сценарій для нерухомості, авто та послуг. 50% користувачів активно використовують карту для пошуку. Як це працює: користувач рухає карту, оголошення оновлюються по видимій області. onCameraIdle (Google Maps) / onMapIdle (Mapbox) → запит з bbox поточного viewport. Маркери на карті, tap — картка оголошення. Для нерухомості важлива кластеризація: в одному будинку 50 оголошень. Кластер показує кількість, при zoom-in розкривається в окремі маркери або список.
Повнотекстовий пошук та фільтрація
Для пошуку використовуємо Elasticsearch або Typesense. Typesense швидший в індексації та простіший у конфігурації, але Elasticsearch гнучкіший для складних запитів. Клієнт відправляє запит, дебаунс 300 мс на полі введення. Пошук з урахуванням морфології (українська мова — «машина» знаходить «машини», «машиною») — через Elasticsearch з ukrainian analyzer або Typesense з Ukrainian stemmer. Фільтри ціни — range slider. RangeSlider у Material 3 (Android) / кастомний GeometryReader-based range slider (SwiftUI або бібліотека RangeSeekSlider). Значення debounce перед запитом.
Як налаштувати чат продавця та покупця?
Чат без обміну номерами телефону — ключова фіча довіри. Firebase Realtime Database або Supabase Realtime — швидкий спосіб запустити чат з real-time повідомленнями. Для серйозного масштабу — власний WebSocket-сервер або Stream Chat SDK. Порівняємо рішення:
| Рішення | Витрати на старті | Масштабованість | Час впровадження |
|---|---|---|---|
| Firebase | Низькі (pay-as-you-go) | Обмежена (до ~1M msg/day) | Дні |
| Supabase | Низькі | Хороша (до ~10M msg/day) | Дні |
| WebSocket сервер | Середні (оренда VPS) | Висока (будь-яке навантаження) | Тижні |
| Stream Chat SDK | Високі (підписка) | Дуже висока | Дні |
Структура повідомлень: { id, conversation_id, sender_id, text, image_url, timestamp, read_at }. read_at для статусу прочитання. Push-сповіщення при новому повідомленні — FCM/APNs data push з conversation_id в payload для deep link у конкретний чат.
Фото в чаті — користувач відправляє фото. Стиснення до 800–1200px, upload в S3/Cloudflare R2, повідомлення містить URL. При відображенні — lazy loading з progressive placeholder. Антиспам: обмеження швидкості повідомлень (rate limiting на сервері), блокування користувача.
Модерація оголошень
На стороні клієнта: попередження при введенні телефону/пошти в тексті оголошення (обхід контактів через платформу). Кнопка «Поскаржитися» на кожному оголошенні — попап з причиною скарги, відправка на сервер. Автоматична модерація фото: Google Cloud Vision API SafeSearch — перевірка на explicit контент. Інтегрується в upload pipeline на сервері, клієнт просто отримує статус оголошення (pending_moderation / approved / rejected).
Монетизація та просування
«Підняти оголошення», «VIP-статус», «виділити» — класичні платні опції. In-app purchase через StoreKit 2 / Google Play Billing або одноразова оплата через Stripe. Правильно налаштована монетизація окупає витрати на розробку. Зверніться до нас для розрахунку монетизаційної моделі.
Що входить в роботу
- Архітектура та проєктування бази даних (категорії, схеми, індекси)
- Розробка мобільного застосунку (iOS/Android/Flutter)
- Інтеграція пошукового двигуна (Elasticsearch/Typesense)
- Реалізація чату та push-сповіщень
- Модерація контенту (автоматична + ручна)
- Налаштування CI/CD для публікації в App Store та Google Play
- Доступ до вихідного коду та документація
- Навчання команди замовника
- Підтримка 2 тижні після релізу
Процес роботи
- Аналітика — вивчаємо конкурентів, збираємо вимоги, визначаємо MVP.
- Проєктування — створюємо архітектуру, JSON Schema категорій, прототип форм.
- Реалізація — ітеративна розробка: публікація → пошук → карта → чат → модерація → монетизація.
- Тестування — навантажувальне тестування (до 10000 оголошень на хвилину), UI-тести, регрес.
- Деплой — публікація в сторах, налаштування моніторингу, передача проекту.
Строки та вартість
Орієнтовний термін розробки — від 14 до 24 тижнів. Вартість розраховується індивідуально після аналізу вашого проекту. Ми гарантуємо стабільність під навантаженням та відповідність App Store Review Guidelines. Наша команда — досвідчені Flutter-розробники з багаторічним стажем. Зв'яжіться з нами — отримайте консультацію та попередню оцінку вашого проекту.