Кинутий кошик: як знайти бар’єр перед оформленням

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

Проблема починається тоді, коли магазин не може відрізнити одне від іншого. Тоді в checkout додають промокод, змінюють дизайн або переносять сайт на іншу платформу. Бюджет витрачається, а причина лишається.

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

Такий порядок не пояснить рішення кожної людини. Зате не дасть витрачати гроші на зміни без конкретної проблеми. Спершу треба зрозуміти, чи покупець передумав, чи магазин не дав йому завершити дію.

Що таке кинутий кошик?

Різні стани кошика

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

В одному звіті не варто зводити в одну категорію різні стани:

• товар лишився в кошику, а до оформлення людина не перейшла;
• checkout відкрили, але не дійшли до підтвердження;
• покупець перейшов до оплати, але платіж не отримав підтвердження;
• замовлення створилося, але потім його скасували.

Це різні точки процесу. Для них потрібні різні перевірки. Якщо товар лишився в кошику, дивляться на картку товару, суму й перехід до оформлення. Якщо не підтвердився платіж, перевіряють повернення з платіжної сторінки та статус замовлення. Скасоване замовлення вже не є незавершеним checkout: для нього треба окремо розбирати причини скасування.

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

Де зупиняється шлях до замовлення

Ланцюг контрольних точок

Checkout варто перевіряти як ланцюг контрольних точок, а не як одну сторінку з кнопкою оплати. Почніть із картки товару. Чи видно, що товар доступний? Чи зрозуміло, який варіант обрано? Чи збігається ціна в картці з ціною після додавання до кошика?

Сторінка товару також має відповідати запиту, з яким людина прийшла з пошуку. Це окрема задача для Що таке SEO та просування сайту: простими словами для бізнесу. SEO не виправляє checkout, але невідповідна картка товару може привести в кошик людину, яка шукала інше.

Далі відкрийте кошик. Чи зрозуміла підсумкова сума? Чи видно вартість доставки або умови, від яких вона залежить? Чи можна змінити кількість, прибрати товар і повернутися до покупки без втрати вибору?

На переході до оформлення перевірте, чи очевидний наступний крок. Під час вибору доставки запитайте: чи доступні умови до переходу на оплату? Чи пояснює інтерфейс, чому спосіб доставки недоступний?

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

Остання точка — сторінка успішного замовлення. Вона має відрізнятися від простого повернення з оплати. Інакше неможливо зрозуміти, де обірвався шлях: до замовлення, під час платежу або після створення заявки.

Як не переплутати поломку з відкладеною покупкою

Повторіть сценарій руками

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

Потім звірте маршрут із доступною аналітикою. Чи видно перехід у кошик? Чи фіксується відкриття оформлення? Чи є ознака повернення з платіжної сторінки? Назви подій залежать від того, що вже налаштовано у вашому магазині. Не створюйте у звіті події, яких система не збирає.

Окремо перевірте результат після оплати. Повернення на сайт ще не означає, що замовлення створилося. Зіставте повідомлення для покупця зі статусом замовлення в адмінчастині.

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

Відкладена покупка не завжди має технічну причину. Але це не привід вважати будь-який вихід із checkout звичайною відмовою. Спершу виключіть те, що можна перевірити: помилку, неясну умову, втрату даних, недоступну оплату.

Перевірка checkout руками до будь-яких змін

Записуйте зміни стану

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

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

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

Нижче — приклад внутрішньої схеми для нотаток. Назви подій умовні. Це не код для копіювання і не специфікація конкретної системи.

• view_item
• add_to_cart
• view_cart
• begin_checkout
• add_shipping_info
• add_payment_info
• form_error
• payment_confirmed
• purchase

Після проходу не виправляйте все одразу. Спочатку сформулюйте проблему так, щоб її можна було повторити: дія, умова, очікуваний результат і фактичний результат. Це дає розробнику задачу, а не загальне «оформлення незручне».

Що змінювати після перевірки, а що не чіпати

Змінюйте підтверджені проблеми

Після перевірки змінюйте не те, що виглядає підозріло, а те, що можна описати й повторити. Пріоритет простий: усунути відтворювану помилку, прояснити умову, прибрати непотрібну дію. Лише потім оцінювати тексти або макет.

Не давайте знижку всім, хто залишив кошик. Це не пояснює, чому людина не змогла оплатити або не зрозуміла доставку. Не перетворюйте форму на анкету. Кожна додаткова дія потребує причини.

Якщо обмеження checkout не дає виконати потрібну бізнес-логіку, спочатку запишіть її без назв платформ і готових рішень. Потім можна планувати зміни та бюджет через сторінку Вартість.

Коли checkout треба перебудовувати, а не латати

Вимоги до логіки checkout

Перебудову checkout варто обговорювати, коли проблема не зводиться до одного поля, тексту помилки або невдалого переходу. Наприклад, правила товарів не вкладаються в доступну логіку доставки. Або оформлення не дозволяє змінити кроки, без яких магазин не може працювати.

Не кожне обмеження означає, що потрібен новий сайт. Спершу відокремте проблему в інтерфейсі від обмеження, яке неможливо прибрати в поточній системі. Якщо працівники вручну виправляють статуси, переносять дані між системами чи обходять правила доставки, цей процес варто описати. Без припущень: що саме робить людина, після якої дії та якого результату намагається досягти.

Окремий сигнал — статус замовлення не передається туди, де його мають обробити. Інший — зміна checkout працює зараз, але її неможливо підтримувати без нових обхідних дій.

Перед розмовою про реалізацію запишіть вимоги до:

• кошика й правил товарів;
• доставки та умов її доступності;
• оплати й повернення після неї;
• статусів замовлення;
• адмінчастини;
• інтеграцій із зовнішніми системами.

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

Коли вимоги сформульовані, їх можна обговорювати як задачу для Інтернет-магазини. Так легше зрозуміти, чи достатньо локальної зміни, чи поточний checkout не витримує потрібну логіку.

Нагадування про кошик не замінює перевірку

Спочатку усуньте бар’єр

Нагадування про кинутий кошик доречне лише після того, як оформлення пройдено руками й зрозуміло, що воно не зупиняє покупця помилкою або незрозумілою умовою. Це сценарій повернення до вже зібраного кошика, а не спосіб прикрити проблему в оплаті, доставці чи формі.

У повідомленні можна дати людині шлях назад до кошика та повторити умови, які вона вже бачила: склад замовлення, доставку, оплату. Не варто змінювати правила між кошиком і нагадуванням. Якщо доставка має обмеження, їх не ховають за посиланням або дрібним текстом.

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

Контактні дані не можна збирати чи використовувати автоматично без перевірки правової підстави для конкретного ринку й способу зв’язку. Тут краще звірити процес із юристом, а не переносити чужий сценарій у свій магазин.

Спочатку прибирають підтверджений бар’єр. Потім вирішують, чи потрібне нагадування.

Кому не потрібна окрема кампанія для кинутих кошиків

Підстава для контакту

Окрема кампанія не потрібна магазинам, де немає підстав повертати покупця окремим повідомленням: наприклад, якщо кошик не передбачає контакту для зв’язку або магазин не може законно використовувати ці дані для нагадування.

Також кампанія не потрібна, якщо звернення після повернення кошика нікому обробляти або якщо магазин не може підтримати обіцяні в повідомленні умови.

Бюджет на зміни варто планувати після сформульованих вимог, а не до них. Для цього можна переглянути сторінку Вартість.

FAQ