Чому люди кидають кошик: 17 причин покинутого checkout і що перевірити за один день

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

За зведеними даними Baymard Institute, близько 70% онлайн-кошиків не завершуються покупкою. Ця цифра корисна для масштабу, але погана як ціль: частина людей лише дивиться, зберігає товар або ще не готова купувати. Нормальний магазин не перетворить кожен кошик на замовлення. Його завдання — не втрачати тих, хто вже хоче купити.

Нижче — аудит, який можна провести за один робочий день без редизайну, знижок і нового checkout-провайдера. Він дасть не список чужих best practices, а ранжований backlog саме для вашого магазину.

Коротка відповідь: перевіряйте не сторінки, а чотири види ризику

Порядок важливий. Якщо товар став невигідним після доставки, скорочення двох полів нічого не змінить. Якщо платіжний провайдер повертає помилку, переконливіші відгуки не допоможуть. Спершу причина, потім рішення.

Кошик, checkout і платіж — три різні воронки

Cart abandonment rate = 1 − покупки / створені кошики. Checkout abandonment rate = 1 − покупки / початі checkout. А payment failure rate рахується серед реальних спроб оплати. Не змішуйте їх: людина, яка поклала ноутбук у кошик для порівняння, і людина, чию карту відхилили після 3DS, потребують різних дій.

Для невеликого магазину достатньо дивитися ці показники щотижня за device, country, new/returning customer і payment method. Загальна середня легко приховує, що desktop працює нормально, а Safari на iPhone втрачає третину оплат.

17 причин покинутого checkout: сигнал, доказ і наступна дія

1–3. Ціна, доставка й coupon hunt

1. Неочікувана доставка, податки або service fee

Це не «checkout UX» у вузькому сенсі, а зміна угоди в останню хвилину. Покажіть приблизну доставку на product page, точні варіанти в кошику й повний total до введення картки. Якщо доставка справді дорога, поясніть чому або змініть economics; ховати її — лише відкладати відмову.

2. Невідомий або надто довгий термін доставки

«3–5 business days» змушує покупця рахувати календар. «Доставимо у вівторок, 18 серпня» знімає роботу. Перевірте різницю abandonment між регіонами та delivery options, а не припускайте, що всім потрібен express.

3. Поле промокоду відправляє людину шукати знижку

Велике порожнє поле виглядає як повідомлення: «десь існує ціна краща за вашу». Згорніть його в текстове посилання, автоматично застосовуйте публічні акції й дивіться, скільки сесій виходить із checkout на запити про coupon. Не лікуйте кожен покинутий кошик знижкою — так ви навчаєте чекати.

4–9. Акаунт, поля, адреси та помилки

4. Обов'язкова реєстрація

Guest checkout має бути очевидним default. Запропонуйте створити акаунт після покупки, коли дані вже введені й користь можна пояснити: tracking, швидше наступне замовлення, історія. Baymard фіксує forced account як одну з помітних причин відмови.

5. Полів більше, ніж потрібно для виконання замовлення

Видаліть company, second address line, date of birth і marketing questions, якщо вони не потрібні цьому замовленню. Billing address за замовчуванням дорівнює shipping. Один рядок імені часто краще, ніж припущення про first/last name у міжнародній аудиторії.

6. Неправильна mobile-клавіатура й відсутній autofill

Для email потрібен type="email", для телефону — type="tel", для числових полів — відповідний inputmode. Коректні autocomplete, стабільні name та id дозволяють браузеру заповнити форму. Це дрібні атрибути з дуже відчутним ефектом на телефоні.

7. Форма не приймає реальні імена й адреси

Апостроф, дефіс, довге ім'я, літера не з латиниці або інший формат індексу не є «поганими даними». Перевіряйте тільки те, що мусить бути істинним для доставки, підтримуйте Unicode й не змушуйте міжнародну адресу вдавати американську.

8. Помилки з'являються після submit або нічого не пояснюють

Показуйте помилку біля поля, людською мовою, не стираючи вже введене. Після загального «Something went wrong» людина не знає, чи повторна оплата створить дубль. Додайте безпечний recovery path і reference ID для support.

9. Неможливо змінити кількість, адресу або повернутися без втрати даних

Пройдіть checkout навмисно «неідеально»: поверніться в кошик, змініть variant, адресу й delivery method. Стан має зберігатися, total — перераховуватися, back button — не руйнувати сесію.

<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email">

<label for="postal">Поштовий індекс</label>
<input id="postal" name="postal" inputmode="numeric"
       autocomplete="shipping postal-code">

Розмітка не замінює тестування, але semantic HTML, справжні labels, autofill і inline validation — хороший мінімум. Не логуються повні адреси, карткові дані чи тексти полів у analytics.

10–13. Методи оплати, declines і технічний checkout

10. Немає звичного для ринку методу оплати

Не додавайте всі payment methods світу. Подивіться на країни, пристрої, середній чек і запити support; запропонуйте релевантні карти, wallets або локальні методи. Порядок методів теж має відповідати аудиторії, а не налаштуванню за замовчуванням провайдера.

11. Відхилення картки або 3DS веде в глухий кут

Gateway reason code має перетворюватися на корисну дію: повторити, перевірити дані, обрати інший метод або звернутися в банк. Після повернення з 3DS замовлення не повинно губитися. Окремо відстежуйте technical failures, issuer declines і fraud blocks.

12. Покупець не довіряє магазину саме в момент оплати

Довіра — не ряд кольорових security badges. Це впізнаване ім'я продавця, робочі контакти, зрозумілі повернення, очікувана валюта, повний order summary і відсутність сюрпризів. Зробіть тест: чи може нова людина за 30 секунд пояснити, хто спише гроші й що буде, якщо товар не підійде?

13. Сторінка повільна, стрибає або кнопка виглядає мертвою

Перевірте Core Web Vitals і real-user data окремо для checkout. Але важливіші конкретні збої: layout shift ховає кнопку, script блокує interaction, подвійний submit створює страх дубля, spinner не завершується. Після першого submit заблокуйте кнопку й чітко покажіть прогрес.

14–17. Пізні зміни, локалізація, distraction і bugs

14. Наявність або ціна змінюється в останню мить

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

15. Валюта, мова чи формат адреси не відповідають покупцеві

Перевірте cross-border checkout руками. Локалізований landing page з checkout іншою мовою та списанням у несподіваній валюті підриває довіру сильніше, ніж відсутність перекладу взагалі.

16. Checkout продовжує продавати замість завершувати покупку

Навігація, pop-up, cross-sell і carousel відводять увагу від єдиної задачі. Залиште важливі гарантії й summary, але приберіть усе, що відкриває новий decision loop.

17. Зламана інтеграція або рідкісний browser bug

Якщо проблема різко з'явилася в конкретний день, device або method, шукайте release, third-party script і response codes. Session recording показує що сталося; server і gateway logs — чому.

Аудит checkout за чотири години

Не закінчуйте аудит словами «checkout треба спростити». Кожна знахідка має виглядати так: на iPhone Safari 18% сесій отримують повторну postal-code error; відтворено 4/5 разів; виправляємо validation; owner — Ірина; перевіряємо error rate і purchase rate сім днів.

10 тестових замовлень, які варто провести сьогодні

Мінімальний tracking, який пояснює проблему

Для базової воронки достатньо view_cart → begin_checkout → add_shipping_info → add_payment_info → purchase. Додайте checkout_error з полями step, field_group, reason_code, payment_method і device_class. Не передавайте PII, адресу або карткові дані.

Перевіряйте, що purchase відправляється один раз і тільки після підтвердженої оплати. Revenue dashboard з дубльованими подіями заспокоює команду рівно до звірки з банком.

Що виправляти першим

Оцініть кожну проблему за формулою Impact × Confidence ÷ Effort по шкалі 1–5. Високий impact без доказів — гіпотеза. Висока confidence без обсягу — edge case. Першими зазвичай ідуть відтворювані payment bugs, hidden fees, mobile validation і forced account; косметичний редизайн — пізніше.

Зміни запускайте по одній або невеликими логічними пакетами. Запишіть baseline, сегмент, дату, очікуваний механізм і guardrail metrics: refunds, fraud, support contacts, average order value. Conversion, куплена ціною більшої кількості помилкових замовлень, — не перемога.

Поширені питання

Який середній показник покинутих кошиків?

Зведене значення Baymard — близько 70%, але воно змішує різні магазини й наміри. Порівнюйте насамперед власні сегменти та тренд.

Чому люди кидають checkout?

Найчастіше через зміну повної ціни, delivery, forced account, складну форму, відсутній метод оплати, недовіру або технічний збій. Причину треба підтвердити даними.

Який checkout abandonment rate вважати хорошим?

Універсального good rate немає: він залежить від товару, ціни, трафіку, ринку й визначення start. Корисніший показник — зміна одного й того самого сегмента після перевіреної правки.

Як зменшити покинуті кошики без знижок?

Раніше показати total і delivery date, дозволити guest checkout, скоротити форму, налаштувати autofill, виправити declines і запропонувати релевантні payment methods.

Чи потрібен guest checkout?

Так, для більшості звичайних онлайн-магазинів. Акаунт краще запропонувати після покупки, якщо він не є суттю продукту або регуляторною вимогою.

Джерела та дата перевірки

Статистику й UX-дослідження перевірено 16 серпня 2026 року за матеріалами Baymard Institute. Рекомендації щодо форм спираються на web.dev, діагностика performance — на Google Search Central. Агреговані benchmarks — орієнтир, не прогноз результату конкретного магазину.

Читайте далі: як зібрати підтримку інтернет-магазину за сім днів та як порахувати ROI автоматизації до запуску.