Привет, друзья! Если вы из тех, кто не боится нырять за результатом в глубины A/B-тестирования, то эта статья для вас. Меня зовут Максим, я продакт-менеджер в Купере — сервисе доставки из магазинов и ресторанов. Зона моей ответственности — пользовательский опыт после оформления заказа: от активного экрана до функций вроде оценки, чаевых партнерам и добавления товаров в уже собранный заказ.
Этот материал — реальный кейс из нашей практики. Речь в нем пойдет о неудачных, «красных» A/B-тестах — после которых гипотезы отправляются в корзину. Один из таких провальных экспериментов мы достали из небытия, разобрали по косточкам и превратили в работающий продукт. Опыт работы с ним оказался полон инсайтов, о них мой рассказ.
Почему товары «исчезают» из заказа
Для начала — немного контекста, он поможет понять суть. В сервисах вроде Купера всегда присутствует риск, что какой-то товар из заказа не достанется покупателю. Мы — агрегатор, работаем с множеством ритейлеров, и качество данных о товаре и его остатках, которыми нам приходится оперировать в диалоге с клиентом, в первую очередь зависит от продавца.
К тому же коррективы в спокойный ритм «продуктового конвейера» стабильно вносит жизнь:
то товар разобрали офлайн-покупатели
то он оказался испорченным (подгнили бананы, грузчики опрокинули палету с яйцами)
то не хватило молока — заказ был на 10 пачек, а на складе — только 5
Последствия печальны: клиент получает неполный заказ, в отношениях между нами исчезает доверие и появляется негатив. Ну и вишенка — мы (компания Купер) теряем в чеке: меньше товаров доставлено — меньше выручки получено.
Личный триггер: как боль пользователя становится вашим вызовом
Очевидное решение описанной проблемы — позволить клиенту самому решить судьбу заказа при форс-мажоре. Обычно сервисы предлагают выбрать один из вариантов:
позвоните мне
если дозвониться не получилось, замените проблемный товар аналогом на свое усмотрение, либо вообще вычеркните позицию из списка
Алгоритм простой и понятный, но есть нюанс. Однажды я обнаружил в смартфоне пропущенный вызов с незнакомого номера. На ответный звонок трубку снял сборщик заказа из сервиса доставки: оказалось, он пытался согласовать замену отсутствующего товара в моей корзине.
Мы обо всем договорились, однако я остался в недоумении: почему такую простую проблему — отсутствие йогурта и его замену — не удалось решить без меня? Ведь подобрать аналог нетрудно: ассортимент магазинов легко позволяет найти продукт или бренд, похожий по вкусу и объему.
Инсайт №1: независимо от масштаба или отрасли, задачи решаются эффективнее, если в них есть личное. Собственный негативный опыт мотивирует к действиям куда сильнее, чем отчеты с метриками.
Анализ: почему 100% покрытия не панацея
Помимо звонков, пропущенных «по вине» клиента, у проблемы есть еще одна сторона: сборщики заказов не горят желанием связываться с заказчиками для уточнений. Причина банальна: никто не любит звонить незнакомцам, да еще с новостями о проблемах, к тому же у сборки есть таймер, а внеплановое общение с клиентами его сбивает.
Ресерч мы начали с дашборда за 2024 год. На графике отображено покрытие звонками тех заказов, где они были необходимы — например, для согласования замены отсутствующих товаров. Желтым цветом обозначены случаи, когда звонок не состоялся (сборщик не смог связаться с клиентом), зеленым — успешные контакты. Период, когда проблема изучалась наиболее активно, приходится на февраль 2024 года: тогда звонки происходили более, чем в 20% случаев, что указывало на серьезный сбой в процессах.
В течение года метрика улучшалась — очевидно, благодаря внедряемым изменениям. Продукт эволюционировал: корректировались инструкции для сборщиков, оптимизировались интерфейсы, вводились дополнительные напоминания и автоматизации. Здесь напрашивается предположение: если довести метрику покрытия звонками до идеальных 100%, когда все контакты происходят без сбоев, означает ли это, что мы решили проблему пользователя?
Нет: метрика отражает лишь количественную сторону процесса (факт состоявшегося звонка), но не учитывает качество взаимодействия.
Инсайт №2: старайтесь не оценивать масштаб проблемы исключительно собственным опытом и ощущениями. Баг или неэффективность, с которыми вы столкнулись, могут быть частным сценарием — вам просто повезло/не повезло. Ищите подтверждение ��ипотезы в системных закономерностях.
Исследования качества звонка
Для объективности был проведен развернутый опрос клиентов. Первый блок вопросов касался сложностей, с которыми покупатели сталкиваются во время звонков от сборщиков.
Результаты неприятно удивили: о том, что контакт произошел без сложностей, рассказали всего 26,9% опрошенных — грубо говоря, лишь четверть. Это значит, что в подавляющем большинстве случаев (73%) звонок сопровождался какими-то помехами, снижающими комфорт пользователя.
Следующий вопрос касался возможности поговорить со сборщиком по телефону: нужна вообще такая опция или нет?
Ответы «это нормально, так и должно быть» и «мне это нравится» в сумме набрали чуть больше 75%. Этот результат примечателен тем, что несмотря на относительно небольшое количество довольных клиентов (напомним, только 27% из них не испытывали сложностей при созвоне), подавляющее большинство положительно относится к идее такого взаимодействия.
Цифры явно говорят о потенциале к улучшению в этом месте — клиентам нужна забота, но в плане реализации фишки нужно что-то менять.
Чтобы разобраться с отношением потребителя к механике телефонных диалогов со сборщиками, мы предложили респондентам несколько сценариев согласования замены товаров в заказе. Задача была простой: выбрать топ-3 варианта, которые им наиболее удобны.
Изюминка в том, что классический звонок в этом перечне стоял в одному ряду с абстрактными функциями, которые теоретически могли бы существовать, но на момент опроса отсутствовали, например: чат, рекомендации в приложении или автоматизированные уведомления с опциями выбора.
С одной стороны, звонок ожидаемо победил: он набрал наибольшее количество голосов (55,1%), поскольку это единственная опция из списка, с которой пользователи уже имели реальный опыт. Они знают, как она работает, и могут оценить качество на основе личных впечатлений. С другой: целых 45% (без малого — половина) респондентов не включили созвон даже в топ-3.
Это говорит о том, что в текущей механике процесса есть серьезные проблемы — от технических (плохая связь, языковые барьеры) до ситуативных (неподходящее время для разговора).
Инсайт №3: пользователи не против самой идеи общения по телефону, даже если она им не очень по душе, но таким способом говорят о ее слабой реализации. Они используют то, что есть, даже если страдают. Исследования помогают сорвать покровы с внешне «нормальных» процессов.
Зачастую люди адаптируются к тому, что им предлагают и терпят неудобства, так как не знают, как может быть иначе. И это нормально — клиент не обязан быть визионером. Это мы, как разработчики, должны брать на себя ответственность: искать болевые точки, генерировать идеи и предлагать альтернативы, которые сделают пользовательский опыт приятным и бесшовным.
От анализа к действию: генерация идей
Проблему идентифицировали, что дальше? Мы начали с проверенной классики: собрали кросс-функциональную команду (IT, операции, маркетинг), провели мозговой штурм, набросали идеи и в рамках метода RICE расположили их в приоритетном порядке.
Получилась упрощенная версия Customer Journey Map (CJM) — три ключевых сценария, которые потенциально могли бы изменить процесс в лучшую сторону.
Инструкции по замене до сборки заказа: пользователь заранее указывает предпочтения для альтернатив (например, через настройки в приложении или при оформлении), чтобы система автоматически подбирала варианты без дополнительного взаимодействия.
Флоу согласования замен во время сборки: через специальный интерфейс в реальном времени — сборщик предлагает опции в чате или уведомлении, а клиент подтверждает выбор прямо в приложении.
Дозаказ после сборки: если товар отсутствует, клиенту предлагается добавить их позже, и они будут доставлены вместе с основным заказом без дополнительных сборов за сборку или доставку.
На первый взгляд эти варианты кажутся перспективными, но, и они не идеальны. Начнем с двух последних — 2 и 3.
Оба сценария ограничены узким временным окном. Чтобы вовлечь клиента в целевое действие (подтверждение или дозаказ) у нас есть всего несколько минут, и, если пользователь занят делами, не смотрит в телефон и пропускает уведомление, схема ломается: заказ нельзя держать «подвешенным» бесконечно, ибо человек может вообще не вернуться к форме, а сделать доставку нужно в любом случае.
Узкое место здесь — пользователя сложно поймать в моменте: заказ уже оформлен, человек закрыл приложение, отложил телефон и занялся другими делами. Пуши, звонки или SMS — это инструменты с низкой вовлеченностью (например, open rate пушей редко превышает 20-30% в зависимости от сегмента), а спам-фильтры и усталость (а, значит, игнор) от уведомлений, только усугубляют ситуацию.
Наконец, проблемы с операционной эффективностью. Все эти нюансы заставляют сборщика тратить время на согласование через приложение, либо тормозят выполнение заказа из-за ожидания реакции клиента.
Инсайт №4: всегда ищите единомышленников — не только для генерации идей на брейншторме, но и для их дальнейшей реализации. Такие «союзники » из разных отделов (dev, ops, marketing) помогут выстроить Discovery-фазу, а потом будут мотивированы довести проект до продакшена, инвестируя собственное время и экспертизу.
Основной сценарий: инструкция по замене до сборки
На первый взгляд, обговорить детали до начала сборки, — наиболее перспективный подход, но (кто бы сомневался), и в нем есть подводные камни. Например, успех сценария зависит от фокусировки пользователя.
В заказе может быть 10-20-30 позиций, и мало кто по доброй воле станет вручную настраивать альтернативы для каждой. Значит, нужно направить клиента при помощи алгоритмов или интерфейса, подсветив нужные пункты.
Онбординг при этом должен быть мягким — ненавязчивое соо��щение, короткое видео. Но нам обязательно нужно объяснить клиенту, зачем нужна и как работает «сборка с заменами», особенно если он новичок в сервисе или еще не сталкивался с проблемой. В общем, без качественного UX, фича почти наверняка останется незамеченной.
Изучая архивы, мы обнаружили, что проблема с заменой уже известна и ранее ее пытались решать теми же средствами, но, закончилось это неудачей. Оценка соотношения затрат и выгод показала: второй и третий сценарии слишком дороги в реализации и хлопотны в эксплуатации. Их в итоге отсекли, но оставили первый вариант, как базу для дальнейшей проработки.
Уроки из неудачных A/B-тестов: на чем споткнулись наши предшественники
Раз уж мы решили дойти до сути, глупо было бы игнорировать опыт неудачных попыток оптимизировать форму предзаказа, тем более сделанных другими. Обратимся к интерфейсам, реализованным в прошлых A/B-тестах.
Начнем с точки входа в сценарий на уровне карточки товара — здесь тестировалось несколько вариантов. Левый скриншот демонстрирует раннюю версию: всплывающая «шторка», которая активировалась каждый раз при добавлении товара в корзину. Сообщением типа: «Выберите альтернативу — на случай отсутствия», система буквально заставляла клиента определиться здесь и сейчас.
Казалось бы, удобно — но, на практике это создает блокирующий флоу: вынужденный прервать шопинг пользователь раздражался и мог даже бросить наполнять корзину.
Ребята вовремя осознали проблему и предложили менее навязчивый вариант — баннер в самой карточке товара (правый скриншот). Вышло наоборот, подход оказался слишком «мягким», пользователи не замечали и просто игнорировали сообщение, продолжая оформление без настроек предзаказа.
Основная же точка работы с фичей — корзина, здесь работа шла особенно активно: в списке товаров под каждой позицией появлялась кнопка Выбрать замену (левый скрин).
Если пользователь нажимал ее, система предлагала альтернативу с опцией изменения — это позволяло быстро скорректировать предпочтения перед оформлением. Флоу выбора (правый скрин): основной товар помещен сверху, а снизу — список рекомендаций для замены. Для этого задействовали ML-модель рекомендаций, которая анализировала похожие товары по атрибутам (вкус, категория, бренд) и предлагала варианты на основе данных о покупках.
Однако здесь команда столкнулась с проблемой качества рекомендаций. На дизайнерских скетчах (как на скриншоте с яблоками) все выглядело отлично: релевантные опции, интуитивный UI. Но в действительности ML-модель работала не так эффективно.
Показательный пример — бананы: они «всплывали» как рекомендация «похожего» товара на любые фрукты. Хотите замену для яблок? Бананы. Для апельсинов? Опять бананы.
Причина проста: алгоритм ориентировался на популярность, а бананы — один из самых покупаемых продуктов. В итоге рекомендации теряли точность, пользователь разочаровывался. ��то типичная ML-ловушка: без тонкой настройки, например, через embedding-модели для поиска по атрибутам, система, вопреки ситуативной логике, склонна к предвзятости в сторону самых востребованных позиции.
Вообще, процесс «расследования» ранних экспериментов оказался настоящим приключением с элементами детектива. Дело в том, что вся доступная документация по ним была разбросана по разным источникам: от внутренних вики-страниц и отчетов до заметок на внешних площадках-органайзерах.
К тому же местами данные противоречили друг другу: один документ описывал фичу как «навязчивую шторку», другой упоминал «минималистичный баннер» без ссылок на изменения. В итоге на то, чтобы реконструировать хронологию тестов и понять причины неудач, ушло куда больше времени, чем мы планировали.
Инсайт №5: Качественная документация — не роскошь. Она помогает не только избежать путаницы и реализовать именно ту функциональность, которую вы запланировали (с четкими спецификациями и вайрфреймами), но и служит «наследием для потомков» — тех, кто через месяцы или годы пойдет по вашему пути.
Последователи смогут быстро разобраться, почему были приняты те или иные решения и что пошло не так в A/B-тестах. В нашем случае правильная документация могла бы сэкономить дни на анализ и помочь избежать повторения ошибок — например, в части ML-рекомендаций или UX-флоу.
Какие выводы мы сделали из чужих ошибок
В целом попытки решить задачу получили положительный фидбэк от сборщиков. Это ожидаемо, инструмент действительно упрощает процесс, увеличивая скорость сборки и улучшая операционные метрики.
С другой стороны, было проведено целых пять «красных» A/B-тестов, каждый из которых заканчивался падением конверсии (в среднем на 3%). Переходить к практической реализации проекта с такими результатами смысла, разумеется, не имело.
Теперь о функциональных качествах интерфейса и пользовательском опыте. Во-первых, неоднозначным показалось размещение окна опции: корзина, в которой оно расположено, — это важная часть воронки продаж. Однако с учетом того, что его актуальность (как мы выяснили) очевидна далеко не всем покупателям, вроде бы полезная фишка больше мешает, создавая ненужный шум, отвлекающий от логики действий.
Во-вторых, само понятие «замены» не до конца понятно клиенту. Интерфейс не объясняет, что произойдет после клика: товар в корзине сменится сразу или это предзамена на случай его (товара) отсутствия? А может, замена активируется только, если продукт не найден на складе? Без четких подсказок человек остается в неведении, путаясь и закрывая приложение без заказа.
Кроме того, рекомендации сами по себе ограничены количеством вариантов, и здорово зависят от качества данных. Вспомним пример с бананами: если похожие товары не подходят, пользователь попадает в тупик.
Нет опций для дальнейших действий: нельзя расширить поиск, добавить фильтры или вернуться к исходному товару без потерь. Это классическая проблема в моделях рекомендаций: если эмбеддинг не охватывает все сценарии, фича становится бесполезной. В итоге юзер попросту игнорирует инструмент.
Из обратной связи с пользователями мы также узнали, что они предпочитают настраивать замены не во время импульсивного шопинга, а ближе к оформлению заказа. Сначала формируют и корректируют список (убирают лишнее, добавляют альтернативы), и только потом «финалят».
Инсайт №6: даже провальный A/B-тест — ценный источник знаний. Он раскрывает неожиданные паттерны поведения клиентов, помогает понять, как люди взаимодействуют с продуктом, и показывает возможности для итераций. На основе таких данных можно разработать новое, более эффективное приложение.
Переосмысление гипотезы: от клиентской ценности к операционной
В проектах по разработке приложений постоянно приходится переосмысливать исходные гипотезы. В нашем случае, анализируя результаты A/B-тестов, мы столкнулись с интересным поворотом: падение конверсии в заказы на фоне улучшения операционных метрик.
Это заставило задаться вопросом — а не является ли проект в большей степени операционным, а не клиентским? Ведь в бизнес-приложениях важно учитывать не только UX, но и общую эффективность цепочки.
Мы обратили внимание на North Star-метрики — ключевые показатели вроде GMV (gross merchandise value) и выручки. Оказалось, что улучшения в операционной части (ускорение сборки заказов) приносят больше пользы, чем потери от снижения конверсии. Это типичный сценарий при автоматизации бизнес-процессов: AI помогает оптимизировать внутренние операции, экономя ресурсы, даже если на первом этапе это сказывается на клиентских метриках. В результате проект оказался выгодным в целом — мы больше сэкономили на операциях, чем потеряли в продажах.
Исходя из этого, были сформулированы новые цели для перезапуска теста.
Минимум — не навредить клиентам сильнее, чем в предыдущих экспериментах, чтобы уровень «размена» метрик остался приемлемым для проверки гипотезы и понимания поведения пользователей.
Максимум — собрать как можно больше данных. Из прошлых тестов мы так и не смогли разобраться, где именно «отваливаются» клиенты и на каком шаге падает конверсия.
Но самой амбициозной целью, виделась возможность добиться операционных преимуществ — ускорения сборки при активном использовании опции, без падения конверсии.
Инсайт №7: у каждого продукта и процесса есть свои показатели эффективности, зацикливаться на них, значит оказаться запертым в «функциональном колодце». Не бойтесь ухудшать локальные метрики, если это идет на пользу сервису в целом.
Новые подходы: от post-checkout к комментариям и фейкдору
Итак, мы начали поиск альтернатив, рассчитывая найти ключ к решению проблемы в полном пересмотре подходов реализации. С учетом уроков из предыдущих A/B-экспериментов нужна была принципиально иная функциональность. При этом осознавая риски повторения фиаско, мы стремились к балансу: сократить затраты на разработку, и одновременно повысить уверенность в работоспособности ��риложения.
Первая идея заключалась в переносе флоу на постчекаут — после оформления заказа. Клиент уже конвертировался, его можно «отпустить» без риска потери, а для тех, кому это актуально, показать поп-ап (шторку) с предупреждением о рисковых товарах и предложением выбрать предзамену.
Это казалось логичным, однако пользовательские исследования дали неожиданный фидбэк. Клиенты прямо говорили, что не хотят заниматься этим после оформления: «Я не понимаю, почему это происходит именно теперь, если мне лучше заранее знать риски».
Поэтому для второго варианта был выбран более простой подход: комментарии к отдельным товарам с шаблонными опциями. Клиенты могли оставлять инструкции, что делать с товаром в случае проблем — например, для молока «Домик в деревне» сохранить жирность, но сменить бренд, придерживаться цены или варьировать жирность при фиксированном бренде.
Исследования показали — замены редко бывают случайными («пиво на бананы») — обычно, альтернатива находится в рамках определенных атрибутов (жирность, вкус, цена, бренд). Мы попытались упорядочить их.
Но здесь нас ждали новые проблемы. Во-первых, параметров, которые объединяют товары, очень много, и зачастую они весьма условны. Например: вкус есть и у бананов, и у йогурта, однако если для йогуртов логична замена с определением «того же вкуса», то для бананов это звучит абсурдно.
Во-вторых, хотя данные показывают, что клиенты задерживаются и достаточно внимательно изучают информацию сервиса о деньгах, бонусах и лояльности, чаще всего они не читают длинные тексты или инструкции, вроде нашего «меню замен».
В-третьих: отсутствие эмоциональной связи. Изображения товара (типа нарисованных яблок или говяжьей вырезки) не вызывают у клиента тревоги о «судьбе ужина» — приедет ли мясо вовремя — а, значит, он легко «перешагнет», через необязательную форму замены.
На этом этапе команда уже рассматривала проведение fake door test, чтобы получить новую порцию отзывов. Но это означало бы новый цикл исследований и сбор данных, а мы и без них уже склонялись к приостановке проекта и переключению на другие задачи.
Прорыв: интеграция с новым экраном!
И вот, мы находимся в той точке, когда все новые вариации инструмента недостаточно хороши, при этом количество гипотез и развилок, только множится:
Размещать флоу до или после оформления заказа?
Делать сложный выбор с рекомендациями или упростить, чтобы урезать затраты на разработку?
Ограничиться одной предзаменой или допустить несколько?
Дать альтернативу через базу ML-моделей, анализирующих паттерны товаров, или каталог?
И самое сложное: как кратко объяснить клиенту суть фичи, ее ценность?
Решение пришло неожиданно: пока шли исследования, смежная команда сделала на нашем чекауте свой экран состава заказа — простой инструмент для проверки содержимого перед оформлением. И пазл сложился!
Мы ушли от основного конверсионного экрана (корзины) в отдельный, не заставляя всех пользователей проходить через общую «рамку» предзамены: теперь баннер виден только тем, у кого есть «опасные» товары:
«Друг, вот этих товаров может не хватить. Давай, ты на всякий случай заранее подберешь им замену?»
Если рисков нет, клиента не дергаем, баннер не показываем, он спокойно идет дальше.
Такой подход освободил пространство для инструкций и мотиваций: в корзине нет места объяснять как, куда и зачем нажимать, чтобы выбрать йогурт для замены, там приоритет — товары, а не баннеры. Теперь мы делаем это с комфортом, сразу переводя клиента в каталог товаров, потому что он изначально идеально структурирован для поиска аналогов.
Не обошлось без курьезов. Во время тестов пользователи пробовали делать предзамену презервативов, которые находились в категории «Презервативы, лубриканты, тест на беременность». А так как в каталоге первыми позициями были тесты на беременность, именно их система и предлагала клиенту: мол, хватит резвиться, чувак, остынь!
Инсайт №8: Смотрите на продукт (процесс) как на нечто живое, динамичное, эволюционирующее. Возможности и точки входа, которых нет сегодня, могут появиться завтра.
Коллеги, знавшие о проекте, отговаривали: «Ребята, что вы делаете? Пять красных тестов подряд — это же путь в никуда, дверь с табличкой «Не влезай, убьет!».
Однако теперь наша уверенность в разработке была подкреплена фактически:
мы провели множество тестов и поняли, что нравится клиентам в продукте, а что — нет
сформулировали новую гипотезу ценности, изменили рекомендательную модель и по-новому взглянули на риски конверсии
собрали большущий дашборд для мониторинга с кучей метрик, чтобы все это отслеживать
Словом, настал момент, когда пора, наконец, сделать шаг веры и перейти от гипотез к реализации.
Выводы
Самое важное — мы не уронили конверсию. Создав для рисковых клиентов отдельный путь, вывели их из основной воронки, параллельно улучшив несколько метрик:
сократили количество отмененных заказов по причине "Нет товарв"
ускорили процесс сборки
повысили процент заменяемых товаров
снизили внутренний контакт-рейт — число обращений сборщиков в контакт-центр при проблемах с товарами
Кроме того, у нас получилось глубже разобраться в механике out-of-stock — проблемы с заканчивающимися товарами. Это позволило выработать стратегию дальнейшего развития. Напомню, что на старте это был MVP, где мы сознательно урезали функциональность, чтобы минимизировать риски и упростить разработку.
Инсайт №9: продуктовая аналитика — это фундамент для анализа того, как пользователи взаимодействуют с процессом, инструментом. Именно она помогает понять (еще до запуска), соответствует ли реальное поведение клиентов вашим ожиданиям. Поэтому не бойтесь экспериментов, они неотъемлемая часть продукта.
Напоследок: узнаете ли вы себя в этом рассказе? Был ли у вас похожий опыт с красными тестами или неожиданными поворотами в продуктовой разработке?
Делитесь в комментариях!
