Опыт «Перекрёстка» в разработке мобильного приложения экспресс-доставки: топ-5 инсайтов

Внедрение изменений внутри уже работающего продукта – процесс, в котором опыт играет одну из главных ролей. За несколько лет работы сервиса экспресс-доставки «Перекрёстка» команда разработки сделала много ценных доработок, вынесла для себя важные инсайты, которые позволили выделить главные ошибки и возможности для тех, кто занимается усовершенствованием ритейл-продуктов. В этой статье о своем опыте Retail.ru рассказывает Оксана Щирба, директор по продукту мобильного приложения «Перекрёстка».

Фото: KateV28/shutterstock

Инсайт 1: не откладывать продуктовую аналитику на потом

Продуктовая аналитика – это базовое звено в создании приложения, которое позволяет понять, как работает продукт и как ведут себя пользователи. Если ее нет, то данных может быть недостаточно, чтобы принимать взвешенные решения и развивать приложение.

Кейсы со знаком минус. Впервые мы столкнулись с этим, когда один из стейкхолдеров (заинтересованный в результатах работы сотрудник или департамент) предложил поднять персональные предложения в топ главного экрана, опустив другие важные блоки. Он считал, что это повысит их охват. Так как мы старались прислушиваться к его советам и у нас не было контраргументов, мы убрали часть блоков с главного экрана, чтобы освободить место под персональные предложения. Уже после того, как внедрили аналитику, провели A/B-тест и поняли, что гипотеза не подтвердилась, а негативные побочные эффекты проявились для клиентского пути доставки – уменьшился трафик в разделе «Каталог», с которого начинается путь клиента доставки.

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

Сначала у нас не было аналитики по просмотрам историй. Приходилось либо публиковать огромное количество историй, либо бесконечно договариваться с людьми, которые хотели их публиковать. Первое выливалось в существенные затраты на продакшн, второе – в рост временных ресурсов. После внедрения аналитики оказалось, что оптимальное количество историй – всего 11. Этого было достаточно, чтобы закрыть потребность 95% аудитории продукта.

Кейс со знаком плюс. Обычно больше 70% продуктовых корзин состоит из товаров, которые пользователь покупал до этого. Не всем удобно каждый раз заново набирать их из каталога. В разговорах с пользователями мы часто получали просьбу добавить раздел «Уже покупали». Но дело в том, что этот раздел уже был, но не был заметен пользователям. Задача заключалась в том, чтобы сделать его более явным, не жертвуя позицией основного каталога.

Продуктовая аналитика показала, что в очень заметный раздел «Избранное» заходит меньше 1% аудитории. Количество товаров в нем редко превышало 1–2, конверсия добавления оттуда в корзину стремилась к нулю. Мы решили разместить этот раздел в менее заметном месте, а вместо него поставить «Уже покупали» – один из самых конверсионных разделов приложения. Задача была решена в пользу клиента. На текущий момент этот раздел на 4-м месте по количеству добавлений в «Корзину». Он уступает только «Каталогу», «Поиску» и разделу «Скидки».

Рекомендации. На отечественном рынке нет решений enterprise, которые подходили бы под уровень задач крупных ритейлеров. Поэтому мы разработали собственное – для clickstream-аналитики. Для базовых задач также подходят решения от «Яндекс» или PostHog.

Инсайт 2: не внедрять изменения сразу для всех

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

Кейс со знаком минус. Мы практически никогда не внедряем что-то новое для всей аудитории сразу, но бывают исключения. Все они, однако, подтверждают, что тестировать что-то новое массово – плохая идея. Например, в мобильное приложение «Перекрёстка» мы внедряли обновленную программу лояльности массово. Причем по уважительной причине: очень хотелось вернуть клиентам их баллы. В результате поток обращений в кол-центр вырос в 1,5 раза, из-за чего пришлось увеличить штат операторов на 40% и в оперативном режиме исправлять недоработки. Также потребовалось время на подготовку и адаптацию материалов, обучение сотрудников новым правилам и программе.

Кейс со знаком плюс. Изабелла Леснова, продакт-менеджер в экспресс-доставке «Перекрёстка», решила при помощи мобильного приложения поэтапно внедрять опцию по согласованию замен для отсутствующих товаров по звонку клиенту. Даже несмотря на то что команда верила в эту опцию и хотела быстрее предоставить сервис нашим клиентам. Это позволило вовремя заметить и исправить проблемы. Например, оказалось, что интерфейс у сборщиков заказов был сформирован не совсем корректно, а работникам требовалось больше времени для обучения новым скриптам звонков на замены. Мы скорректировали эти проблемы, провели серию обучений и постепенно внедрили функцию для всех. На это ушло больше трех месяцев, но в итоге мы добились лучшего пользовательского опыта и повысили количество принятия замен через звонки с 1 до 20%.

Рекомендации. Если говорить об универсальной схеме внедрения нового функционала, мы бы рекомендовали делать это в таком порядке:

1. поэтапная техническая развертка релиза в сторах с мониторингом багов;

2. Friends&Family;

3. небольшой процент новых пользователей;

4. небольшой процент старых пользователей;

5. постепенно – на всех пользователей.

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

Инсайт 3: ценность A/B-тестов

Если не проводить A/B-тесты, невозможно понять, как конкретная функция влияет на продуктовые и бизнес-метрики, а также пользовательский опыт – тем самым вы рискуете не просто не улучшить, а ухудшить последний.

Кейс со знаком минус. Изначально в приложении экспресс-доставки «Перекрёстка» сборщики меняли товары через интерфейс. То есть, когда нужного продукта в наличии не было, пользователям приходили пуши с несколькими опциями – и те выбирали подходящую замену.

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

Кейс со знаком плюс. Когда мы внедряли первую версию структуры нашего каталога, то никак ее не тестировали. Решение основывалось на розничной ассортиментной матрице «Перекрёстка» и на онлайн-каталогах аналогичных сервисов. На базе поведенческой аналитики удобство такой структуры не проверяли. А то, что она оказалась неоптимальной, поняли только по завершении редизайна каталога – он длился полгода. Мы проверили разную структуру каталога серией A/B-тестов. Выбрали ту, что обеспечила большую конверсию, – она существенно отличалась от изначальной.

Рекомендации. Проводите A/B-тесты для проверки ваших продуктовых решений всегда, когда есть такая возможность, это поможет существенно сократить время, которое вы тратите на внедрение изменений. Они окажутся лучшими из вариантов для пользователей.

Инсайт 4: использовать систему целевых метрик для продукта и команды

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

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

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

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

Инсайт 5: привлекать команду разработки при проектировании решений

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

Существует явная закономерность: чем позже мы обсуждаем фичу или какое-то решение с командой разработки, тем больше time to market – время выхода на рынок. Потому что разработчики могут сразу подсветить технические ограничения и предложить более элегантное решение.

Кейс со знаком плюс. Сейчас, например, мы работаем над опцией добавления товара в уже сформированный заказ. Когда мы начали думать над решением, в голову приходили только сложные и трудозатратные для разработки UI-варианты. Но наш технический лид по Android как раз предложил легкое элегантное решение – добавление товара будет происходить через отдельный экран с поисковой строкой, а результаты поиска будут адаптированы по релевантности для каждого пользователя. Обновление появится в одном из ближайших релизов мобильного приложения.

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

Собственный опыт

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

В начале каждого года ставим перед собой конкретные цели в виде измеряемых метрик. Например, повышение качества сервиса экспресс-доставки по всему клиентскому пути и улучшение механик лояльности «Перекрёстка» для предоставления большей ценности клиенту. Под это целеполагание составляем верхнеуровневую дорожную карту.

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

Retail.ru