Воронка чекаута: где теряется выручка и что может исправить инженерная команда

Если бы нужно было выбрать одну страницу, которую стоит сделать быстрее и надёжнее — это чекаут. Не главная, не листинг — именно чекаут. На магазине с €5M в год полпроцентного улучшения completion rate — это €25 000. И при этом именно на эту страницу большинство инженерных команд тратит меньше всего времени. Мы сделали достаточно аудитов чекаутов, чтобы иметь чёткое мнение о том, почему.

Пошаговое отсеивание — это то, что реально нужно отслеживать

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

Точки утечки, которые мы встречаем снова и снова: стоимость доставки, которая впервые появляется на третьем шаге трёхшагового флоу; загрузка страниц между шагами дольше трёх секунд; отсутствующие способы оплаты. Последнее недооценивают. Покупатель, который хочет заплатить через Klarna или местный банковский перевод, а не может — уйдёт. Неважно, насколько хорош остальной флоу. Ничто из этого не требует A/B-теста для диагностики — только нормального инструментирования воронки.

Валидация форм, от которой не хочется уйти

Валидация при потере фокуса, а не при сабмите — это самый главный UX-фикс формы, и в большинстве реализаций это изменение в одну строку. Что ещё гонит людей: слишком строгий regex для email, отклоняющий валидные адреса (мы видели, как он режет .agency и новые TLD), сообщения об ошибках вида «неверный ввод» без объяснений, и очистка всей формы при неудачной отправке. Последнее — особенно. Люди не будут вводить номер карты второй раз.

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

Авторизационные ставки: невидимый рычаг конверсии

Большинство команд смотрят на success rate платежей как на одну цифру и списывают неудачи на шлюз. Реальность детальнее. Авторизационные ставки отличаются по эмитенту карты, типу карты, географии и сумме транзакции. Один процессор, оптимизированный под отечественные Visa, тихо откажет заметной доле международных Mastercard. Магазины с умной маршрутизацией — попытка повторного проведения через вторичный процессор, маршрутизация по BIN-диапазону — регулярно восстанавливают 5–15% транзакций, которые иначе бы потерялись.

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

Мобильный чекаут — это отдельная задача

Мобильный трафик — большинство на большинстве магазинов, а конверсия чекаута на мобильных отстаёт от десктопа на 20–40% почти везде, где мы смотрели. Принято винить дизайн или UX, но проблема обычно инженерная. Набирать 16-значный номер карты на клавиатуре телефона — это мучение. Touch-таргеты, построенные под точность десктопного клика, дают промахи. Платёжные флоу, которые уводят в браузерную вкладку или внешнее приложение, теряют пользователей способами, которых на десктопе вообще нет.

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

Производительность конкретно на чекауте

Страницы чекаута копят JavaScript со временем — платёжный SDK, библиотека валидации форм, аналитика, A/B-фреймворк сверху. Мы видели страницы чекаута с более чем 800 КБ JS. Загрузка менее двух секунд достижима обычными инструментами; большинство магазинов, которые мы смотрим, грузятся за 3–5. Раздутость никогда не появляется из-за одной большой вещи — это десять средних, которые никто не оспорил.

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

Как безопасно тестировать чекаут

Чекаут — плохое место для агрессивных экспериментов. Вариант, снижающий конверсию на 3% пока идёт тест, — это реальная потеря, не learning opportunity. Наш подход: сначала полноценное инструментирование, потом гипотезы из данных, тестирование одного элемента за раз, быстрая остановка проигрышных тестов. Минимальный детектируемый эффект на чекауте небольшой — длинные тесты не нужны. Нужно чистое измерение и дисциплина останавливать тест рано, если что-то не работает.