Почему покупатель бросает корзину в приложении: сценарии UX-аудита

18.10.2026 E-commerce UX мобильные приложения Покупатель Корзина 20 мин чтения

---

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

Что такое UX-аудит корзины и что он даёт бизнесу

UX-аудит корзины — последовательная проверка пути от карточки товара до подтверждённого заказа. Проверка идёт по трём источникам одновременно, и каждый отвечает на свою часть вопроса:

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

Для собственника и e-commerce-директора результат аудита переводится на деловой язык так: вы получаете список шагов, на которых теряются уже оплаченные рекламой пользователи, и перечень изменений, каждое из которых можно проверить измерением. Аудит не рисует новый дизайн и не обещает роста продаж — он сокращает перечень догадок до нескольких проверяемых гипотез.

Что получает руководитель на выходе

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

Что проверить до начала аудита

• Совпадает ли число успешных заказов в аналитике с числом заказов в учётной системе.
• Размечены ли отдельно шаги оформления заказа, а не только экран корзины.
• Фиксируются ли ошибки: отказ оплаты, неверный адрес, недоступный промокод.
• Разделены ли данные по операционным системам и по версиям приложения.
• Есть ли записи сессий или хотя бы журналы клиентских ошибок за последний месяц.

Шесть точек, где покупатель бросает корзину

Средняя доля брошенных корзин в онлайн-торговле по сводке исследований Baymard Institute держится около 70%. Сводка пересчитывается по мере выхода новых работ, поэтому перед использованием цифры посмотрите дату на странице источника. Для вашего приложения это ориентир рынка, а не норма: считать нужно по собственным данным, отдельно по операционным системам и отдельно по новым и повторным покупателям.

Шесть точек ниже перечислены в порядке движения покупателя. Приоритет работ определяется двумя числами: сколько людей проходит через точку и какая доля из них на ней останавливается. Условный пример: точка с долей уходов 40% при сотне пользователей в месяц подождёт, а точка с долей 12% на основном потоке требует внимания раньше.

Карта точек выхода: что ломается и где это видно в данных

Часть причин вообще не лежит в интерфейсе: цена, ассортимент, срок доставки, доверие к бренду. Общий обзор таких ограничений собран в материале про основные проблемы электронной коммерции, а влияние подачи товара на выбор покупателя — в разборе факторов спроса и визуальной подачи. Аудит интерфейса отвечает за ту часть потерь, которую можно снять правкой экранов и сценариев.

Регистрация и вход в аккаунт

Крупные потери начинаются с требования войти в аккаунт раньше, чем покупатель увидел итоговую сумму. Человек уже выбрал товар, а приложение просит номер телефона и ожидание кода. Дальше добавляются мелкие поломки: таймер повторной отправки на минуту и код из СМС без автоподстановки. Отдельно стоит поломка с корзиной гостя: она пропадает после входа, потому что её не связали с профилем.

Что проверить

• Можно ли дойти до экрана оплаты без создания аккаунта, с подтверждением только на последнем шаге.
• Сохраняется ли корзина гостя после входа, и что происходит при расхождении с корзиной в профиле.
• Подставляется ли код из СМС автоматически и доступна ли повторная отправка без длинного ожидания.
• Есть ли понятный выход из состояния «код не приходит»: звонок, вход по электронной почте, обращение в поддержку.
• Размер нажимаемых областей на экране входа: рекомендации Apple для интерфейсов — не меньше 44×44 pt, об этом есть отдельный раздел руководства по интерфейсам.
• Какие поля в профиле обязательны и почему: дата рождения и пол на шаге заказа редко нужны для доставки.

Гипотеза и как её измерить

Формулировка для проверки: если перенести вход на шаг после выбора доставки, доля пользователей, дошедших от корзины до экрана оплаты, вырастет. Замер — сравнение двух случайных групп в течение полного делового цикла, обычно двух-четырёх недель. Ограничение: часть заказов перестанет попадать в профиль, и обмен с программой лояльности придётся достраивать по номеру телефона из заказа.

Промокоды и скидки

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

Что проверить

• Текст ошибки при неудачной попытке: указана ли причина и условие, при котором код сработает.
• Поведение скидки при смене доставки, оплаты и состава корзины.
• Видна ли итоговая сумма до перехода к оплате — с ценой товаров, скидкой и доставкой в одном блоке.
• Свёрнуто ли поле кода для тех, у кого кода нет, и подставляется ли код из ссылки акции.
• Совпадают ли условия акции в приложении, на сайте и в рассылке.

Гипотеза и как её измерить

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

Адрес доставки: ввод и проверка

Ввод адреса требует от покупателя больше ручной работы, чем остальные шаги оформления. Поломки повторяются от приложения к приложению:

• ручной ввод без подсказок по улице и дому;
• обязательные поля подъезда и квартиры при доставке в пункт выдачи;
• несовпадение дома с базой геокодера и отказ без пояснения;
• сообщение «доставка по адресу недоступна» без предложения альтернативы.

Отдельно стоит потеря введённого адреса при возврате на предыдущий экран. После этого человек вводит данные второй раз и часто бросает заказ.

Что проверить

• Работают ли подсказки адреса с первых символов и допускают ли они опечатки.
• Какие поля обязательны для курьерской доставки, а какие — для пункта выдачи.
• Что происходит при отказе по адресу: предлагает ли приложение ближайший пункт выдачи или другой способ.
• Сохраняются ли введённые данные при возврате назад и при сворачивании приложения.
• Видны ли на карте пункты выдачи с режимом работы и сроком хранения заказа.
• Сходятся ли зоны доставки в приложении и в учётной системе.

Гипотеза и как её измерить

Если подключить подсказки адреса и оставить обязательными только поля, нужные курьеру, число ошибок проверки адреса на один заказ снизится. Метрика — доля заказов с ошибкой проверки и доля повторных попыток ввода. Расхождения в зонах доставки обычно тянутся из бэк-офиса, поэтому вместе с интерфейсом смотрят обмен с системой складского учёта и общую омниканальную архитектуру. Про требования покупателей к пунктам выдачи есть отдельный разбор — рост доставки в пункты выдачи.

Способы оплаты и отказы платежа

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

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

Что проверить

• Набор способов оплаты: карта, Система быстрых платежей, оплата при получении, рассрочка — и их порядок на экране.
• Возврат из банковского приложения: открывается ли экран статуса заказа, а не главная.
• Текст сообщения при отказе: понятно ли, что делать дальше, и остался ли заказ в корзине.
• Повторная попытка: можно ли сменить способ оплаты без повторного ввода адреса.
• Поведение при двойном нажатии кнопки оплаты и при потере связи в момент платежа.
• Как платёжный экран ведёт себя в пиковые часы — это проверяется нагрузочным тестированием перед распродажей.

Гипотеза и как её измерить

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

Стоимость и сроки доставки

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

• порог бесплатной доставки, о котором не сказано в корзине;
• срок «от трёх до семи дней» без выбора даты и интервала;
• разные цены доставки в приложении и на сайте.

Что проверить

• Видна ли стоимость доставки в корзине до перехода к оформлению, хотя бы ориентировочно по городу.
• Подсказан ли порог бесплатной доставки и сумма, которой не хватает до него.
• Есть ли выбор даты и интервала, и совпадают ли интервалы с возможностями службы доставки.
• Читается ли блок с ценой: контраст текста и фона по рекомендациям W3C для веб-доступности — не ниже 4,5:1 для обычного текста.
• Совпадают ли условия доставки в приложении, на сайте и в описании на карточке товара.
• Что видит покупатель, когда часть заказа доставляется отдельно.

Гипотеза и как её измерить

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

Восстановление корзины и возврат к заказу

Покупатель редко оформляет заказ в один присест. Он возвращается через час, вечером или уже с другого устройства. Поломки этого сценария:

• корзина живёт только на одном устройстве;
• товар исчезает из корзины без уведомления и без замены;
• незавершённое оформление не восстанавливается с того же шага;
• напоминание приходит без причины возврата и повторяется четвёртый раз.

Что проверить

• Сохраняется ли корзина между устройствами для вошедшего покупателя и сколько живёт корзина гостя.
• Что происходит при исчезновении товара: предупреждение с заменой или молчаливое удаление строки.
• Восстанавливается ли оформление с последнего шага — с адресом, доставкой и способом оплаты.
• Что написано в напоминании: причина возврата, состав корзины, срок действия цены.
• Сколько напоминаний приходит на одну корзину и можно ли их отключить в настройках.
• Куда ведёт нажатие на напоминание: на экран корзины или на главную.

Гипотеза и как её измерить

Если восстанавливать оформление с последнего шага и отправлять одно напоминание с составом корзины, доля вернувшихся к незавершённому заказу в течение суток вырастет. Метрика — возвраты к незавершённому заказу и доля таких возвратов, которые закончились оплатой. Ограничение: напоминания работают только для тех, кто разрешил уведомления, поэтому замер идёт отдельно по этому сегменту. Подсказки и помощь прямо в сценарии оформления разобраны в материалах про встроенную поддержку клиентов и разговорных помощников в электронной торговле, а их возможности в подборе товара — в обзоре ассистентов для онлайн-покупок.

План событий аналитики для корзины

Без разметки данных аудит превращается в перечень мнений. Минимальный план событий закрывает три вопроса: сколько людей прошло шаг, сколько остановилось и по какой причине. Главное правило — фиксировать не только успех, но и отказ с его причиной. Отказ без кода ошибки не отличить от того, что человек передумал.

Минимальный план событий для корзины и оформления заказа

Что проверить в текущей разметке

• Единые имена событий и параметров в двух операционных системах — иначе воронки не складываются.
• Номер заказа в событии успеха: без него сверка с учётной системой упирается в ручной подбор.
• Разделение клиентских и серверных событий: отказ банка надёжнее фиксировать на сервере.
• Отсутствие персональных данных в параметрах событий — обработка данных покупателя подчиняется закону о персональных данных.
• Расхождение числа заказов в аналитике и в учётной системе: расхождение выше нескольких процентов делает выводы о воронке шаткими.

Когда данные собраны за несколько месяцев, по ним работают и прогнозные модели — это отдельная тема, собранная в материале про предиктивную аналитику в электронной торговле. До этого шага полезнее закрыть пробелы в разметке.

Пользовательские тесты и измеримые гипотезы

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

Подготовка теста в течение недели

• Цель. Один-два шага пути, выбранные по данным, а не весь путь целиком.
• Участники. Пять человек на сегмент: по методике Nielsen Norman Group этого хватает, чтобы увидеть большинство повторяющихся проблем. Новые и повторные покупатели — разные сегменты.
• Задачи. Три сценария с понятным завершением, сформулированные словами покупателя.
• Условия. Своё устройство участника, обычная связь, запись экрана с письменным согласием.
• Фиксация. Таблица «участник — шаг — что произошло — слова участника».
• Разбор. Проблема попадает в список, если повторилась у двух участников и выше.

От наблюдения к проверяемой гипотезе

Наблюдение превращается в задачу для разработки через гипотезу: формулировку с метрикой, сроком замера и ограничением. По нашему опыту работы с мобильными приложениями именно ограничение чаще всего забывают, а потом объясняют рост сезоном распродаж.

Как наблюдение превращается в проверяемую гипотезу

Гипотеза проверяется сравнением двух случайных групп, а при малом трафике — сравнением периодов до и после с поправкой на сезон. Обещать рост продаж от правки экрана некорректно: приложение живёт в одном контексте с ценами, рекламой и наличием товара. Корректная формулировка звучит как «ожидаем изменение метрики X, замер через Y недель, при условии Z». Как связать такие замеры с деньгами проекта, разобрано в материале про оценку окупаемости мобильного приложения.

Ограничения метода

UX-аудит закрывает часть вопросов и оставляет открытыми другие. Это нормально, если границы названы до начала работ.

• Причины вне приложения. Цена выше рынка, отсутствие размера, срок доставки в две недели — интерфейс этого не исправит.
• Малый трафик. При нескольких десятках заказов в неделю сравнение двух групп не даст значимого вывода; остаются наблюдение и журналы ошибок.
• Сезонность. Замер во время распродажи покажет эффект акции, а не правки экрана. Подготовка к пиковым периодам — отдельная работа, собранная в чек-листе к распродажам и в чек-листе к новогоднему сезону.
• Чужие отказы. Сбои на стороне банка или службы доставки видны в данных, но решаются договором и технической поддержкой партнёра.
• Ограничения готового решения. В приложении на стороннем решении часть экранов не меняется. Тогда вопрос переходит в плоскость перехода на собственное приложение.
• Разные операционные системы. Поведение экранов оплаты и возврата из банковского приложения на iOS и Android различается, поэтому проверки и замеры ведутся раздельно.

Качество проверок тоже стоит оценить отдельно: сценарии оформления заказа входят в набор, который проверяют перед каждым выпуском. Общие правила собраны в материале про принципы тестирования программного обеспечения, а автоматизация таких проверок — в разборе инструментов автоматизации тестирования.

Итог: порядок работ по корзине

Работа с брошенной корзиной складывается в пять шагов, и первые два не требуют изменений в интерфейсе.

1. Сверить разметку данных. Закрыть пробелы по плану событий, проверить сходимость с учётной системой.
2. Построить воронку. Посчитать уходы по шести точкам отдельно для iOS и Android, для новых и повторных покупателей.
3. Выбрать две точки. Там, где произведение трафика на долю уходов максимально.
4. Провести наблюдение. Пять участников на сегмент, три задачи, запись экрана, сводка повторяющихся проблем.
5. Поставить гипотезы. Две-три формулировки с метрикой, сроком замера и ограничением; проверить и зафиксировать результат, в том числе отрицательный.

Такой порядок даёт выигрышный баланс затрат и результата: дорогие изменения интерфейса идут последними, после того как данные и наблюдения показали, где именно теряются заказы. Смежные темы — аудит сайта с привлечением моделей машинного обучения, поиск по каталогу и технологические тренды интернет-торговли.

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