Цифровые продукты ·
Приложение магазина начинается со второй покупки
Мобильное приложение для интернет-магазина выглядит естественным продолжением сайта. Но установка — отдельная просьба к покупателю, а разработка создаёт постоянную работу для команды. Решение оправдано, когда приложение делает возвращение и повторную покупку заметно удобнее, а не просто показывает тот же каталог в другой рамке.
Не путайте первый заказ с привычкой возвращаться
Человек, который впервые нашёл товар в поиске, вероятнее откроет ссылку в браузере, чем установит приложение до знакомства с магазином. Для него важны ассортимент, наличие, условия доставки и понятная оплата. Если этот путь не работает на мобильном сайте, перенос его в приложение не решит проблему.
Приложение приобретает смысл, когда покупатель уже знает магазин и выполняет повторяющиеся действия: докупает расходники, следит за заказом, использует персональные условия, собирает список привычных товаров или программу лояльности. Не каждому магазину нужны все эти функции. Начните с одного возвращающегося сценария и посчитайте, сколько клиентов в нём действительно участвует.
Выберите задачу, которую мобильный сайт решает хуже
Сохранённая корзина и история заказов могут работать в адаптивном сайте. Иногда этого достаточно. Приложение может дать более удобный быстрый вход, устойчивый доступ к персональным функциям и отдельный канал уведомлений — но только если клиент согласился на них и сообщения остаются полезными. Само наличие push не создаёт лояльность.
Сравните три варианта на одном сценарии: улучшенный мобильный сайт, устанавливаемое веб-приложение и нативное приложение. Учитывайте не только стоимость первой разработки, но и обновления, поддержку, проверку двух платформ, аналитику и работу с обращениями. Разница должна быть видна покупателю, а не только команде проекта.
Каталог и заказ должны оставаться едиными
Новый экран не должен означать вторую независимую систему товаров. Цены, остатки, акции, способы доставки и состояния заказа должны иметь определённый источник. Покупатель может начать на сайте, а вернуться в приложении; оба канала должны одинаково понимать его корзину, оплату и историю. Если данные расходятся, приложение увеличит объём поддержки вместо удобства.
Продумайте исключения до дизайна: товар закончился между добавлением и оплатой, цена изменилась, заказ частично доставлен, возврат оформлен через поддержку. Для каждого события назовите источник статуса и сообщение покупателю. Отдельно определите, какие сведения о клиенте действительно нужны приложению и кто имеет к ним доступ.
Экономику проверяют на поведении, а не установках
Число скачиваний удобно показывать в отчёте, но оно не отвечает на вопрос о пользе. Сравните завершённые повторные заказы, частоту возврата, долю активных покупателей, обращения в поддержку и стоимость поддержания канала. Учитывайте, что в приложение чаще переходят уже лояльные люди: их покупки нельзя автоматически приписать новому интерфейсу.
До крупной разработки можно проверить узкий сценарий в существующем сайте и кабинете: например, быстрый повтор заказа и понятный статус доставки. Если он востребован и ограничения браузера действительно мешают, у команды появится основание для приложения и первый список требований, выведенный из поведения.
Решение о разработке
Составьте короткую карту: кто вернётся, зачем, как часто, что мешает сейчас и что именно приложение изменит. Добавьте источник данных, маршрут ошибки и человека, который будет отвечать за обновления. Если ответа на эти вопросы нет, сначала улучшайте мобильную покупку на сайте. Если есть устойчивый повторный сценарий, можно проектировать приложение вокруг него, не дублируя весь магазин в первой версии.
Я могу помочь оценить этот переход и спроектировать [разработку приложения](/dialogue) от одного доказанного действия покупателя. Для общего выбора носителя полезна статья [«Сайт или мобильное приложение»](/apocrypha/website-or-mobile-app), а для проверки устанавливаемого веб-варианта — [материал о PWA](/apocrypha/pwa-for-business).
От сценария к приложению
Если вам нужно приложение, разберём ключевой сценарий, роли, первую версию и ограничения до начала разработки.