Многие руководители при запуске проекта упираются в один и тот же вопрос: делать магазин как сайт или как мини-программу?
Спросишь несколько подрядчиков — и мнения разные. Одни говорят, что мини-программы — это тренд, а сайт не нужен; другие — что сайт это основа, а мини-программа лишь дополнение. Звучит убедительно и то, и другое, но бюджет только один.
На самом деле сам вопрос поставлен неверно. Разработка сайта интернет-магазина и мини-программа магазина — это не отношения замещения, а отношения разделения ролей. Ключ в том, чтобы сначала понять, что берёт на себя каждая сторона, а затем обсуждать, как они взаимодействуют.
Сначала определите роли: кто отвечает за сделку, кто — за приём трафика
Типичное разумное разделение выглядит так:
Мини-программа магазина отвечает за частые повторные покупки и конверсию в приватном трафике. Пользователь приходит из официального аккаунта, из сообщества, по офлайн-QR-коду — путь короткий, оплата удобная, хорошо подходит для действий с членством, купонами, групповыми покупками.
Корпоративный сайт отвечает за доверие к бренду и приём поискового трафика. Пользователь приходит по названию бренда или по категорийным запросам и должен увидеть, кто компания, какие у неё квалификации, как обеспечивается послепродажная поддержка. То, что на этом этапе не происходит сделки, — нормально; его задача — выстроить доверие.
Конкретный сценарий: компания по товарам для дома при редизайне сайта разместила карточки товаров, описание компании и политику послепродажного обслуживания на сайте, а на каждой странице товара — QR-код мини-программы. Пользователь приходит из Baidu, сначала смотрит сайт, убеждается в надёжности и затем сканирует код, чтобы оформить заказ в мини-программе. Этот путь стабильнее по конверсии, чем просто реклама.
Предупреждение: не делайте обе стороны «большими и всеобъемлющими». Сайт забит корзиной, мини-программа — описанием компании, в итоге обе стороны — полуфабрикаты, а затраты на поддержку удваиваются.
Данные должны быть объединены, иначе это два разных магазина
Это самое проблемное место.
Многие команды действуют так: у сайта одна админка, у мини-программы другая, товары загружаются дважды, заказы просматриваются дважды. Через три месяца после запуска выясняется: остатки не сходятся, бонусы участников не универсальны, поддержке нужно открывать два окна.
Правильный подход — использовать единую платформу товаров и заказов. Разработка сайта и разработка мини-программы на уровне интерфейсов обращаются к одному набору данных: товары, остатки, цены, участники, заказы — единственный источник. Фронтендов может быть два, бэкенд должен быть один.
На практике обычно есть три способа:
- Собственный API-шлюз, обе стороны вызывают один набор интерфейсов — максимальная гибкость и максимальный объём работ
- Использование зрелого продукта-платформы как основы с адаптационными слоями на обеих сторонах — быстрый запуск, но ограничения продукта
- Сначала одна сторона, другая подключается через открытые интерфейсы — подходит для поэтапного бюджета
Выбор зависит от сложности ваших товаров и возможностей команды по поддержке. Мало SKU, простые механики — достаточно второго варианта; нужны дистрибуция, несколько складов, сложные акции — надёжнее первый.
Предупреждение: при проектировании интерфейсов заранее согласуйте поля и коды ошибок, не ждите, пока обе стороны будут готовы, чтобы начать интеграцию. Обнаружение несовпадения полей на этапе интеграции обходится гораздо дороже, чем два дополнительных дня проектирования на старте.
Систему аккаунтов и членства нужно спроектировать сразу и правильно
Пользователь зарегистрировался в мини-программе, а на сайте должен регистрироваться снова — такой опыт сразу отталкивает.
Для системы членства рекомендуется использовать номер телефона как основной ключ, и сайт, и мини-программа используют одну систему аутентификации. Бонусы, уровни, купоны синхронно отображаются и списываются на обеих сторонах.
Есть часто упускаемая деталь: авторизационный вход в мини-программе и вход по логину-паролю на сайте должны отображаться на один и тот же ID пользователя. Если это не спроектировать сразу, позднее объединение данных будет крайне болезненным, особенно когда уже есть десятки тысяч участников.
Кроме того, если в планах есть и разработка App, систему членства тем более нужно унифицировать заранее. Три отдельные системы аккаунтов на трёх платформах — позднее объединение почти равно переделке.
Как расставить приоритеты при ограниченном бюджете
Не всем компаниям нужно сразу запускать обе стороны. Можно определить по такому порядку:
Сначала посмотрите, откуда приходит трафик. Если в основном из поиска и контента — сначала сделайте корпоративный сайт основательно; если в основном из сообществ и офлайн-магазинов — приоритет у мини-программы.
Затем посмотрите на частоту повторных покупок. Товары частого спроса подходят для удержания в мини-программе, низкочастотные товары с высоким чеком лучше подходят для глубокого описания на сайте.
Наконец, оцените возможности команды. Есть ли кто-то, кто будет постоянно вести акции и рассылки в мини-программе? Если нет — получится пустая оболочка.
Поэтапный подход — не стыдно; страшно запустить обе стороны и не иметь сил управлять ни одной.
В каких случаях стоит обратиться в MIC Studio
Если ваша ситуация соответствует следующим пунктам, можно обсудить с нами:
- Уже есть сайт или мини-программа, хотите добавить вторую сторону и объединить данные
- Логика товаров и заказов довольно сложная, стандартные шаблоны не справляются
- Нужно одновременно спланировать разработку сайта, разработку мини-программы и последующую разработку App, хотите спроектировать архитектуру один раз
- Перед запуском хотите провести тестирование безопасности сайта, чтобы избежать проблем с платежами и данными участников
Мы не даём обещаний вроде «гарантии позиций»; наша основная работа — помочь вам прояснить техническое решение и темпы реализации, а затем сдавать поэтапно.
Три практических рекомендации
Первое: при запуске проекта сначала нарисуйте схему потоков данных. Откуда берутся товары, куда уходят заказы, как идентифицируются участники — проясните это до обсуждения фронтенда. Эта схема сэкономит половину последующих споров.
Второе: сначала определите контракт интерфейсов, потом разрабатывайте. Поля, коды ошибок, способы аутентификации — запишите в документацию, обе стороны разрабатывают по документу, время интеграции значительно сокращается.
Третье: не заполняйте функционал сразу весь. Сначала запустите основную цепочку: товары, оформление заказа, оплата; после успешного запуска добавляйте членство, купоны, дистрибуцию. Если основная цепочка нестабильна, чем больше функций, тем больше проблем.
Взаимодействие разработки сайта интернет-магазина и мини-программы магазина — в конечном счёте задача архитектуры, а не задача выбора. Продумайте роли и данные, а остальное — следование намеченному темпу.