Брошенная корзина: почему покупатель не завершает заказ

Брошенная корзина интернет-магазина: как найти препятствия в оформлении, проверить оплату и измерить результат. Примеры, события и план доработки.

Автор: Виктория Сидорова, Product Designer, 404gen.

Покупатель выбрал товар. Сравнил характеристики. Положил в корзину. Дошёл до оформления — и исчез. В отделе маркетинга уже обсуждают цепочку писем, скидку и красную кнопку. Где-то между этими обсуждениями стоит человек, которого сайт заставил завести аккаунт, угадать стоимость доставки и повторно набрать адрес. Его объявили брошенной корзиной. Он, возможно, считает себя выжившим.

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

Корзина ещё не обещание купить

Разделяйте интерес к товару и готовность заключить сделку. Человек может использовать корзину как список сравнения, проверять итоговую сумму, собирать заказ для согласования или просто откладывать выбор. У интернет-магазина возникает запись в базе, но у посетителя не появляется моральное обязательство оплатить её до конца рабочего дня. Отсюда первый неудобный вывод: вернуть каждую корзину нельзя, а считать любую незавершённую покупку потерянной выручкой — слишком смело.

Для B2B-магазина это особенно заметно. Снабженец проверил состав заказа, переслал коллегам и ждёт решение. Ему нужен сохранённый список с ценой, доступностью и сроками, а не письмо «Вы забыли кое-что прекрасное». Другой посетитель понял, что товар не подходит, и ушёл совершенно осознанно. Третий хотел купить, но столкнулся с ошибкой формы. Одна метрика объединяет три разные истории. Если лечить их одной скидкой, диагноз останется неизвестным, а маржа уже начнёт испытывать дискомфорт.

Сначала договоритесь о единице учёта. Это уникальная корзина, пользователь, сеанс или попытка оформления? Что считается завершением: созданный заказ, подтверждённый платёж, согласованный счёт? Как долго ждём покупку? Для заказа с оплатой по счёту и для доставки готового товара возможны разные окна наблюдения. Без этого отчёт меняется от настроек аналитики быстрее, чем от улучшения сайта.

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

Разложите исчезновение на наблюдаемые события

Полезная воронка показывает переходы между состояниями. Добавили товар, открыли корзину, начали оформление, получили доступные способы доставки, выбрали оплату, создали заказ, подтвердили платёж. У каждого события есть смысл и идентификатор, позволяющий связать его с тем же заказом. В документации Google Analytics по ecommerce предусмотрены отдельные события для корзины, начала оформления, данных доставки, оплаты и покупки. Это пример устройства измерения, а не требование выбрать именно этот сервис.

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

Ошибки нужно видеть рядом с переходами: недоступный способ доставки, отказ оплаты, истечение сессии, ответ сервера, повторная попытка. Для диагностики достаточно технического кода, этапа, устройства и версии интерфейса. Адреса, содержимое комментариев и платёжные сведения не стоит тащить в обычные журналы «на всякий случай». Наблюдаемость должна объяснять сбой, не становясь дополнительным хранилищем личной переписки клиента.

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

Сначала условия, потом телефон

Покажите человеку то, что способно изменить решение, до сбора длинной анкеты. Итоговую сумму, доступность товара, условия доставки и срок получения. В разборе оформления заказа Baymard Institute среди заметных препятствий рассматриваются дополнительные расходы, обязательный аккаунт и неудобный ввод данных. Их наблюдения полезны для списка проверок; частоты из зарубежного исследования нельзя автоматически приписывать вашему российскому магазину.

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

Если срок зависит от склада, уточняйте его на уровне позиции. Обещание «быстрая доставка» у смешанного заказа мало помогает. Клиенту нужно знать, что одна позиция доступна сейчас, а другая требует ожидания; можно ли разделить отправки и как изменится сумма. При этом не подменяйте неизвестность точной датой из воображения. Формулировка «Подтвердим срок после проверки наличия» бывает полезнее уверенного календаря, который отдел логистики увидит впервые.

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

Регистрация — хороший слуга и плохой шлагбаум

Спрашивайте, зачем аккаунт необходим до заказа. Если он нужен только для будущих повторных покупок, его можно предложить после полезного результата. Если действуют индивидуальные B2B-цены, ограничения доступа или согласование условий, вход может быть обязательным. Тогда посетителю стоит сразу понять, что он получает после авторизации и сколько займёт получение доступа. Главное — не применять один сценарий ко всем бизнес-моделям ради единообразия макетов.

Гостевой заказ не означает, что системе запрещено сохранить контакты или выдать ссылку на статус. Это вопрос архитектуры конкретного магазина. Разведите учёт заказа и постоянную учётную запись. Человек может завершить покупку, а затем решить, нужен ли ему кабинет. Для более сложных сценариев полезен отдельный разбор личного кабинета интернет-магазина: история, возвраты и повторное оформление имеют другую задачу, чем первый проход через кассу.

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

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

Каждое обязательное поле должно защищать конкретную операцию

Вопрос к полю не «интересно ли нам это знать», а «без этого нельзя выполнить текущий заказ?». Для доставки нужен адрес; для самовывоза он может не понадобиться. Для юридического лица нужны определённые реквизиты; частному покупателю полный набор не подходит. Выбор режима должен менять форму осмысленно. Список полей, скопированный из CRM, редко совпадает со списком сведений, которые клиент готов ввести сейчас.

Предусмотрите нормальный человеческий ввод. Автозаполнение, вставку из буфера, разные допустимые написания адреса, длинную фамилию, номер с пробелами. Маска должна помогать, а не спорить с клавиатурой. Покупатель не сдаёт экзамен по вашей внутренней модели данных. Если система способна безопасно нормализовать значение, полезно делать это явно и проверяемо, не требуя от человека угадывать единственно правильную раскладку.

Ошибку показывайте рядом с причиной и объясняйте исправление. «Неверные данные» не говорит, что именно не подошло. «Не удалось проверить адрес. Уточните дом или выберите точку на карте» уже даёт действие. Сохранённый ввод после ошибки ценнее, чем сердечный тон сообщения. Человек может простить сухой текст. Повторный набор всех полей он переживает как увольнение из собственного заказа.

Сложные требования лучше вводить последовательно. Например, сначала определить тип покупателя и доставку, затем показать относящиеся к ним сведения. Это не универсальная рекомендация разбить форму на максимальное число шагов. Разделение должно сокращать ненужный ввод и сохранять обзор суммы. Проверяйте сценарий на реальных данных: пустой красивый макет не обнаруживает неприятности с длинными названиями и несколькими адресами.

На мобильном главный враг может оказаться клавиатурой

Проверяйте оформление на устройстве, где его действительно проходят. Экранная клавиатура перекрывает кнопку, список вариантов уходит за пределы, карта требует точного попадания, уведомление об ошибке появляется вне видимой области. На десктопном макете всё это не выглядит проблемой. Телефон превращает запас пространства в предмет роскоши, поэтому важна иерархия: текущее действие, его результат, сумма и возможность вернуться к предыдущему выбору.

Особенно внимательно смотрите на переходы в сторонние приложения. Оплата, подтверждение, просмотр почты или карты доставки временно выводят человека из магазина. После возврата нужно восстановить правильный заказ, а не открыть случайную стартовую страницу. Проверяйте переход назад, повторный вход, обновление и потерю связи. Если приложение банка вернуло клиента, магазин обязан объяснить, что известно о платеже в этот момент.

Не превращайте фиксированные элементы в бутерброд. Сверху меню, снизу кнопка покупки, поверх cookie, рядом чат — и заказ виден через щель. Считайте доступную область с открытой клавиатурой. Видимость обязательного пояснения и согласованного действия важнее, чем одновременное присутствие всех маркетинговых инструментов. Если под кнопкой невозможно прочитать итоговые условия, закрепление ухудшает задачу, которую должно было упрощать.

Приёмка мобильного оформления должна включать разные размеры экрана и ввод пальцем. Важны также медленная сеть и длинная корзина. Удачный заказ на одном современном телефоне при хорошем Wi-Fi — необходимый, но маленький фрагмент проверки. Стоит заранее составить матрицу устройств и браузеров, поддерживаемых проектом, чтобы после запуска команда не спорила, считать ли популярную конфигурацию экзотикой.

Нажатие «Оплатить» — начало ожидания, а не финал истории

Разведите заказ, попытку оплаты и подтверждённый результат. Открытие платёжной формы ещё не означает списание. Возвращение на сайт может произойти раньше, чем сервер получит окончательный статус. В документации Stripe о Payment Intents платёж описывается через жизненный цикл и отдельные статусы, а сервер проверяет завершение. Это пример инженерной модели; доступность Stripe для вашего бизнеса и выбор провайдера требуют отдельной проверки.

Состояние ожидания должно быть видимым и безопасным: «Проверяем оплату», номер заказа, время следующей проверки, способ вернуться к статусу. Кнопка «Попробовать снова» не должна бездумно создавать новый заказ и второе списание. Когда человек нажал дважды из-за задержки, система должна понимать, какие запросы относятся к одной операции. Конкретный механизм идемпотентности согласуется с сервером и платёжным провайдером.

При отказе сохраните состав заказа и покажите возможный следующий шаг. Другой способ оплаты, повторная проверка статуса или обращение в поддержку — разные действия. Не пишите «Деньги не списаны», если это ещё неизвестно. Уверенный текст в такой ситуации легко превращается в дополнительную претензию. Лучше честно сообщить известный статус и объяснить, как получить окончательное подтверждение без новой случайной попытки.

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

Не заставляйте корзину обещать то, чего нет на складе

Доступность и цена могут измениться между выбором и оформлением. Объясняйте изменение до подтверждения заказа и указывайте, к какой позиции оно относится. Если часть товара закончилась, сохраните остальное и предложите понятные варианты. Полное обнуление корзины из-за одной проблемной строки — необычный способ сообщить клиенту, как сильно вы цените его время.

Не каждая корзина обязана резервировать товар. Это решение зависит от бизнеса, платёжного процесса и нагрузки. Но команда должна знать, в какой момент создаётся резерв и как он освобождается. Иначе сайт уверенно принимает заказ, склад уже отдал последнюю единицу, а виноватым выглядит менеджер. Здесь UX пересекается с учётом: красивое «Есть в наличии» требует конкретного источника и правил обновления.

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

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

Помощь нужна в месте сомнения

Дайте человеку возможность спросить о том, что мешает текущему заказу. Уточнить совместимость, срок или документы. Поддержка должна получать достаточный контекст с разрешённым доступом: какая корзина и какой этап, а не начинать беседу с просьбы перечислить все товары заново. Если вопрос закрывается подсказкой, показанной вовремя, чат может вообще не понадобиться.

При этом помощник не должен перекрывать оформление и самовольно менять условия. Ответ «Да, доставим завтра» требует источника. Ответ «Ваш заказ уже оплачен» требует проверенного статуса. Для сложных вопросов полезнее передача сотруднику со сведениями о проблеме. Обычный чат и ИИ-помощник одинаково вредны, когда уверенность ответа превосходит знания системы.

Посмотрите на обращения в поддержку как на данные о проектировании. Повторяющиеся вопросы «Где узнать доставку?» или «Нужно ли регистрироваться?» показывают, что информация находится не там, где её ищут. Решение может быть короткой фразой и исправленным порядком шагов. Новый бот в этом случае будет дорогим способом рассказывать каждому человеку то, что можно было нормально написать один раз.

Согласуйте, что происходит вне рабочего времени и при долгом ожидании. Честная форма запроса с сохранённым контекстом предпочтительнее видимости мгновенной помощи. Кнопка «Задать вопрос» должна объяснять дальнейший маршрут и не создавать ощущение, что заказ уже принят. Разделите намерение связаться, обращение в поддержку и оформление покупки, чтобы они не смешивались в отчёте о конверсии.

Письмо о корзине начинается после проверки самой корзины

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

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

Не называйте каждый заказ после письма эффектом письма. Человек мог вернуться самостоятельно. Сравнение с группой, которая не получила сообщение, при сопоставимых условиях помогает отделить влияние кампании от обычного повторного визита. Где такой эксперимент невозможен, честно укажите ограничение и не складывайте все последующие покупки в заслуги одной рассылки.

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

Сначала честная арифметика, потом победный кейс

Возьмём явно условный пример. За период создано 1 000 уникальных корзин, 400 дошли до начала оформления, 200 стали подтверждёнными заказами. Если считать незавершённые относительно всех корзин, получится 800 из 1 000. Если оценивать отказ после начала оформления — 200 из 400. Оба числа могут быть корректны, но отвечают на разные вопросы. Смешать их в сравнении «до и после» значит нарисовать эффект сменой знаменателя.

Допустим, после изменения 440 пользователей начали оформление и 230 завершили заказ. До завершения от всех корзин — 23% вместо 20%, если корзин снова 1 000. Но качество трафика, ассортимент, период и акции нужно проверить отдельно. Разница в три процентных пункта не равна росту на три процента. Это базовая арифметика, которую почему-то регулярно отправляют на заслуженный отдых ради красивого заголовка.

Для оценки денег нужны не только заказы: возвраты, переменные затраты, влияние скидок, стоимость доставки и поддержки. Объём может вырасти вместе с долей проблемных покупок. Условные расчёты в статье объясняют способ рассуждения, а не прогнозируют результат для клиента. Фактический эффект доработки устанавливается по данным конкретного магазина и согласованному дизайну сравнения.

Держите рядом защитные метрики. Ошибки оплаты, повторные списания, незавершённые резервы, отмены из-за отсутствия товара и обращения в поддержку. Улучшение прохождения интерфейса не должно покупать успех за счёт операций после него. Если новая кнопка позволяет легко оформить то, что магазин не может выполнить, рост конверсии окажется премией за создание лишней работы.

Что собрать до первой встречи с разработчиками

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

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

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

После этого можно обсуждать разработку и доработку интернет-магазина. В состав этапа включайте не только экран, но и данные, серверные состояния, измерение и приёмку. Детали визуальной иерархии и форм разобраны в материале про UX/UI-дизайн. Здесь же важно связать изменение интерфейса с конкретным препятствием и способом проверить результат.

Приёмка: один успешный заказ и несколько неудобных

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

Проверяйте сообщения глазами человека. Если ошибка не даёт следующего действия, серверный контракт выполнен лишь наполовину. Если заказ принят, должна быть узнаваемая запись с номером и согласованными условиями. Если принят только запрос на уточнение, это нельзя подписывать «Покупка завершена». Ясность статуса полезна и покупателю, и отделу продаж, которому потом объяснять происходившее.

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

После запуска смотрите не только на общую конверсию, но и на устранённую причину. Перестал ли сбрасываться адрес? Появляется ли окончательная сумма вовремя? Восстанавливается ли платёж? Если гипотеза не подтвердилась, сохраните результат и ищите следующую. Такая дисциплина звучит скромнее обещания «поднять продажи на десятки процентов», зато позволяет действительно понять, куда вложить следующий бюджет.

Что делать завтра, пока большой редизайн ещё в переписке

Соберите один заказ сами с телефона, затем попросите человека, не участвовавшего в проекте, пройти тот же маршрут без подсказок. Пусть проговаривает, что знает и чего ждёт. Не защищайте интерфейс объяснением «это же очевидно». Если очевидность требует сопровождения автора макета, покупателю она бесплатно не достанется. Зафиксируйте вопросы и место каждого затруднения.

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

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

Хорошая работа с брошенной корзиной возвращает человеку возможность завершить начатое. Иногда нужен сохранённый выбор, иногда прозрачная доставка, иногда исправленный платёж. И лишь после этого — уместное напоминание. Начать можно с простого вопроса: ваш магазин сейчас помогает купить или торжественно оформляет право попытаться? Ответ стоит проверить на реальном маршруте, прежде чем вооружать его ещё одной рассылкой.

Частые вопросы

Чем брошенная корзина отличается от незавершённого оформления?

В корзине есть выбранные товары, но человек мог ещё не начать оформлять заказ. Незавершённое оформление относится к более узкому этапу: посетитель уже перешёл к данным заказа, доставке или оплате. Для сравнения нужно определить единицу учёта, окно наблюдения и событие завершения. Эти показатели нельзя взаимозаменять.

Нужно ли сразу делать рассылку о забытых товарах?

Сначала полезно проверить, доступна ли покупка без технических препятствий и неожиданного изменения условий. Сообщение не устранит сброс формы, недоступную доставку или ошибку оплаты. Для напоминания нужны актуальная корзина, разрешённый канал, остановка после покупки и понятный переход к сохранённому заказу.

Как оценивать эффект изменения корзины?

Сравнивать прохождение одинаковых этапов на сопоставимых аудиториях и периодах. Отдельно проверять состав трафика, акции, ассортимент и технические ошибки. Дополнять завершённые заказы данными об отменах, возвратах и вкладе после переменных затрат. Учебные числа показывают арифметику, но не прогнозируют результат для конкретного магазина.

Что должно входить в приёмку оформления заказа?

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