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

Якби потрібно було вибрати одну сторінку, яку зробити швидшою та надійнішою — це чекаут. Не головна, не лістинг — чекаут. На магазині з €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. Наш підхід: спочатку повноцінне інструментування, потім гіпотези з даних, тестування одного елемента за раз, швидка зупинка програшних тестів. Мінімальний виявлюваний ефект на чекауті невеликий — довгі тести не потрібні. Потрібне чисте вимірювання і дисципліна зупиняти тест рано, якщо щось не працює.