Чекаут теряет заказы

70,22% корзин в интернет-магазинах бросают, не дойдя до оплаты. Это среднее по 50 исследованиям, которое собирает Baymard Institute.

Большая часть уходов с дизайном не связана: дорогая доставка, долгие сроки, обязательная регистрация — это решения бизнеса. К интерфейсу и качеству из причин, которые называют покупатели в опросе Baymard, прямо относятся две: слишком длинное или сложное оформление (17%) и ошибки и падения сайта (17%).

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

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

Рабочий цикл выглядит так:

1. Данные — где именно уходят покупатели.

2. Причина — почему они уходят именно там.

3. Гипотеза — что изменить и какой эффект ожидаем.

4. Макет — дизайнер отрисовывает решение, включая состояния ошибок.

5. Проверка — юзабилити-тест и A/B-тест.

6. Решение — оставить, доработать или откатить.

Пропуск любого шага превращает редизайн в лотерею.

Воронка по шагам. Каждый шаг оформления (корзина → контакты → доставка → оплата → подтверждение) размечается целью в системе аналитики. Воронка показывает, между какими шагами теряется больше всего людей. Без этой разметки разговор о чекауте идёт вслепую.

Аналитика по полям формы. В Яндекс Метрике для этого есть отчёт «Аналитика форм»: сколько человек увидели форму, начали её заполнять и отправили, сколько времени заняло каждое поле и с каких полей уходят, не отправив данные. Отчёт работает на данных Вебвизора, хранит последние 15 дней и опирается на событие отправки формы — если форма отправляется нестандартно, данных не будет.

Записи сессий. Когда воронка и отчёт по полям показали проблемное место, стоит посмотреть записи сессий тех, кто на нём ушёл. Часто причина видна сразу: поле не принимает формат телефона, кнопка уехала под клавиатуру, ошибка появилась там, где её не видно.

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

Цифры показывают, где уходят. Почему — показывает наблюдение за людьми.

Юзабилити-тестирование. Нескольких участников просят оформить заказ и наблюдают, где они спотыкаются. По нашей практике достаточно пяти участников, они находят около 85% проблем юзабилити. Тут же важная оговорка: лучше провести три раунда по пять человек с исправлениями между ними, чем один тест на пятнадцать. А если у магазина несколько разных групп покупателей (например, розница и оптовые клиенты), участники нужны из каждой.

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

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

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

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

Подсказки адреса. Ввод адреса одной строкой с подсказками сокращает форму. Но подсказки — это сторонние сервисы (DaData, Яндекс, 2ГИС и другие), которые подключаются отдельно и не всегда бесплатно. Их стоимость сравнивают с тем, сколько заказов теряется на полях адреса — и это опять вопрос к данным из шага 1.

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

Итог шага — гипотеза в формате «меняем X, ожидаем, что метрика Y изменится, потому что Z». Без ожидаемого эффекта нечего проверять.

A/B-тест. Часть покупателей видит старый чекаут, часть — новый, и сравнивается выбранная метрика. Несколько правил, которые делают результат надёжным:

• метрику и длительность теста фиксируют до запуска и записывают;

• результат не проверяют каждый день с мыслью «остановим, как только A станет больше B или наоборот» — такой подход поднимает долю ложных побед примерно с 5% до 17%;

• тест идёт полными неделями, чтобы захватить будни и выходные;

• после теста проверяют, что группы получились того размера, который задумывали: если при делении 50/50 в группах оказалось 176 и 124 пользователя, в тесте что-то сломано;

• слишком хороший результат перепроверяют.

Если трафика мало. A/B-тесту нужен объём: объём выборки считают калькулятором от текущей конверсии и минимального эффекта, который хотят поймать. В одном из практических руководств по экспериментам в Яндекс Метрике порогом называют около 2000 визитов в месяц. Когда трафика не хватает, остаются юзабилити-тесты и сравнение «до/после» с поправкой на сезонность.

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

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

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

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

Ответьте «да» или «нет»:

1. Каждый шаг оформления заказа размечен целью в аналитике?

2. Вы знаете, между какими шагами теряется больше всего покупателей?

3. Включена аналитика по полям формы?

4. За последний месяц кто-то смотрел записи сессий ушедших с оформления?

5. За последние полгода проводилось юзабилити-тестирование чекаута?

6. У каждой правки чекаута есть гипотеза с ожидаемым эффектом?

7. Метрику и срок A/B-теста фиксируют до запуска?

8. После теста проверяют, что группы получились нужного размера?

9. Разметку аналитики тестируют перед релизами чекаута?

Если «нет» набралось три и больше, решения по чекауту у вас принимаются скорее на ощущениях, чем на данных.