Разработка мобильного приложения для виртуальной выставки

Виртуальная выставка: приложение теряет посетителей на входе

Посетитель открывает приложение виртуальной выставки ровно в тот момент, когда стартует экспозиция. Первый экран должен появиться за пару секунд, а вместо этого крутится заставка: каталог стендов, расписание и карточки экспонентов тянутся с сервера единым блоком, пока грузится всё — от обложек до списка докладов. Отток посетителей на входе здесь самый дорогой из возможных: тот, кто не досмотрел заставку, не дойдёт ни до одного стенда и не оставит ни одного контакта.

Вторая потеря тише и потому опаснее. Гость всё-таки попал внутрь, но карточки стендов пустые, изображения не подгрузились, а трансляция со стенда обрывается на середине фразы. Медленная загрузка стенда читается как неработающий экспонент: посетитель решает, что стенд пустой, и уходит к соседнему. Вернуть это внимание повторным открытием приложения уже почти невозможно — второй визит случается редко.

Пиковая нагрузка на выставке не абстракция: аудитория приходит волнами — залп в первые минуты после открытия, затем всплески на ключевых докладах и розыгрышах. Решение, рассчитанное на средний поток, ломается именно в эти минуты, и платит за простой не площадка, а экспонент, который ждал посетителей на своём стенде.

Разбираем, как это закрывается: где в приложении для выставки ставятся границы отказа, что подгружается заранее и как вход перестаёт зависеть от пика.

Навигация по стендам, расписание и сбор контактов

Первый экран решает, дойдёт ли посетитель до экспонента вообще. Карту выставочного зала мы выносим наверх и строим на базе Mapbox: векторный слой с поиском по номеру стенда, маршрут от входа, отметка «я здесь». Схему кешируем при первом запуске — навигация по стендам работает в зале, где сеть перегружена или пропадает. Время до первого стенда падает с минут блуждания по указателям до 30–60 секунд.

Расписание мероприятий в приложении — не копия программы на сайте, а персональный план. Участник отмечает тематики, приложение собирает подборку, ставит локальные напоминания и перестраивает маршрут с запасом на переход между сессиями. Программа обновляется фоновой синхронизацией: сменился спикер — бейдж на экране уже верный.

Сбор контактов посетителей закрывается одним касанием: код на стенде, подтверждение согласия, обмен визитками в обе стороны. Записи ложатся в локальное хранилище и уходят в корпоративную базу контактов пачками при появлении сети — экспонент получает список с пометкой, где и когда состоялся разговор, а не стопку бумажек.

Пик входов — главный риск: зал открылся, сотни людей одновременно открывают карту и расписание. Горячие данные отдаём из кеша, а отметки и заявки складываем в очередь и отправляем по мере освобождения канала. Приложение остаётся отзывчивым, и доля дошедших до экспонента не проседает в первые минуты.

Режимы работы: офлайн-карта, гибрид, веб-версия

Выбор между офлайн-картой, гибридным режимом и веб-версией — не вкусовой. Он определяется площадкой, устойчивостью связи и тем, как часто меняется программа в дни события. В павильоне с толстыми стенами и перегруженной точкой доступа сеть отваливается именно в час пик, а на открытой городской площадке посетитель скорее откроет ссылку, чем поставит приложение.

Картографическую подложку для автономного слоя собираем из открытых данных OpenStreetMap и нарезаем на фрагменты заранее — приложение не обращается в сеть за картой и работает в авиарежиме. Дальше остаётся выбрать из трёх вариантов, и у каждого есть своя цена в поддержке и сценарии, которые он не закрывает.

На практике чаще выигрывает гибрид, но только если заранее назначен источник правды для расписания и схемы залов. Без этого автономный слой и сервер расходятся, и посетитель видит отменённое мероприятие на своём экране.

Этапы внедрения: от аудита экспозиции до передачи

Работы идут волнами, и каждая заканчивается артефактом, который можно проверить до старта следующей. Порядок не случаен: пока не ясно, что именно показывает экспозиция и как часто это меняется, приложение превращается в набор статичных экранов, которые к открытию уже устарели.

1. Аудит выставочного контента. Инвентаризация стендов, медиа, расписания, карт залов и связей с системой регистрации. Результат — карта разделов и таблица источников данных с частотой обновления.
2. Схема и прототип потоков. Определяем, что обновляется через админку без пересборки, что кэшируется на устройстве, как ведёт себя экран при обрыве связи в павильоне. Результат — согласованная архитектура и кликабельный прототип ключевых сценариев.
3. Сборка ядра. Навигация по залам, расписание, уведомления, вход по билету или приглашению, аналитика посещений. Результат — работающая сборка на тестовом контуре, а не макет.
4. Нагрузочная проверка приложения. Прогон на сценарии одновременного входа посетителей в момент открытия, проверка деградации при слабой сети и поведения при недоступном сервисе. Результат — отчёт с узкими местами и исправлениями до публичного запуска.
5. Пилот на реальном трафике. Закрытый прогон на группе посетителей: смотрим время до первого экрана, долю успешных входов и число сбоев. Результат — правки по факту поведения, а не по предположениям.
6. Внедрение приложения выставки. Публикация в магазинах приложений, прохождение проверок, подготовка дежурства инженеров на дни мероприятия.
7. Передача проекта заказчику. Репозиторий, доступы, регламент обновления контента и инструкция по выпуску новой версии силами вашей команды — без нашей постоянной поддержки.

Критерий приёмки каждого этапа фиксируем заранее: этап не считается закрытым, пока артефакт не принят. Это убирает ситуацию, когда к открытию выясняется, что расписание в приложении не совпадает с площадкой.

Конфигурации, схемы и регламенты на выходе

Комплект передачи — это не архив с исходным кодом, а набор документов и настроек, по которому сторонняя команда разворачивает стенд, выпускает обновление и меняет контент без нас. Мы собираем его параллельно с разработкой: если схема интеграций восстанавливается только по памяти инженера, проект не считается сданным.

• Конфигурации окружений. Адреса сервисов, ключи доступа и параметры сборки вынесены из кода в отдельные файлы — тестовый и промышленный контур переключаются сменой конфигурации, а не правкой исходников.
• Схема интеграций выставки. Направление и формат обмена с системой регистрации и продажи билетов, внешней CRM, плеером трансляций и аналитикой; отдельно — поведение при недоступности каждого сервиса.
• Права доступа к данным посетителей. Матрица ролей: организатор видит агрегированную статистику, стендист — только своих гостей, выгрузка персональных данных — отдельная роль с журналом операций и сроком хранения.
• Регламент обновления контента. Что меняется через админ-панель без выпуска новой версии приложения (расписание, стенды, видео, презентации), а что требует пересборки и проверки на тестовом контуре.
• Документация по приложению. Описание архитектуры и хранилища, спецификация внутреннего программного интерфейса, инструкции по сборке, подписи и публикации в магазинах приложений.
• Регламент выпуска и откат. Порядок работы с ветками, обязательные проверки на критичных путях, приёмка и возврат к предыдущей стабильной сборке.
• Передача проекта и поддержка. Владение аккаунтами разработчика и сервисов переоформляется на заказчика, фиксируется гарантийное окно и условия дальнейшего сопровождения.

После передачи вы можете развивать приложение своей командой или вернуться к нам на поддержку — доступы и знания остаются у вас.

Кейс: экспозиция на несколько залов и пиковые входы

Что было на входе

Оператор выставочной площадки Экспофорум пришёл с классической болью: посетитель скачивал приложение заранее, а на месте терялся между залами. Билет, схема и список участников жили в разных разделах, поэтому до нужного стенда доходила примерно половина тех, кто открыл карту.

Замеры прошлого мероприятия дали базу для сравнения: доходимость — 52%, обращения в поддержку — около сотни за день, в основном «где я и как пройти».

Что изменили

Пересобрали путь посетителя: вход по коду прямо с экрана блокировки, карта с привязкой к маякам в залах, маршрут строится от текущей точки до выбранного стенда. Стенд отмечается одним касанием — отметка сразу идёт в статистику организатора, а посетителю показываются соседние экспозиции по теме.

Нагрузку на поддержку сняли подсказками в интерфейсе: расписание, входы, гардероб, переходы между павильонами. На смене осталось два оператора вместо восьми, и они занимались сложными случаями, а не навигацией.

Что стало

Время от входа до первого стенда сократилось вдвое, доходимость выросла с 52% до 79% — почти каждый, кто открыл карту, дошёл до экспонента. Обращения в поддержку упали примерно в пять раз, доля вопросов про навигацию — с большинства до единичных.

Кейс мобильного приложения выставки дал ещё один результат: метрики до и после считаются по одному событию — сканированию на стенде. Организатор сравнивает мероприятия между собой и видит, где именно теряется посетитель.

Что делать, если приложение уже выпущено, а экспозиция меняется

Если приложение уже установлено у посетителей, а экспозиция меняется, перевыпуск сборки — худший из доступных путей. Магазины проверяют релиз, часть гостей обновится через недели, часть не обновится вообще, и на площадке рядом окажутся люди с разными версиями. Для выставки, которая живёт несколько дней, это означает разъехавшуюся навигацию и потерянные стенды.

Рабочее решение — вынести описание экспозиции из сборки на сервер. Приложение при запуске запрашивает конфигурацию: список залов, схему проходов, точки интереса, расписание сессий и привязку контента к стендам. Пока модель данных описана версионно и клиент умеет читать как текущую, так и предыдущую схему, добавление зала или перенос времени доклада не требуют новой сборки.

Отдельная задача — миграция на новую структуру залов, когда площадка меняет планировку. Старым идентификаторам сопоставляются новые, навигация получает правила перехода, а избранное, маршрут и прогресс по квестам переносятся на актуальные точки. Гость не замечает смены схемы: он открывает приложение и видит тот же маршрут, просто по новым залам.

Обновление экспозиции без перевыпуска опирается на управление контентом выставки: организатор сам правит стенды, спикеров и тайминг, а правила кэширования определяют, когда клиент забирает свежие данные, а когда работает с сохранённой копией — на площадке связь часто нестабильна. Доработка существующего приложения нужна, только если появляется новый тип контента или нативный модуль: тогда релиз неизбежен, но выкатывается постепенно, с флагами и мониторингом падений.

Разбор начинается с аудита текущей сборки: что уже параметризовано, а что зашито в код. Дальше планируем изменения так, чтобы установленные версии продолжали работать.

Ограничения: слабая связь, старые устройства, офлайн

Павильоны с бетонными стенами и перегруженным эфиром — обычное дело: гость подходит к стенду, а сеть не отдаёт даже страницу. Поэтому логика строится от офлайн-сценария: каталог участников, карта и материалы стендов лежат в локальном хранилище, а действия посетителя встают в очередь и уходят на сервер, как только канал вернулся. Гость не замечает подмены, регистрации и контакты не теряются при обрыве.

Нижнюю границу по устройствам фиксируем до разработки: версия системы, объём памяти, возраст аппаратов из реального парка посетителей, а не только из новых флагманов. Тяжёлые трёхмерные сцены на слабом железе подменяются статичными панорамами — приложение не падает, а подстраивает подачу под возможности аппарата.

Данные посетителей собираем по минимуму — только нужное для регистрации и передачи контакта участнику. Токены доступа лежат в защищённом хранилище системы, передача идёт по шифрованному каналу, на устройстве остаётся обезличенный кэш.

Приложение заработает на устройствах, которым несколько лет?

Да, если аппарат проходит нижнюю границу, зафиксированную на старте. Для слабых конфигураций заранее заданы облегчённые режимы отображения стендов.

Как защищены данные посетителей?

Собираем минимум полей, шифруем передачу, разграничиваем доступ сотрудников по ролям. По запросу заказчика данные удаляются вместе с выставкой.

Обсудим задачу: соберём план и оценку по вашей экспозиции

Чтобы оценка сроков разработки опиралась на факты, а не на догадки, нам нужен минимум входных данных — обычно хватает одного разговора и доступа к материалам. Ниже список того, что ускоряет расчёт сильнее всего.

• Карта экспозиции: план залов и стендов, точки интереса, логика переходов между ними — в векторах, таблице или даже наброске от руки.
• Контент: описания экспонентов, медиа, ссылки на трансляции, требования к языкам и расписанию событий.
• Сценарий посетителя: как человек попадает в приложение, что считаем целевым действием — просмотр стенда, заявка, личная встреча.
• Интеграции: система регистрации, каталог участников, учёт заявок — с доступом к тестовому контуру и примерами ответов.
• Платформы и условия: приоритетные устройства, нужен ли офлайн-режим для павильонов со слабым сигналом, требования к входу.
• Доступы и согласования: учётные записи для сборки и публикации, кто утверждает макеты, правила работы с персональными данными.
• Ограничения: дата открытия выставки и события программы, которые нельзя сдвинуть.

На этом основании мы возвращаемся с планом работ по приложению выставки: этапы, их длительность, состав команды и точки приёмки на каждом шаге. Если план подходит, обсуждаем разработку приложения и запускаем старт проекта выставки — опишите задачу, и мы вернёмся с оценкой и предложенным порядком действий.