Начните с одного заказа и места остановки
Для доработки оформления заказа интернет-магазина мы сначала сопоставляем три источника: шаги покупателя, записи ошибок и фактические заказы. Выбираем один маршрут, воспроизводим сбой, согласуем ожидаемый результат и только затем оцениваем исправление. Так у каждой задачи появляются причина, проверка и понятный приоритет.
В отчёте по корзине смешиваются разные ситуации. Человек может сравнивать цены, отказаться от стоимости доставки, застрять в форме или оплатить заказ, который сайт всё ещё показывает неоплаченным. Сама доля незавершённых корзин не объясняет, какая из этих причин действует у вас. Начните с сегмента, где видна проблема: например, первый заказ с телефона с доставкой в пункт выдачи.
Результат аудита: карта пути, записи воспроизводимых ошибок, список доработок с зависимостями и сценарии приёмки. Для спорной причины добавляем отдельную проверку: наблюдение за покупателем, сверку статусов или проверку передачи событий.
Как мы связали корзину с доставкой в Frost Mining
В Frost Mining мы разработали собственный магазин термопаст, термопрокладок и жидкого металла. Покупатель выбирает фасовку и количество, затем службу доставки и видит её стоимость в корзине. Для этого мы подключили СДЭК, Яндекс Доставку и Почту России.
За выбором на экране продолжается работа системы. В связке со СДЭК сохраняется товарный состав заказа, данные передаются в доставку, количество товара в админ-панели уменьшается автоматически. Сотрудник работает с заказом и учётом в связанной системе. Этот путь полезно проверять целиком: верная сумма в корзине ещё не подтверждает верный состав отправления.
Реальный проект 13FOX
Стоимость доставки видна до заказа
Покупатель видит выбранную службу, город и стоимость. Команда магазина получает состав покупки для дальнейшей обработки.
Какие данные отличают отказ покупателя от сбоя
Мы просим показать путь от добавления товара до результата оплаты и сверяем события с серверными записями. В документации GA4 для этого предусмотрены события добавления в корзину, начала оформления, ввода данных доставки и оплаты, покупки. Яндекс Метрика принимает данные электронной коммерции через контейнер данных; передачу нужно настроить и проверить. Названия и формат событий зависят от выбранной системы аналитики.
К этой цепочке предлагаем добавить собственные события ошибок: поле не прошло проверку, расчёт доставки завершился с ошибкой, платёж не удалось создать. В аналитике достаточно шага и кода ошибки; телефон, адрес и реквизиты карты туда передавать не нужно. Связь с конкретным заказом для диагностики храним в защищённом журнале с ограниченным доступом.
| Сигнал | Что сверить | Какое решение принять |
|---|---|---|
| Покупатель открыл корзину и ушёл | Показывали ли итог, наличие и условия доставки; начал ли человек оформление | Проверить ясность условий и намерение купить, прежде чем менять форму |
| Остановился на адресе или пункте выдачи | Запись действий, ответ службы доставки и код ошибки | Повторить тот же адрес и состав корзины; проверить форму и интеграцию |
| Нажал оплату, завершения нет | Создан ли заказ и платёж, какой статус вернул провайдер | Разделить ошибку создания, ожидание, отказ и успешную оплату |
| Заказ оплачен, покупки в аналитике нет | Журнал платежей, запись заказа, отправка события и повторы | Исправить учёт событий; сверить уже оплаченные заказы |
Единица подсчёта должна оставаться одной. Для пути до создания заказа можно считать попытки оформления по внутреннему идентификатору, после создания связывать их с заказом и платежами. Повторные нажатия и несколько попыток оплатить один заказ учитывайте отдельно от новых покупок. Иначе изменения в отчёте легко принять за изменения поведения людей.
Запишите ошибку так, чтобы её мог повторить разработчик
Допустим, после смены города исчезает выбранный пункт выдачи, а кнопка оплаты остаётся доступной. В сообщении «доставка иногда ломается» потеряются условия ошибки. Мы предлагаем оформить одну карточку проверки и приложить запись экрана с тестовыми данными.
- Условия: устройство, браузер, вход в аккаунт или гостевой заказ, товары и варианты, количество, промокод, способ доставки.
- Шаги: открыть корзину, выбрать город и пункт, сменить город, продолжить оформление.
- Фактический результат: пункт пуст, оплата доступна; указать время проверки и текст ошибки.
- Ожидаемый результат: система просит выбрать доступный пункт, обновляет доставку и итог; заказ без обязательных данных не создаётся.
- След системы: обезличенная связь попытки с запросом доставки, заказом и платежом, если они появились.
Сначала повторяем сценарий на тестовом окружении. Затем меняем по одному условию: другой браузер, товар, город, способ доставки. Это помогает найти границу сбоя. По каждому обращению сохраняем результат проверки, включая случай, когда ошибка не повторилась.
Для проверки удобства даём человеку, который не проектировал форму, обычную задачу: выбрать товар, указать доставку и дойти до тестовой оплаты. Наблюдаем, где он останавливается, возвращается или просит объяснение; во время попытки не подсказываем. Такие наблюдения объясняют затруднения, но сами по себе не измеряют долю всех покупателей с той же проблемой. Сценарий и запись сопоставляем с событиями воронки.
Что проверить в корзине и доставке с телефона
Мы проходим оформление с открытой клавиатурой, возвратом на предыдущий шаг и сменой условий. На телефоне эти действия показывают проблемы, которые легко пропустить при просмотре макета: сообщение об ошибке остаётся выше экрана, карта перекрывает продолжение, введённый адрес пропадает после возврата.
- Состав и сумма. Изменение количества, удаление товара, скидка и доставка обновляют итог. Сервер заново проверяет цену и доступность перед созданием заказа; правило изменения цены объясняем покупателю.
- Поля. Для каждого обязательного значения определяем, зачем оно нужно выбранному способу получения. Проверка показывает конкретную ошибку рядом с полем и сохраняет остальные введённые данные.
- Получение. После смены города, службы или состава покупки заново проверяем доступность пункта и стоимость. Внутренний код пункта передаётся вместе с нужными данными заказа.
- Ожидание ответа. Пока служба считает доставку, показываем состояние загрузки. При сбое сохраняем корзину и предлагаем повтор либо согласованный альтернативный маршрут. Правило ручного расчёта обсуждаем с магазином заранее.
Гостевой заказ и заказ с аккаунтом проверяем отдельно. Если магазин требует вход, выясняем его причину: персональная цена, договорные условия, бонусы или другое правило. Затем проверяем, может ли покупатель восстановить доступ и вернуться к своей корзине. Удобство формы тесно связано с правилами продажи.
Как проверить оплату, возврат в магазин и повтор
Переход покупателя обратно на сайт ещё не подтверждает оплату. Например, в сценарии Redirect ЮKassa возвращает человека на return_url и при успехе, и при проблеме. Это прямо описано в процессе платежа ЮKassa. Мы предлагаем показывать результат по проверенному сервером статусу связанного платежа. Если оплату проводят в две стадии, сначала удерживают сумму, а затем списывают её. Ожидание списания показываем отдельно.
Если магазин настроен получать серверные уведомления платёжного провайдера, сообщение об изменении статуса приходит независимо от возвращения покупателя на сайт. В документации ЮKassa предусмотрены уведомления об изменении статуса и проверка их подлинности. При аудите проверяем настройку уведомлений, связь платежа с заказом, сумму, обработку повтора и результат сверки текущего статуса. Если человек закрыл вкладку после оплаты, сотрудник всё равно должен увидеть её результат в заказе.
Повтор после пропавшего ответа требует отдельного правила. ЮKassa использует ключ идемпотентности: тот же запрос с теми же данными и ключом получает результат исходной операции. Согласно формату взаимодействия API, это правило действует в течение 24 часов. На стороне магазина отдельно проверяем повтор создания заказа и повтор изменения остатка; ключ платежа не решает эти задачи автоматически.
Контрольный сценарий: создать тестовый заказ, прервать получение ответа, повторить действие, завершить тестовую оплату и открыть результат заново. Сверить число заказов и платежей, сумму, статус и запись для сотрудника. Ожидание оплаты, отказ и успешное завершение должны иметь разные сообщения и следующие действия.
При связи с учётом проверка продолжается после платежа: где фиксируется заказ, когда меняется доступное количество, кто видит исключение. В «Бакаеве» мы связали приложение, админ-панель и 1С через сервер синхронизации; заказ в приложении отражается в остатках админки и 1С. Для вашего проекта эти правила разберём по выбранной конфигурации. Подробнее об этой части работы рассказываем в статье об интеграции интернет-магазина с 1С.
Как принять доработку и измерить результат
Приёмка начинается с повторения на новой версии сценария, в котором возникала ошибка. Проверяем, что теперь он заканчивается согласованным результатом. Затем проверяем соседние условия: другой способ получения, промокод, отсутствующий товар, повтор оплаты и возврат на шаг назад. К каждой задаче прикладываем исходную запись, ожидаемый результат и запись повторной проверки. Для выпуска согласуем способ возврата к предыдущей версии и контроль заказов после запуска.
Технический результат можно проверить сразу: нужный сценарий проходит, сумма согласована, заказ виден сотруднику, повтор не создаёт лишнюю операцию в проверенных условиях. Влияние на покупки оцениваем после накопления данных. До выпуска фиксируем определения шагов, единицу подсчёта и период наблюдения; после выпуска используем те же правила.
Сравнение разбиваем по устройству, источнику перехода, первому и повторному заказу, доставке и способу оплаты. Учитываем изменения цен, ассортимента, наличия и акций. При достаточном потоке можно спланировать сравнение вариантов на сопоставимых группах. При малом потоке сначала опираемся на контрольные сценарии и реальные обращения, а численный вывод оставляем до появления достаточных данных.
Для первой проверки предлагаем считать долю начатых попыток оформления, которые завершились созданием заказа. Отдельно считаем долю заказов с подтверждённой оплатой среди заказов, в которых покупатель начал оплату. Повторные попытки платежа одного заказа показываем отдельным диагностическим показателем. Эти определения согласуем с магазином до выпуска.
Группы формируем по времени начала попытки и даём им одинаковое согласованное время на завершение. Ожидание списания ещё не считаем окончательной оплатой. Рядом показываем количество наблюдений, период и отмены. Денежную потерю нельзя получить простым умножением всех брошенных корзин на их стоимость: часть посетителей ещё выбирала, а часть позже вернулась. Разработка помогает устранить найденное препятствие; продвижение, цена и условия доставки влияют на результат вместе с ней.
Что влияет на смету и состав команды
Сначала мы предлагаем разобрать один торговый сценарий. Для оценки нужны каталог с вариантами товара, правила цен и скидок, маршрут заказа, службы доставки, платёжный сервис и учётная система. Полезны обезличенный пример сбоя, события воронки и текущие обращения покупателей. Если событий нет, их настройка и проверка станут отдельной частью работ.
Смету раскладываем на диагностику, проектирование пути, доработку интерфейса, серверные правила, интеграции, аналитику и тестирование. Обновление модуля, изменение полей и переработка создания заказа требуют разного объёма работы. Для каждой части фиксируем зависимость, допущение и способ приёмки; смежные переделки согласуем отдельно.
За удобство отвечает продуктовый специалист или дизайнер, за правила и интеграции отвечает разработчик. Тестировщик воспроизводит ошибку и проверяет, что доработка не нарушила соседние сценарии. Аналитик помогает согласовать события и сравнение результатов. Со стороны магазина нужен человек, который утверждает цену, доставку и обработку исключений. Один специалист может совмещать роли; ответственность за каждую проверку должна быть ясной.
Компаниям из Москвы и Санкт-Петербурга, которые работают по России, удобно начать с удалённого разбора экрана и обезличенных записей. Для проверки используем реальные условия обслуживания ваших регионов: зоны, пункты выдачи, ограничения по товару и правила оплаты. По ним определяем границы первой доработки и данные, которые ещё потребуются.
Разберём один маршрут от корзины до оплаты
Покажите каталог, правила цен, маршрут заказа и учётную систему. Мы сопоставим шаги покупателя с передачей заказа, обозначим причины для проверки и подготовим состав первой доработки с критериями приёмки. Начать можно с одного обезличенного примера сбоя.