Короткий ответ
Не начинайте с нового дизайна. Сначала выясните, где обрывается покупка: до выбора товара, в корзине, при оплате или уже после оформления. Затем отделите реальную проблему магазина от ошибки в учёте. Один и тот же график «много посещений, мало покупок» может потребовать совершенно разных действий.
1. Сначала разделите три разные проблемы
Перед обсуждением конверсии сопоставьте магазин, платёжную систему и аналитику. Есть ли созданные заказы? Какие действительно оплачены? Какие отменены или возвращены? Что из этого отражено в отчёте? Зафиксируйте период, часовой пояс, валюту и выбранный статус заказа.
«Заказ создан», «оплата подтверждена» и «покупка попала в аналитику» — разные проверки. При оплате после доставки они тем более не должны означать одно и то же. Не меняйте определение успешного результата между периодами.
| Что наблюдаете | Что проверять первым | Какой вывод пока делать нельзя |
|---|---|---|
| В аналитике нет покупок, в магазине они есть | Передачу событий и условия включения данных | «Нужно переделать магазин» |
| Нет заказов и попыток оформления | Трафик, предложение, выбор товара | «Во всём виновата платёжная система» |
| Оформление начинается, но не завершается | Форму, доставку, оплату, сообщения об ошибках | «Все пользователи считают цену высокой» |
| Деньги поступили, заказ не виден команде | Подтверждение оплаты и передачу заказа | «Покупатель передумал» |
| Есть заказы, но много отмен и возвратов | Наличие, описание, исполнение и причины возврата | «Рост покупок уже означает рост прибыли» |
Сохраните несколько конкретных примеров с датой и идентификатором заказа. Одного общего скриншота графика недостаточно, чтобы локализовать разрыв. В публичном отчёте удалите персональные данные.
2. Проверьте, что аналитика действительно считает покупки
GA4 предусматривает отдельные события для просмотра товара, корзины, оформления, покупки и возврата. Их нужно корректно передавать: одного счётчика просмотров страниц недостаточно. 1
Предлагаем согласовать с разработчиком короткую карту измерения. Названия событий ниже относятся к GA4; это не готовый код для вставки и не требование использовать именно эту систему.
| Событие GA4 | Что обозначает | Что воспроизвести при проверке |
|---|---|---|
| view_item | Просмотр товара | Открыть реальную карточку |
| add_to_cart | Добавление в корзину | Проверить выбранные размер и цвет |
| begin_checkout | Начало оформления | Начать оформление из корзины |
| add_shipping_info | Передача сведений о доставке | Убедиться, что адрес принят |
| add_payment_info | Передача платёжных сведений | Не принять этот шаг за оплату |
| purchase | Покупка | Сопоставить с определённым статусом заказа |
| refund | Возврат денежных средств | Проверить связь с исходной покупкой |
Смысл событий задан документацией Google; последний столбец — наш проверочный сценарий. 1 Для покупки проверьте transaction_id , состав товаров, сумму и валюту по схеме события. 2 Идентификатор должен сохраняться для одного заказа; при повторном открытии подтверждения проверьте, что результат не задвоился.
Не пытайтесь любой ценой добиться полного совпадения цифр двух систем. Shopify, например, отдельно описывает влияние согласия на cookies и блокировщиков на сбор части сеансовых данных. 4 Сначала объясните расхождения, а не отключайте защиту приватности ради красивого отчёта.
Не отправляйте в GA4 имена, email, телефоны и другие идентифицирующие сведения, в том числе внутри URL и параметров событий. 12 Для проверки используйте безопасные тестовые данные и предусмотренный системой режим отладки.
3. Найдите переход, который требует проверки
В обычном разговоре смешиваются посетители, сеансы, события и заказы. Для анализа сначала выберите единицу подсчёта. Shopify прямо различает количество заказов и сеансы с завершённой покупкой: в одном сеансе может быть несколько заказов. 3
Для нашего примера возьмём 2 000 сопоставимых сеансов магазина . Воронка закрытая и последовательная: каждый следующий этап учитываем только после предыдущего в том же сеансе; один сеанс считается на этапе один раз. Повторные события не складываем. Покупки по сокращённому пути рассматриваем отдельно.
| Этап | Сеансы | Доля от предыдущего этапа | Доля от 2 000 сеансов |
|---|---|---|---|
| Вход в магазин | 2 000 | — | 100% |
| Просмотр товара | 1 200 | 60% | 60% |
| Добавление в корзину | 120 | 10% | 6% |
| Начало оформления | 80 | 66,7% | 4% |
| Покупка по принятому критерию | 20 | 25% | 1% |
Формула перехода проста: сеансы следующего этапа / сеансы предыдущего этапа × 100% . Для общей доли используем исходные 2 000. Не делите число событий на число людей, называя результат той же метрикой.
Здесь 120 из 1 200 сеансов с просмотром товара дошли до корзины. Это повод проверить выбор размера, наличие, предложение и измерение. Из 80 начатых оформлений завершены 20 — повод исследовать доставку и оплату. Но таблица не доказывает ни одну причину.
Не называйте остальные 1 980 сеансов «потерянными клиентами». Мы не знаем, сколько посетителей намеревались купить немедленно. Если в вашей системе воронка построена по пользователям, используйте её определения и заново согласуйте знаменатели, а не копируйте эти числа.
4. Сопоставьте трафик с тем, что обещает магазин
Предлагаем взять несколько основных входных страниц и пройти путь из конкретной рекламы или публикации. Совпадают ли товар, цена, изображение, доступный размер и условия? Ведёт ли объявление о куртке к этой куртке, а не к общей коллекции без неё?
Разделите проверку по устройству, источнику, стране доставки, языку и входной странице. Это рабочие разрезы, не обязательный список из десятков отчётов. Начните с сегмента, где заметили изменение, и сравните его с сопоставимым предыдущим периодом.
Учебный пример: после публикации о стиле выросли посещения журнала, а число заказов магазина осталось прежним. Снижение общей доли покупок в такой смеси ещё не показывает ухудшение checkout. Посмотрите отдельно тех, кто действительно посещал торговые страницы.
До увеличения рекламных расходов уточните также, продаётся ли сейчас рекламируемый вариант и обслуживается ли нужный регион. Не пытайтесь исправить настройкой кнопки ситуацию, когда предложение недоступно пришедшему человеку.
5. Проверьте карточку одежды: размер, посадку и наличие
В исследованиях Baymard размерная информация помогает участникам выбирать одежду, а фотографии на человеке дают контекст посадки и масштаба. 7 8 Это основание для проверки карточки, не гарантия определённого прироста продаж.
Наш подход — пройти реальные вопросы покупателя, а не добавлять одинаковое число фотографий во все товары. Ниже критерии для внутреннего аудита.
| Вопрос покупателя | Что проверить | Признак готовности |
|---|---|---|
| Подойдёт ли размер? | Мерки, единицы и инструкция по измерению | Понятно, измеряют тело или изделие |
| Как вещь сидит? | Фото на человеке, длину, силуэт | Размер на модели указан, когда он известен |
| Что за материал? | Состав, фактуру и уход | Текст относится именно к этому товару |
| Доступен ли мой вариант? | Сочетание размера и цвета | Нельзя незаметно заказать отсутствующий вариант |
| Что получу за указанную цену? | Комплектность, выбранную вариацию | Фото, название и корзина не противоречат друг другу |
| Как получить или вернуть покупку? | Условия доставки, обмена и возврата | Информация доступна до оплаты и соответствует работе магазина |
Отдельно проверьте переключение цвета: сохраняется ли доступный размер, меняются ли нужные фотографии и не появляется ли ложное наличие. Попросите сотрудника пройти этот сценарий без подсказок автора сайта.
Если информации о мерках нет, сначала получите её от команды продукта. Не заполняйте таблицу придуманными сантиметрами. Не используйте искусственный дефицит или неподтверждённые отзывы как замену понятному предложению.
6. Пройдите оформление и оплату до конца
Проверяйте не только удачный заказ. Для начала используйте разрешённую тестовую среду провайдера. Stripe, например, документирует безопасную имитацию успешных оплат, отказов и аутентификации без движения реальных денег. 6
Выберите один товар, одну доставку и один способ оплаты. После базового сценария добавьте сбои. Матрица ниже — предлагаемый план теста, а не утверждение о проведённых проверках.
| Сценарий | Какого поведения ожидаем | Что сохранить |
|---|---|---|
| Успешная тестовая покупка | Один корректный заказ и понятное подтверждение | ID, сумму, валюту, статусы |
| Адрес вне зоны доставки | Ясное объяснение до попытки оплаты | Экран и текст сообщения |
| Ошибка обязательного поля | Указание поля и способа исправить ввод | Шаги воспроизведения |
| Отказ оплаты или отмена подтверждения | Отсутствие ложного статуса «оплачено» | Безопасный код ошибки и статус заказа |
| Возврат назад или обновление страницы | Согласованное состояние корзины и заказа | Порядок действий и результат |
| Задержка подтверждения или повторный клик | Проверяемый промежуточный статус, без неконтролируемого дубля | Временную последовательность событий |
W3C рекомендует понятные уведомления об ошибках и успешном выполнении, с объяснением исправления. 9 Поэтому красная рамка без текста — недостаточный ориентир для нашей приёмки.
Уточните, когда покупатель видит итоговую сумму и доступную доставку. Проверяйте также промокод, гостевой сценарий, если он предусмотрен, и возврат из внешнего платёжного окна. Не обещайте, что один удачный тест подтверждает работу всех методов и стран.
7. Проверьте мобильный путь, а не только балл скорости
Откройте карточку, выберите размер, вызовите клавиатуру в форме и вернитесь из оплаты. Не перекрывают ли важные действия баннер, чат или фиксированная панель? Видно ли ошибку без поиска по всей странице? Можно ли увеличить текст и продолжить покупку?
Для технической проверки ориентиры Core Web Vitals: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1 на 75-м процентиле с разделением мобильных и настольных устройств. 10 Это не норматив конверсии и не обещание продаж.
Полевые данные CrUX доступны не для всех страниц: действуют требования к включению и достаточности данных. 11 Их отсутствие не равно плохой скорости. Лабораторную проверку используйте как диагностический снимок с указанными условиями, не выдавая её за опыт всей аудитории.
Проверяйте прежде всего затронутые карточку и оформление, а не только главную. Запишите устройство, браузер, условия соединения и действие. Так задача разработчику будет звучать «при выборе размера интерфейс зависает», а не «сделайте сайт быстрее».
8. Дошёл ли оформленный заказ до команды
При внешней оплате Shopify описывает случаи, когда платёж прошёл, но его подтверждение не было корректно передано магазину. 5 Поэтому отсутствие заказа в нужном списке не всегда означает отказ покупателя.
Мы рекомендуем проследить цепочку: запись заказа → подтверждение платежа → согласованный статус → задача сотруднику → сообщение покупателю. Email-уведомление не должно быть единственным местом, по которому вы судите о наличии заказа.
Назначьте ответственного за расхождения. Проверьте, как команда обнаружит запись без уведомления, позднее подтверждение или ошибку передачи в CRM. Не меняйте вручную финансовый статус без проверки первичных данных и принятого процесса.
Если магазин работает через заявки, применяйте ту же логику к форме. Google предусматривает generate_lead для созданного обращения. 13 Клик по мессенджеру не подтверждает получение сообщения. Проследите тестовую заявку до сотрудника и отдельно учитывайте последующую продажу.
9. Разделите исправление ошибки и проверку гипотезы
Подтверждённая неисправность не требует ожидания A/B-теста, чтобы признать её неисправностью. Но после исправления нужно повторить сценарий. Предположение «другой текст повысит продажи» требует отдельной проверки результата.
| Приоритет | Основание | Действие | Критерий завершения |
|---|---|---|---|
| Сначала: блокер покупки | Ошибка воспроизводится | Исправить форму, оплату или наличие | Ранее неработавший сценарий проходит повторную проверку |
| Затем: достоверность измерения | События расходятся с объяснимыми статусами | Исправить карту передачи данных | Контрольные заказы корректно прослеживаются |
| Далее: недостающая информация | В карточке нет мерок или условий | Добавить проверенные сведения | Информация доступна в нужном месте |
| После этого: гипотеза улучшения | Есть наблюдение, но причина не доказана | Проверить изменение на сопоставимой аудитории | Оценены основной показатель и побочные эффекты |
В рабочей задаче укажите наблюдение, доказательство, ожидаемое поведение, ответственного и проверку. Формулировка «улучшить UX» не описывает ни объём работы, ни результат.
10. Оценивайте изменения без выдуманного роста
Предположим, доля сеансов с покупкой изменилась с 1% до 1,5%. Это +0,5 процентного пункта и +50% относительно исходного значения , а не «плюс 50 процентных пунктов». Даже правильная арифметика ещё не доказывает влияние изменения сайта.
Записывайте одновременные изменения рекламы, цены, ассортимента, остатков и условий доставки. Выбирайте сопоставимые периоды и сегменты. При A/B-проверке заранее определите основной показатель, правила распределения, достаточность наблюдений и условие завершения; не останавливайте её при первом удобном результате.
При малом числе покупок сначала исправляйте воспроизводимые сбои и собирайте наблюдения, а не объявляйте победителя после нескольких заказов. Универсального «семи дней достаточно» здесь нет. Если причинный эффект оценить нельзя, так и пишите: после изменения наблюдалась разница, причины полностью не отделены.
Кроме покупки смотрите на отмены, возвраты и работу команды. Скидка или обещание быстрой доставки могут изменить количество заказов, но не делают результат автоматически выгодным и выполнимым.
11. Когда редизайн всё-таки нужен
Мы рекомендуем обсуждать системный редизайн, когда проверка выявляет связанные препятствия в структуре каталога, карточке и оформлении, которые нельзя разумно устранить локально. К решению стоит приложить наблюдения, новый сценарий и способ проверить его до полного запуска.
Редизайн не исправит неверные остатки, неподходящий трафик или потерянное серверное подтверждение сам по себе. Если ограничение связано с платформой, вернитесь к материалу «На чём создать интернет-магазин одежды: Tilda, Shopify или индивидуальная разработка». Для оценки объёма работ используйте статью «Сколько стоит создать интернет-магазин одежды: запуск и первый год работы».
В этой статье задача другая: определить проблему до выбора дорогого решения. Иногда достаточны исправленная форма и точная информация о товаре. Иногда нужна перестройка нескольких сценариев. Вывод должен следовать из проверки.
13. С чего начать владельцу магазина
Соберите адрес проблемной страницы, период, источник трафика, определение успешной покупки и несколько обезличенных примеров. Пройдите путь заказа и запишите первый подтверждённый разрыв. Затем назначьте исправление или проверку гипотезы — в зависимости от доказательств.
Главный результат диагностики — не список из ста общих советов, а понятное решение: что сломано, что пока неизвестно и что проверяем следующим.
Обсудить с VITON13 проверку пути покупателя: от карточки одежды до подтверждённого заказа и его получения командой. Передавайте доступы только через согласованный защищённый процесс, а не через публичные комментарии или текст статьи.
Практический чеклист
- 1. Сначала разделите три разные проблемы
- 2. Проверьте, что аналитика действительно считает покупки
- 3. Найдите переход, который требует проверки
- 4. Сопоставьте трафик с тем, что обещает магазин
- 5. Проверьте карточку одежды: размер, посадку и наличие
- 6. Пройдите оформление и оплату до конца
Вопросы и ответы
Почему посещения есть, а заказов нет?
По одному числу посещений причину установить нельзя. Начните со сверки заказов и аналитики, затем пройдите выбор товара, доставку, оплату и передачу заказа сотруднику. Проверьте один воспроизводимый сценарий, прежде чем назначать полный редизайн.
Какая конверсия должна быть у магазина одежды?
Не используйте одну чужую цифру как диагноз. Сначала определите единицу подсчёта, успешный статус, источник данных, период и аудиторию. Для принятия решения полезнее сопоставимые собственные сегменты и проверенные причины изменений.
Можно ли увеличить рекламу, чтобы появились продажи?
Это отдельная гипотеза. Сначала убедитесь, что предложение доступно пришедшей аудитории, покупка работает, а результат учитывается. Иначе вы не поймёте, улучшилось ли привлечение или выросло количество неуспешных попыток.
Нужно ли сразу менять платформу?
Нет. Сначала воспроизведите ограничение и оцените локальное исправление. Перенос имеет смысл обсуждать, когда нужный сценарий невозможно поддерживать приемлемым способом, а не из-за одного слабого отчёта.
Поможет ли скидка или бесплатная доставка?
Предлагайте их только с проверенным расчётом и ясными условиями. Смотрите не только на количество покупок, но и на расходы, отмены и выполнение заказов. Это не замена ремонту неработающего оформления.