Содержание
- 1. Headless commerce — это подход к реализации e-commerce проектов
- 2. Принцип работы headless commerce
- 3. Отличия headless commerce от «монолитной» архитектуры. Преимущества и недостатки традиционного подхода
- 4. Преимущества и недостатки headless commerce
- 5. Headless commerce платформы. Как выбрать и на что ориентироваться
- 6. Когда и кому разумно внедрять headless commerce
- 7. Кейсы компаний, использующих headless commerce
Headless commerce — это подход к реализации e-commerce проектов
В последние 2-3 года понятие headless commerce набирает популярность в связи с развитием и усложнением онлайн-магазинов. Добавляются новые способы оплаты, BNPL-сервисы, подписные модели, поисковые системы, новые интерфейсы и способы взаимодействия с магазином: например, с помощью умных колонок и других смарт-гаджетов. Каждый из таких сервисов представляет собой отдельный самостоятельный интерфейс (фронтенд), который необходимо соединить с бэкендом — программной логикой интернет-магазина.
Тут и подключается headless commerce — подход к управлению e-commerce ресурсами, который упрощает процесс интеграции. В рамках этого подхода бэкенд становится универсальной, независимой серверной частью, которая предоставляет свои технические ресурсы для реализации любого пользовательского интерфейса или фронтенда. Таким образом, фронтенд и бэкенд независимы друг от друга и взаимодействуют с помощью API. Более того, у некоторых решений и вовсе нет фронтенда как такового, только бэкенд и API, а фронтенд пишут под свои потребности те, кто использует такое ПО.
Так, к бэкенду интернет-магазина можно подключить модуль голосового поиска и интерфейс умного холодильника. Если пользователь, открыв дверцу, увидит, что молоко закончилось, то сможет заказать его тут же вслух, не открывая приложение магазина.
Принцип работы headless commerce
В рамках этого подхода условный интернет-магазин можно поделить на две части: его внешняя оболочка, отрисованный UX-дизайн и его разнообразные модули-сервисы — то, с чем взаимодействуют пользователи. Вторая часть — «внутрянка»: базы данных и серверная часть, которая отвечает за работу этих пользовательских интерфейсов или «голов». Друг с другом обе части взаимодействуют с помощью API — программного интерфейса приложения, который позволяет программам обмениваться данными и становится мостиком между фронтендом и бэкендом.
«Голова» (фронтенд,внешний вид интернет-магазина) взаимодействует с «телом» (бэкэндом, базами данных) по API. Источник: chargebee.com
Такой разделенный вид программного взаимодействия удобен, поскольку разработчикам открывается возможность изменять большой объем бизнес-логики или внутренних настроек, не затрагивая при этом пользовательские интерфейсы. Более того, менять внешний вид онлайн-магазина при этом можно без вмешательства во внутренние системы и сохранив целостность всего e-commerce проекта.
Одним из примеров использования подхода на российском e-commerce рынке можно назвать экосистему «Яндекс»: например, с онлайн-маркетплейсом «Яндекс Маркет» работают умные колонки, мобильное приложение, сервисы доставки. При этом существует открытое публичное API, которым могут воспользоваться все желающие и создать собственное приложение.
Отличия headless commerce от «монолитной» архитектуры. Преимущества и недостатки традиционного подхода
10-15 лет назад монолитная архитектура по формату «все в одном» была если не единственным способом создать онлайн-магазин, то точно наиболее распространенным. При таком традиционном подходе к онлайн-торговле внешний вид сайта тесно связан с его функциональными возможностями. Если нужно изменить дизайн интерфейса или добавить новую фичу, то важно учитывать возможности и ограничения используемых платформ.
Такой комплексный подход считался удобным и гарантировал полный контроль над разработкой: если фронтенд и бэкенд делаются по единому роадмапу, это упрощает разработку. К тому же, есть возможность реализовать любую кастомную идею. Наконец, ПО на монолитном подходе всегда состоит из меньшего количества компонентов. Это делает его более простым, а значит — более надежным.
Среди примеров на основе традиционного подхода — Wordpress с плагином Woocommerce. Также в российском e-commerce сегменте востребовано семейство решений на основе «1С-Битрикс». CS-Cart также раньше использовали традиционный подход, а сейчас всё активней внедряет headless-ПО.
При этом в рамках «1С-Битрикс» также можно реализовать headless-подход. Для этого нужно использовать платформу для создания бэкенда и API, а затем «присоединять» к бэкенду различные пользовательские приложения.
Однако у традиционного метода есть и недостатки. Например, заранее заданный UX-дизайн. Все элементы пользовательского интерфейса и бизнес-логика тесно взаимосвязаны между собой. Разработчики могут потратить много ресурсов, чтобы адаптировать элементы UX-дизайна к новой функциональности. Для того, чтобы что-то видоизменить, зачастую приходится сильно изменять весь продукт.
Более того, удлиняется time-to-market продукта. Каждое изменение в монолитной системе должно быть тщательно протестировано, поскольку любая ошибка может привести к сбою всей программы. При headless- подходе можно внедрять новшества в каждом из приложений в отдельности, не затрагивая при этом остальные.
Преимущества и недостатки headless commerce
Из плюсов системы:
-
Гибкость. Разработчики могут создавать любой пользовательский опыт. API-first подход позволяет торговцам быстро реализовывать лучшие услуги в своих нишах. И при интеграции нового сложного сервиса работа интернет-магазина не нарушится.
-
Персонализация. Новые фичи и элементы интерфейса можно внедрять с учетом пользовательского поведения и ценностей конкретного сегмента. Это позволит повысить лояльность покупателя к бренду, а следовательно — объем продаж;
-
Высокая скорость внедрения обновлений — благодаря тому, что не нужно менять бэкенд для создания еще одного продукта или добавления фич в один из уже работающих интерфейсов.
-
Оптимизация для разных устройств и интерфейсов. К торговой платформе можно привязывать интерфейсы для разных типов устройств, например, мобильных приложений, умных часов, голосовых ассистентов.
-
Экономичность подхода в долгосрочной перспективе. Первоначальные инвестиции в создание самостоятельного бэкенда могут быть высокими, но эффективность подхода окупит вложения и принесет прибыль. Необходимо один раз создать сложный бэкенд, чтобы затем использовать его для интеграции множества более дешевых пользовательских приложений. В случае с традиционным подходом каждый из продуктов подразумевает свой бэкенд.
-
Масштабируемость. Основная часть интернет-магазина обычно достаточно устойчива и надежна для внедрения новых технологий, потому что разработчикам необходимо лишь соблюдать спецификацию внешнего интерфейса (API), вне зависимости от внутренней реализации бизнес-логики. Зачастую используется микросервисный подход, который еще больше повышает масштабируемость.
-
Снижение взаимозависимости в рамках ИТ-команды. Разработчики смогут самостоятельно тестировать, разрабатывать и исправлять ошибки каждый своего приложения — без опасения «сломать» всю систему.
-
Рост коэффициента конверсии. Маркетологи могут безопасно проводить А/Б-тесты и проверять гипотезы, и вносить изменения только в одном приложении, не влияя на остальные.
Минусы подхода заключаются в следующем:
-
Высокие начальные затраты. На разработку индивидуального решения может потребоваться больше ресурсов, чем на внедрение стандартного ПО.
-
Технические требования. Бизнес-логика бэкенда становится универсальной базой проекта, и к ней повышаются требования — как с точки зрения бизнес-логики, так и разработки.
-
Затраты на поддержку. Обычно ПО с отделенным бэкендом устроено технически более сложно, поэтому его поддержка может быть ресурсоемким процессом и требовать более высокой квалификации специалистов.
-
Риски управления. Каждый новый сервис на платформе — потенциальная точка отказа. Поэтому важно предусмотреть, чтобы магазин в любом случае продолжал работу.
Headless commerce платформы. Как выбрать и на что ориентироваться
Основное различие среди решений — это формат: SaaS либо «коробка», разворачиваемая на собственных мощностях. Так, если нет собственной команды разработчиков для создания и поддержки такого продукта, или нужно двигаться быстро — то разумно выбирать SaaS.
Второе — разумно изучить функциональность: все ли задачи конкретного бизнеса реализуются выбранной платформой, интегрируются ли необходимые программы, есть ли возможность использовать магазин без серьезных доработок.
Решения «КОРУС Консалтинг»
Команда «КОРУС Консалтинг» может реализовать любые e-commerce-проекты, используя как традиционный, так и headless-подход в обоих форматах. Так, система управления гейтами на складских комплексах для маркетплейсов и ритейлеров Gate Management System реализована с использованием «безголового» подхода. При необходимости к ней можно подключить любые дополнительные приложения — например, мобильный интерфейс для быстрого доступа со смартфонов.
Agora
Разрабатывают ЭТП-, КИМ- и SRM-программы, а также маркетплейсы и порталы для оптовых закупок и отраслевых решений на основе подписной модели или с коробочной лицензии.
CommerceTools
SaaS продукт. Именно они выделили технологию как отдельный подход. Их платформа обещает пользователям существенное увеличение бизнес-показателей вроде средней стоимости заказа и скорости сайта. Это стало возможным благодаря следующей системе: модульная архитектура интегрируется с имеющимся ПО и дополняет его;
GraphQL (специальный язык запроса данных) используется для повышения эффективности работы с информацией информацией, а разработчики выбирают тот стек, который им комфортен. В России недоступны.
Источник: commercetools.com
Spryker
Зарубежная SaaS-платформа для создания e-commerce-проектов в разных сегментах — b2b, b2c, d2c. Ее хвалят за высокую производительность и масштабируемость. Придумали концепцию unified commerce, при которой торговые площадки в разных регионах и филиалах с разным ассортиментом, остатками и ценами легко контролируются единовременно.В России недоступны.
Источник: spryker.com
Magento или Adobe Commerce
Коробочное решение от компании Adobe, которое позволяет быстро развернуть e-commerce проект, и затем настраивать интеграцию через REST и SOAP web API, а также интегрировать системы CRM, PIM, ERP, бухгалтерского учета, маркетинговые и другие. В платформу встроена удобная аналитика с наглядной визуализацией данных. Есть омниканальные решения, позволяющие комбинировать работу офлайн- и онлайн-продаж. Подходит для b2b и b2c сегментов.
Источник: business.adobe.com
Shopify Plus
SaaS-формат. Раньше Shopify был стандартной e-commerce платформой для продавцов. Затем компания ввела новый стандарт Shopify Plus с GraphQL API, который поддерживает headless-решения. Теперь сервис поддерживает интеграцию такими с необходимыми бизнес-системами, как CRM, PIM и ERP, публикацию контента и работу с разными каналами продаж. Оптимален для малого и среднего бизнеса в b2c сегменте. Недоступен в России.
Источник: shopify.com
Когда и кому разумно внедрять headless commerce
В каком случае подход может быть полезен компаниям:
— есть необходимость реализовать омниканальную бизнес-стратегию. Решения позволяют эффективно собирать все данные об аудитории и предоставлять пользователям доступ к тем каналам, которые они используют для онлайн-шопинга;
— хочется больше инфраструктурной гибкости. Подход позволяет быстрее вводить и тестировать новые функции и также быстро отказываться от них в случае невостребованности;
— есть потребность повысить качество покупательского опыта и в целом обслуживания клиентов: подход позволит проводить больше тестов с UX и повышать производительность и эффективность продукта;
— если есть необходимость работать с разными сегментами или нишами — b2b, b2c, d2c. У каждой из этих аудиторий разные потребности, поэтому разумно закрывать их в разных приложениях. Другой пример — одна и та же компания предоставляет одновременно разные товары и услуги, и делает для каждого направления отдельное приложение. При этом все приложения могут быть соединены одним бэкендом.
— хочется быстро захватывать ниши. Например, оперативно подключать IoT к проекту;
— есть потребность в создании уникального покупательского опыта, и текущие функциональные возможности не позволяют это сделать.
Кейсы компаний, использующих headless commerce
Lamoda
С использованием метода разработали программное обеспечение на стыке 2 предметных областей: портала поставщиков (e-commerce) и Yard Management System (область WMS). На рынке не существовало готовых решений, которые бы полностью закрывали задачи команды Lamoda: внедрить интерфейс по типу «единое окно», получить возможность отслеживать загрузку гейтов, исключить хаотичное управление большим количеством таблиц и броней, масштабировать программу на новые склады, избавить сотрудников от выполнения рутинных задач и минимизировать ошибки.
Интерфейс календаря бронирования слотов системы Gate Management System
Headless-подход в реализации этого продукта открывает большой потенциал для масштабирования ПО. Например, можно подключать мобильные приложения для сотрудников складов или водителей, автоматизировать работу гейтов с помощью датчиков, устройств объективного контроля и т.д. Возможности ограничены только фантазией заказчика.
В результате, число самостоятельных бронирований партнёрами выросло почти в 6 раз — с 16% до 92%. Это позволило сократить трудозатраты менеджеров компании на поддержку в 2 раза по сравнению с началом прошлого года. Точность планирования при этом повысилась в 2,5 раза, а склад теперь принимает больше машин с мелкими поставками.
Olam Group
Olam Group, поставщик продуктов питания и агробизнес, работает в 60 странах, и для каждой страны есть свой комплексный e-commerce сайт. При этом каждый сайт — это большая база полезного контента о продукции и портал для закупок.
Источник: olamgroup.com
Среди задач компании — масштабироваться на большее число рынков и вводить новые продукты. Чтобы повысить эффективность работы большого числа сайтов, компания отошла от традиционной монолитной архитектуры и внедрила headless-подход, который объединил все сайты с одним бекэндом. Это позволило улучшить пользовательский опыт и снизить процент отказов на этапе чекаута с 60% до менее 30%.
Pentair
Pentair занимается очисткой воды. До перехода на headless-архитектуру, бренд управлял почти тремя десятками сайтов в США помимо еще нескольких в Европе. Разница контента для b2b- и b2c-потребителей в связи с таким большим числом сайтов стала очень размытой, и пользователям стало сложно находить подходящие ресурсы и информацию.
Источник: pentair.com
Из-за сложностей, связанных с управлением таким количеством сайтов, линии между B2C, B2B и подрядчиками стали размытыми. Это, в свою очередь, затруднило поиск каждой группой клиентов веб-сайта и ресурсов, соответствующих их потребностям. Новая архитектура позволила компании объединить все точки взаимодействия на одном сайте, выстроить понятную для всех сегментов навигацию и повысить качество клиентского опыта.
Tesla
Tesla использовала подход для того, чтобы дать покупателям возможность самим выбирать материалы или цвета своих автомобилей. Гибкие функции с поддержкой API позволили Tesla повысить покупательский опыт, внедрить удобную доставку, а также варианты возврата средств.
Источник: shop.tesla.com
***
Команда «КОРУС Консалтинг» может выполнить e-commerce-проект любой сложности. Если у вас остались вопросы или требуются партнеры в разработке e-commerce-проекта с headless-архитектурой для бизнеса — оставьте заявку в форме ниже или напишите на адрес omni@korusconsulting.ru, мы с вами свяжемся и проконсультируем.
