Почему покупатели бросают корзину и оформление заказа

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

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

Что считать брошенной корзиной

Брошенная корзина — это корзина, после которой за выбранный период не зарегистрирована покупка. В определении есть три переменные:

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

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

Корзина и оформление — две разные воронки

Полезно разделить ранний интерес и намерение оформить заказ.

• Корзина: просмотр товара → добавление → открытие корзины.
• Чекаут: начало оформления → данные получателя → доставка → оплата → подтверждённый заказ.

В GA4 для этого предусмотрены рекомендуемые события add_to_cart, begin_checkout, add_shipping_info, add_payment_info и purchase.[1] На их основе можно построить отдельную воронку оформления.[2] Яндекс Метрика принимает данные электронной коммерции о просмотре товара, добавлении, удалении и покупке; дополнительные шаги чекаута удобно фиксировать отдельными JavaScript-событиями.[3]

Два базовых показателя рассчитывают раздельно:

• доля корзин без покупки = 1 − покупки / корзины;
• завершение чекаута = покупки / начатые оформления.

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

Сначала проверяют качество данных

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

Событие соответствует реальному действию

add_to_cart отправляется после успешного добавления товара, а purchase — после подтверждённого создания покупки с уникальным идентификатором. Клик по кнопке ещё не гарантирует, что сервер принял действие. Документация Метрики также предупреждает, что событие, отправленное непосредственно перед переходом на другую страницу, может потеряться, если новая страница загрузится раньше передачи данных.[3]

Одна покупка не считается несколько раз

Обновление страницы «Спасибо за заказ» и повторный заход в личный кабинет не должны создавать новые покупки в отчёте. Событие дедуплицируют по идентификатору заказа, а тестовые заказы, обращения роботов и внутренний трафик исключают из рабочих отчётов.

Статусы бизнеса согласованы с аналитикой

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

Проверены валюты, сумма и состав заказа

Цена, количество, скидка, доставка и валюта должны совпадать с заказом в CRM или учётной системе. Метрика предоставляет режим проверки электронной коммерции через параметр _ym_debug; он помогает увидеть структуру отправленного объекта до ожидания отчёта.[4]

Основные группы причин

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

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

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

Цена и условия получения

Итог меняется из-за доставки, минимальной суммы, платной упаковки или недоступности выбранного способа в регионе. Сигналом служит резкий выход после расчёта адреса либо показа полной суммы. При дистанционной продаже покупателю до заключения договора должна быть доступна предусмотренная правилами информация о продавце, товаре, цене и условиях приобретения.[5]

Наличие и сроки

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

Технический сбой

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

Трудный интерфейс

Обязательная регистрация, непонятное поле, незаметная кнопка, потеря введённых значений и общая ошибка формы увеличивают усилие. Аналитика форм Метрики показывает, сколько пользователей взаимодействовали с формой, отправили её, сколько времени занимало поле и после каких полей уходили.[6] Запись визита помогает воспроизвести последовательность, но не раскрывает мотив без дополнительных данных. Чтобы увидеть конкретные места, где посетители прекращают заполнение, можно подключить аналитику брошенных полей и незавершённых форм.

Недоверие или нехватка информации

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

Какие сегменты сравнивать

Среднее значение скрывает локальную поломку. Обычно достаточно нескольких бизнес-сегментов:

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

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

Диагностический отчёт по шагам

1. Собрать воронку

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

2. Найти место разрыва

Вместо поиска «плохой конверсии всего сайта» выделяют конкретное изменение: рост выходов после выбора доставки на смартфонах, отсутствие покупок после определённого ответа API, падение одного браузера после релиза.

3. Добавить технические данные

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

4. Просмотреть выборку визитов

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

5. Проверить обращения и ручные заказы

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

Как приоритизировать гипотезы

Для каждой гипотезы фиксируют:

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

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

Вопросы, которые помогают проверить каждый разрыв

Для крупного провала в воронке составляют карточку диагностики. Она удерживает команду от преждевременного редизайна.

• Данные: событие отправляется после успешного действия или только после клика? Совпадает ли число заказов с CRM?
• Сегмент: проблема общая или относится к одному устройству, региону, способу доставки, источнику либо категории?
• Изменение: когда показатель изменился и какие релизы, акции или правила доставки появились рядом с этой датой?
• Техника: есть ли рост кодов ошибок, времени ответа, отклонённых платежей или повторных запросов?
• Содержание: какая цена и дата доставки показаны до разрыва, что меняется на этом шаге?
• Поведение: пользователь уходит, возвращается назад, меняет вариант, повторяет нажатие или обращается в поддержку?
• Экономика: затронутые корзины отличаются суммой, маржой, отменами и выкупом?

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

Какие действия дают ложное улучшение

Удаление шага из аналитики повышает нарисованную конверсию, но не меняет заказ. Автоматическое создание заказа при открытии оплаты увеличивает число заказов и одновременно засоряет CRM. Скрытие стоимости доставки переносит отказ ближе к оплате. Навязчивое восстановление корзины может вернуть часть визитов, но создать жалобы и расходы.

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

Как оценивать результат доработки

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

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

Правовые оговорки для аналитики и заказа

Состав собираемых данных связывают с целью. Закон № 152-ФЗ предусматривает несколько оснований обработки, включая исполнение договора и заключение договора по инициативе человека; согласие требуется в тех сценариях, где оператор выбирает его как основание или где это прямо установлено законом.[7] Поэтому чекбокс возле кнопки заказа не является универсальным техническим рецептом. Отдельные цели, например рекламные сообщения, оценивают отдельно от оформления покупки.

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

Итог

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

Источники

1. Google Analytics: рекомендуемые события, включая события электронной торговли.
2. Google Analytics: построение воронки оформления заказа.
3. Яндекс Метрика: передача данных электронной коммерции.
4. Яндекс Метрика: проверка настройки электронной коммерции.
5. Постановление Правительства РФ от 31.12.2020 № 2463: правила розничной продажи.
6. Яндекс Метрика: аналитика форм.
7. Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных».