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

Опишите маршрут языком покупателя

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

В Manage Funnels администратор выбирает Add New и задаёт правила шагов. Для Path сравнивается путь без строки параметров, для URL — полный адрес. Не подставляйте полный адрес туда, где ожидается только путь: это может изменить результат сопоставления. Доступность Funnels зависит от подключённых возможностей Matomo, её нужно проверить до настройки.

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

Пройдите несколько допустимых сценариев

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

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

Отличайте пропавший сигнал от реального препятствия

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

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

Оцените изменение на сопоставимой базе

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

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

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

Если заказ оплачивается на внешней странице, проверьте возвращение после успешной и неуспешной оплаты отдельно. Одинаковая кнопка возврата не должна давать одинаковую конверсию для двух разных результатов.