Брошенные корзины: как понять, на каком шаге покупатели уходят

Договоритесь, что в отчёте считается брошенной корзиной

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

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

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

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

Проверьте события до расчёта доли брошенных корзин

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

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

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

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

Постройте последовательность, соответствующую вашему оформлению

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

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

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

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

Отделите уход до заказа от дальнейшей оплаты

Рассмотрим условный учебный набор: 100 разных корзин одной группы, каждую наблюдали в течение одинакового выбранного срока. В примере идентификаторы связаны корректно, альтернативные пути исключены. Корзину открыли в 90 случаях, оформление начали в 60, заказ создали в 40. Из этих сорока заказов к моменту сверки оплачены тридцать.

По выбранному определению без заказа осталось 60 из 100 корзин, то есть 60%. Десять созданных, но ещё не оплаченных заказов не нужно повторно записывать в уход до создания заказа. Среди них могут быть оплата при получении, ожидающая операция и отказ. Эти причины выясняются по состояниям заказа и платежа, а не по одному событию аналитики.

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

Сравните группы, в которых условия действительно различаются

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

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

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

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

Запишите гипотезу так, чтобы её можно было опровергнуть

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

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

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

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

Оцените изменение вместе с качеством созданных заказов

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

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

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

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

Соберите отчёт, по которому команда сможет действовать

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

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

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

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