Аудит интернет-магазина начните с тестового заказа на телефоне и сверки статусов оплаты. Так можно найти, где покупка прерывается, и понять, какую доработку поставить первой.
Покупатель оплатил заказ и закрыл вкладку банка. У платёжного сервиса операция прошла, а в магазине заказ остался неоплаченным. Менеджер отправил покупателю ссылку на оплату ещё раз. В отчёте по воронке этот случай легко принять за обычный уход на шаге оплаты.
Такие проблемы редко видны на скриншотах интерфейса. Нужно пройти покупку, посмотреть, что зафиксировала аналитика, и сверить заказ в системах, через которые он прошёл. Для первой проверки хватит одной покупки, которую команда может проследить от выбора товара до подтверждения оплаты. Дальше станет ясно, где искать причину и какие сценарии проверить рядом.
Начните с товара, который покупатели действительно заказывают. Откройте магазин на телефоне без сохранённого входа. Выберите нужный вариант, положите товар в корзину, укажите адрес и дойдите до подтверждения. Полный тест оплаты лучше провести в тестовой среде. Если часть интеграций там отличается от рабочего сайта, согласуйте контролируемый заказ и заранее решите, как отмените его после проверки.
Во время прохода сохраняйте номер заказа, время и шаг, на котором что-то пошло иначе, чем ожидалось. Для сбоя до создания заказа пригодятся запись экрана, адрес страницы и выбранный товар. С такими данными разработчик сможет повторить покупку или найти связанные записи в журнале. Формулировка «иногда пропадает доставка» оставляет ему почти весь поиск с нуля.
Следующий проход выберите по условиям магазина. Если цена доставки зависит от города, смените город после выбора пункта выдачи. Если у товара есть размеры, проверьте два варианта с разными остатками. Задача первого прохода простая: увидеть, какие данные передаются дальше и в какой момент они расходятся с тем, что видел покупатель.
Воронку лучше читать по отдельным событиям. Просмотр карточки, добавление товара, начало оформления, создание заказа и успешная оплата отвечают на разные вопросы. Например, в электронной коммерции Яндекс Метрики add передаёт добавление товара в корзину, а purchase сообщает о покупке. Какой момент сайт считает покупкой, зависит от настройки передачи данных. Это стоит проверить на тестовом заказе перед сравнением конверсии.
Если отчёт показывает резкое падение после выбора доставки, проверьте сам шаг. Введите адрес, который обслуживает магазин, и посмотрите, сработало ли событие. Затем повторите покупку с адресом, для которого часть способов недоступна. Возможно, отчёт объединяет ситуацию, когда человек увидел дорогую доставку и ушёл, с ситуацией, когда форма вообще не дала ему продолжить.
Сравнивайте покупки в сопоставимых условиях. В мобильную воронку может приходить больше посетителей по акции, а на компьютере чаще оформляют заказы постоянные клиенты. Разница между устройствами подсказывает, где искать, но сама по себе не объясняет причину. Если событий мало, начните с просмотра конкретных заказов и проверки сценария вручную.
В карточке проверьте, может ли покупатель выбрать нужный вариант товара и узнать условия покупки до оформления. Если фотография меняется при выборе цвета, проверьте, что в корзину ушёл артикул именно этого цвета. Если размер доступен только в одном городе, убедитесь, что карточка и корзина одинаково объясняют ограничения. Отдельно посмотрите, что происходит, когда человек возвращается к карточке из корзины и меняет выбор.
В корзине сверьте состав заказа и итоговую сумму. Удалите позицию из заказа с промокодом, измените количество товара и вернитесь с шага доставки. Если скидка перестала действовать, магазин должен показать новую сумму и объяснить изменение до оплаты. Покупатель также должен видеть, какой товар и в каком количестве он оплачивает после всех правок.
В одном проекте для магазина товаров для интерьера команда Фортех (fortech.dev) доработала корзину и реализовала покупку в один клик с выбором размера и рамки. Для такого сценария у доработки интернет-магазина есть конкретная проверка: после сокращённого оформления в заказ должны попасть те размер и рамка, которые выбрал покупатель.
Остатки проверяйте в момент, когда количество товара меняется между добавлением в корзину и подтверждением заказа. Положите в корзину последнюю единицу и воспроизведите продажу этой единицы через другой канал, если магазин работает с общим складом. Затем попробуйте завершить первый заказ. Результат зависит от правил резерва: магазин может удерживать товар с момента оформления или проверять доступность позже. Команде нужно знать, какое правило действует, и убедиться, что покупатель получает понятное сообщение при изменении остатка.
Для доставки проверьте смену города, адреса и способа получения. Допустим, покупатель выбрал пункт выдачи, а затем поменял город. Старый пункт нужно сбросить, доступные способы пересчитать и показать новую сумму до подтверждения заказа. Сверьте эти данные с тем, что увидит менеджер. Бывает, что экран уже показывает новый адрес, а в заказе сохранился прежний.
Для каждого расхождения определите, где хранится верное значение. Если склад передаёт доступность в 1С, а сайт показывает старый остаток, начните с времени последнего обновления и записи обмена по этому артикулу. Если данные совпадают до смены города, а потом расходятся, проверьте обработку изменения адреса.
Оплату проверяйте по номеру заказа и идентификатору платежа. Сравните сумму и состояние операции в магазине, у платёжного сервиса и в учётной системе. Если клиент закрыл страницу после подтверждения платежа, заказ всё равно должен получить правильный статус. В интеграции с ЮKassa, например, о переходе платежа в состояние succeeded можно узнать через входящее уведомление payment.succeeded. Возврат покупателя на сайт и получение магазином такого уведомления происходят отдельно. Документация ЮKassa
Проверьте три сценария. В первом оплата прошла, но покупатель закрыл вкладку. Во втором подтверждение пришло с задержкой. В третьем магазин повторно получил уведомление по тому же платежу. Во всех случаях сверяйте итоговое состояние заказа, уведомление покупателя и данные, которые видит менеджер. Повторная обработка уже учтённого платежа не должна создавать второй заказ или повторно менять сумму.
Если покупатель видит предложение оплатить ещё раз, прежде чем менять экран выясните, какое состояние получил сайт. Иногда платёж подтверждён, но статус ещё не дошёл до магазина. Иногда банк отклонил платёж и повторная попытка действительно нужна. Для этих ситуаций у интерфейса должны быть разные действия и сообщения.
Первой берите подтверждённую проблему, которая прерывает покупку, приводит к повторной оплате или отправляет в работу заказ с неверными данными. Затем смотрите, сколько покупок затрагивает сбой и можно ли обойти его до исправления. Ошибка, из-за которой один способ оплаты недоступен в конкретном браузере, и ошибка, из-за которой менеджеры по всем заказам вручную сверяют статус, требуют разной срочности.
Запишите для каждой проблемы три вещи: что случилось, какие заказы затронуты и чем команда подтвердит исправление. Например, при смене города сохраняется прежний пункт выдачи. Сбой подтверждён тестовым заказом и обращениями покупателей. После исправления старый пункт сбрасывается, цена доставки пересчитывается, а новый адрес совпадает на экране, в заказе и в системе менеджера.
Если в воронке видно падение, но причина ещё неизвестна, поставьте задачу на проверку гипотезы. Например, сравните стоимость доставки, показанную до оформления, с суммой после ввода адреса. На этом этапе полезнее воспроизвести расхождение, чем согласовывать редизайн всей корзины. Редизайн имеет смысл оценивать отдельно, когда команда понимает, какие действия покупателю трудно выполнить в текущем интерфейсе.
Доработку принимайте по исходному сценарию сбоя и соседним случаям. Если исправляли статус после оплаты, повторите заказ с успешным, отклонённым и отложенным платежом. Проверьте, что менеджер видит актуальное состояние, покупатель получает соответствующее сообщение, а в аналитике нет лишней покупки при повторном открытии страницы подтверждения.
После выпуска сравните показатель, ради которого делали работу. Для оплаты подойдёт доля успешно оплаченных заказов, которые остались в магазине со статусом «не оплачен». Для доставки можно посчитать долю ошибок при выборе пункта выдачи среди оформлений с самовывозом. Так будет видно, изменилась ли частота именно того сбоя, который команда исправляла.
Общая конверсия тоже пригодится, но на неё влияют ассортимент, акции и источники посетителей. Если в неделю выпуска началась распродажа, сравнение с обычной неделей плохо изолирует эффект доработки. Проверьте сам сценарий на реальных заказах и отдельно посмотрите, как ведёт себя нужный шаг воронки после того, как наберутся сопоставимые данные.
Для первой проверки возьмите один популярный товар и оформите заказ с телефона. Сохраните номер заказа, проверьте его путь по системам и сформулируйте один результат, по которому команда сможет принять исправление.
Можно ли провести аудит интернет-магазина без настроенной аналитики?
Да. Контрольная покупка и сверка заказа помогут найти воспроизводимые сбои. Чтобы понять, сколько покупателей с ними сталкивается, понадобятся данные воронки, журналы ошибок или история обращений.
Как понять, что магазин теряет заказы именно на оплате?
Сопоставьте попытки оплаты, подтверждённые платежи и статусы заказов. Если платёж подтверждён, а заказ висит как неоплаченный, проверьте обмен статусами. Если до платёжной формы не доходят, ищите причину раньше, на шаге создания заказа.
Что делать, если ошибка возникает только иногда?
Соберите примеры с номером заказа, временем, способом оплаты или доставки и устройством. Ищите общее условие. Например, проблема возникает только при смене города или после возврата в корзину из платёжной формы.
Когда после доработки смотреть на конверсию?
Когда наберётся достаточно покупок в сопоставимых условиях. Исправление конкретного сбоя можно проверить сразу после выпуска на контрольном заказе, а затем подтвердить по рабочим данным.
БизнесРассказываем, как сделать свой маркетплейс - стоимость и сроки создания. Создаем маркетплейс с нуля в 2024 году.
Читать
БизнесАутстаффинг в России к 2026: тренды рынка, преимущества модели и прогнозы экспертов. Узнайте, как изменится найм IT-специалистов
Читать
РазработкаЧек-лист аудита мобильного приложения на 40 пунктов: код, безопасность и 152-ФЗ, производительность, интерфейс, релизы в сторах и аналитика
Читать
