Воронка в GA4: как найти шаг, на котором посетители бросают оформление
Воронка GA4 помогает увидеть, между какими действиями теряются посетители: начали оформление, передали данные доставки, выбрали оплату, завершили покупку. Но разрыв на диаграмме ещё не объясняет причину. Человек мог отказаться от заказа, пройти другим маршрутом или выполнить действие, которое сайт не передал в аналитику.
Поэтому анализ брошенных корзин в GA4 начинается с определения шагов и проверки событий. Ниже — практический порядок работы с Funnel exploration: от описания реального сценария до проверки гипотезы и повторного измерения. Для примеров используется вымышленный магазин; цифры служат иллюстрацией расчётов, а не отраслевым ориентиром конверсии.
Сначала определите, на какой вопрос должна ответить воронка
Формулировка «почему мало продаж» слишком широкая для одной последовательности. Выберите участок, за который отвечает конкретная команда. Например: «Где прекращают оформление посетители, уже открывшие checkout?» Такая задача отделяет удобство оформления от качества рекламного трафика, выбора товара и работы каталога.
Укажите начало, ожидаемый финал, включённые способы покупки и период наблюдения. Зафиксируйте, относится ли исследование к доставке, самовывозу, быстрому заказу или всем сценариям сразу. Смешивание разных маршрутов особенно мешает, если один из них законно пропускает обязательный для другой ветки шаг.
Воронка описывает пользователей, проходящих последовательность, что отражено и в модели отчёта Google. Поэтому количество прошедших финальный шаг нельзя автоматически назвать количеством заказов или суммой оплат. Для этих величин нужны соответствующие события, идентификаторы и отдельная сверка.
Перед настройкой попросите сотрудника магазина пройти покупку как посетитель и описать действия обычными словами. Сопоставление этой записи с технической картой часто обнаруживает лишний шаг раньше, чем команда начнёт обсуждать дизайн формы.
Сопоставьте действия покупателя с событиями GA4
Для учебного магазина выберем стандартный путь с доставкой и оплатой на сайте. Названия событий берём из справочника рекомендуемых событий Google. Передача сведений об оплате соответствует add_payment_info, а purchase обозначает покупку. Эти события нельзя считать взаимозаменяемыми.
| Шаг | Событие | Что проверяет команда |
|---|---|---|
| Начало оформления | begin_checkout | Посетитель действительно начал checkout |
| Переданы данные доставки | add_shipping_info | Событие связано с передачей данных, а не простым показом блока |
| Переданы данные оплаты | add_payment_info | Выбранный способ измерения соответствует смыслу события |
| Совершена покупка | purchase | Событие связано с подтверждённым в проекте фактом покупки |
Для каждого события опишите момент отправки и ответственного за реализацию. Если начало оформления фиксируется при показе кнопки, а покупка — при любом открытии страницы благодарности, даже аккуратно построенная диаграмма будет отвечать на неверный вопрос.
Не включайте шаг только потому, что он есть в чужом шаблоне. В быстром заказе может не быть отдельного ввода платёжных данных, а при самовывозе отличается работа блока доставки. Для таких маршрутов подготовьте собственные последовательности или согласованное общее бизнес-действие. Решение должно отражать поведение сайта, а не маскировать отсутствие события дополнительной отправкой.
Проверьте события на реальном сценарии до анализа потерь
Пройдите согласованный маршрут на тестовом заказе. Для каждого действия сохраните время, ожидаемое событие, фактическое событие и необходимый параметр. Используйте предусмотренную магазином тестовую процедуру, чтобы учебная покупка не вызвала реальную отгрузку и не попала в рабочую обработку без пометки.
DebugView показывает отладочные события и их параметры. Google рекомендует при проверке включать режим для своего устройства, например через Tag Assistant. Сопоставьте последовательность на экране с последовательностью в диагностике: важно подтвердить каждый переход, а не только присутствие purchase.
Проверьте также возврат на предыдущий шаг, ошибку обязательного поля и повторное нажатие кнопки. Если событие отправляется до проверки введённых данных, оно может означать попытку, хотя в названии шага указано успешное завершение. Такое расхождение сначала исправляют в плане измерения и реализации.
Отдельно запишите условия согласия и ограничения тестового браузера. Отсутствие аналитического события при отказе от соответствующего сбора не следует исправлять принудительным разрешением. Принимая воронку, команда должна понимать, какие наблюдения доступны и какие посетители не представлены в данных выбранным способом.
Соберите первую версию в Funnel exploration
Откройте нужный ресурс GA4, перейдите в Explore и выберите Funnel exploration. В настройках шагов задайте понятные названия и условия по именам событий. Для нашего примера это точное соответствие четырём значениям из таблицы. Порядок редактирования описан в справке по исследованию воронок.
Начните с простого исследования без длинного набора фильтров. Убедитесь, что выбран период после запуска всех необходимых событий. Если шаг доставки появился в середине месяца, сравнение начала и конца месяца смешает изменение поведения с изменением измерения.
Дайте исследованию рабочее название, например «Оформление с доставкой — версия 1». Рядом сохраните дату создания, период, последовательность и условия отбора. Этого достаточно, чтобы другой сотрудник понял границы исследования и не перепутал его с общей воронкой всего магазина.
По описанию редактора Explorations, переменные и настройки вкладки выполняют разные роли. Проверьте, что нужные параметры действительно применены в текущей вкладке. Добавление доступного поля в список ещё не означает, что таблица уже разбита по этому полю.
Выберите открытую или закрытую воронку под задачу
В закрытую воронку пользователь входит с первого шага, в открытую — с любого. Эти варианты описаны в документации Google по отчётам воронок. Для вопроса «что происходит после начала оформления» выберем закрытую: точкой входа служит begin_checkout.
Предположим, часть покупателей возвращается по сохранённой ссылке сразу к оплате. В открытой модели такие входы нужно рассматривать отдельно от продолжения прежнего шага. Простое деление общей высоты соседних столбцов может смешать два потока: пришедших из начала последовательности и вошедших позже.
Закрытая модель тоже не исправляет пропуски измерения. Если посетитель начал оформление, но begin_checkout не отправился, последующая покупка не восстанавливает отсутствующее наблюдение о входе. Проверьте её технический маршрут, прежде чем объявлять человека необычным посетителем или добавлять всё в открытую модель ради более приятных чисел.
Храните обе версии только при наличии двух разных вопросов. Например, закрытая нужна для оценки прохождения всего checkout, открытая — для исследования поздних точек входа. Назовите их соответствующим образом. Переключение типа в середине регулярного сравнения меняет саму постановку задачи и должно быть отмечено в отчёте.
Задайте порядок шагов и допустимое время между ними
В Funnel exploration режим indirectly followed by допускает промежуточные действия, а directly followed by требует следующего шага непосредственно после предыдущего. Условие Within ограничивает интервал перехода. Для первого исследования обычного оформления удобно разрешить промежуточные события и отдельно обосновать временное ограничение.
Покупатель может открыть условия доставки, прочитать подсказку или вернуться к составу заказа. В его глазах оформление продолжается. Поэтому строгую последовательность без промежуточных действий выбирают только тогда, когда она отвечает конкретному вопросу и подтверждена наблюдением за реальными событиями.
Если установлено условное ограничение в двадцать минут, зафиксируйте его причину. Сравните результат с версией без этого ограничения: часть разницы будет следствием правила отбора, а не неисправности магазина. Не меняйте окно задним числом только для получения желаемой конверсии.
Соблюдение порядка остаётся необходимым: пропуск заданного шага исключает дальнейшее прохождение в этой последовательности. Если интерфейс допускает полноценную покупку без промежуточного действия, пересмотрите модель маршрута. Нельзя считать её корректной только потому, что названия шагов красиво располагаются на диаграмме.
Посчитайте потери в людях и долях на одном учебном примере
Предположим, все четыре события проверены, выбран один период и закрытая воронка оформления с доставкой. В вымышленных данных тысяча пользователей начала маршрут, а до покупки дошли 360. Рассчитаем потери на каждом переходе, используя число достигших предыдущего шага как знаменатель.
| Переход | Начали шаг | Дошли до следующего | Не продолжили | Доля потерь |
|---|---|---|---|---|
| Начало → доставка | 1 000 | 700 | 300 | 30% |
| Доставка → данные оплаты | 700 | 420 | 280 | 40% |
| Данные оплаты → покупка | 420 | 360 | 60 | 14,3% |
Общее прохождение составляет 360 / 1 000 × 100% = 36%. На втором переходе теряется наибольшая доля участников — 40%, но на первом больше людей в абсолютном выражении: 300 против 280. Поэтому приоритет нельзя выбирать только по самому высокому проценту или самому длинному столбцу.
Сопоставьте масштаб, предполагаемую причину, стоимость проверки и влияние на покупку. Если первый шаг сложен из-за обязательных данных, его улучшение может потребовать согласования бизнес-процесса. Если второй сломан для конкретного браузера, исправление технической ошибки может оказаться более срочным. Диаграмма помогает выбрать место исследования; решение требует дополнительного свидетельства.
Не называйте 640 незавершивших маршрут гарантированно потерянными заказами. Часть людей сравнивает условия или завершает покупку иначе. Умножение этого числа на средний чек не даёт доказанного размера потерь выручки и не является прогнозом эффекта редизайна.
Разберите устройства, сохраняя смысл выбранной группы
Добавьте Device category в Breakdown и сравните тот же участок пути. В учебном примере предположим, что каждый участник использует одно устройство на всём маршруте. Это позволяет показать арифметику без смешения переходов между устройствами.
| Группа | Начало | Доставка | Данные оплаты | Покупка |
|---|---|---|---|---|
| Мобильные устройства | 600 | 360 | 180 | 150 |
| Компьютеры | 400 | 340 | 240 | 210 |
| Всего | 1 000 | 700 | 420 | 360 |
На переходе от доставки к данным оплаты мобильная группа теряет 180 из 360 человек, то есть 50%. Группа компьютеров — 100 из 340, примерно 29,4%. Это повод проверить мобильный сценарий: размещение элементов, сообщения об ошибках и фактическую отправку события.
Однако различие может быть связано и с составом посетителей, источниками или ассортиментом. Сначала воспроизведите проблему, затем формулируйте вывод. Не называйте мобильную верстку причиной только на основании двух процентов.
В реальной разбивке GA4 относит пользователя к первому подходящему значению параметра. Поэтому строка mobile не доказывает, что каждый следующий шаг выполнен на телефоне. Для сложного маршрута уточните условия отбора и идентификации, сохраняя одинаковое правило в сравниваемых версиях исследования.
Учтите повторные прохождения и область сегмента
При нескольких прохождениях пользователем за выбранный период исследование учитывает первую последовательность. Поэтому два заказа одного покупателя не превращаются автоматически в два входа в эту воронку. Для анализа повторных покупок отдельно определите единицу наблюдения и нужный отчёт, сохранив исходную задачу исследования оформления.
Конструктор сегментов GA4 различает пользователей, сеансы и события. Отбор людей, совершивших покупку, отличается от отбора только событий purchase. В первом случае вопрос относится к поведению выбранных людей; во втором из набора могут исчезнуть действия, необходимые для изучения предыдущих шагов.
Прежде чем добавить готовый сегмент коллеги, прочитайте его условия. Название «покупатели с рекламы» не объясняет, по какому признаку отобраны данные и какие действия остались доступны. Сохраните описание отбора вместе с воронкой, особенно если сравнение будет повторяться каждый месяц.
Также проверяйте соответствие периода доступным данным. Google объясняет различия отчётов и исследований, включая ограничения хранения, фильтрацию и обработку свежих событий. Если числа расходятся, сначала сопоставьте условия двух запросов. Общее количество покупок в другом разделе не является готовым эталоном для пользовательской последовательности с дополнительными ограничениями.
Отделите техническую проблему от поведенческого отказа
Для подозрительного перехода составьте две проверяемые гипотезы. Первая: посетителю действительно трудно продолжить. Вторая: действие выполнено, но аналитика описывает его неверно. Такой порядок позволяет не начинать редизайн из-за пропавшего события и не ограничиваться исправлением тега при реальной ошибке формы.
| Наблюдение | Что проверить следующим |
|---|---|
| Интерфейс продолжает оформление, событие отсутствует | Условие отправки, ошибки выполнения и назначение события |
| Кнопка не позволяет пройти дальше | Валидацию полей, сообщение об ошибке и работу элемента |
| Проблема возникает после перехода на другой домен | Пользовательский маршрут и сохранность аналитической связи |
| Разрыв появился после выпуска новой версии | Изменения интерфейса и измерения в этом выпуске |
| События корректны, сбой не воспроизводится | Дополнительные наблюдения и условия коммерческого предложения |
Фиксируйте точные обстоятельства: устройство, браузер, способ доставки, состояние корзины, время и последовательность действий. Сообщение «на мобильных низкая конверсия» не позволяет разработчику воспроизвести ошибку. Полезное задание описывает момент, где ожидаемый результат расходится с фактическим.
Вспомогательные показатели тоже требуют осторожности. Среднее время перехода описывает дошедших до следующего шага, а не время ожидания всех ушедших. Нельзя объяснить отказ людей только средним значением, рассчитанным по другой части участников.
Проверяйте улучшения при неизменных правилах измерения
После нахождения причины сформулируйте изменение и ожидаемый эффект. Например: «Исправляем сообщение об ошибке в выборе доставки; ожидаем, что больше участников этого шага продолжат оформление». Назначьте основной показатель, дополнительные признаки качества и ответственного за проверку.
Сначала повторите технический сценарий после выпуска. Убедитесь, что событие сохранило прежний смысл. Если раньше оно означало успешную передачу данных, а теперь отправляется при открытии блока, рост числа событий нельзя считать улучшением поведения. Аналитическое определение должно оставаться сопоставимым.
Затем сравнивайте подходящие периоды или результаты корректно организованного эксперимента. Учитывайте состав трафика, акции, наличие товара, способы оплаты и другие изменения. Обычное сравнение «до и после» помогает заметить сдвиг, но само по себе не доказывает, что его вызвала конкретная правка.
Смотрите и на следующий шаг. Упрощённый переход может увеличить число дошедших до оплаты, одновременно ухудшив качество введённых данных или не изменив количество покупок. Для владельца магазина важен устойчивый результат всего маршрута, а не улучшение одного промежуточного процента.
Не останавливайте наблюдение после первой удачной покупки и не объявляйте две неудачные попытки массовой проблемой. Объём данных и критерий решения согласуют заранее под задачу. В рабочей заметке честно разделяйте подтверждённое исправление ошибки и ещё проверяемую гипотезу о влиянии на конверсию.
Сохраните понятную версию отчёта и порядок повторной проверки
Перед передачей результата руководителю добавьте краткое описание: кого считали, откуда начинался путь, какие шаги были обязательны и что обнаружили. Приложите воспроизводимый пример и конкретное следующее действие. Одна диаграмма без условий отбора легко превращается в спор о разных определениях.
Если исследование сохраняют как отдельный отчёт в библиотеку, Google фиксирует его настройки на момент сохранения. Последующие изменения исходного исследования автоматически не обновляют этот отчёт; для новой логики понадобится новая сохранённая версия. Это относится к конфигурации, а не к обещанию заморозить все будущие данные.
Для регулярной работы используйте короткий контрольный список:
- Названия шагов соответствуют проверенным действиям посетителя.
- Тип воронки, порядок и ограничения времени записаны.
- Период относится к стабильной версии сбора событий.
- Быстрая покупка, самовывоз и другие ветки учтены осознанно.
- Потери рассчитаны с понятным знаменателем и проверены в абсолютных числах.
- Сегменты и разбивки описаны так, чтобы их мог повторить другой сотрудник.
- Предполагаемая причина отделена от технически подтверждённого факта.
- После изменения интерфейса проверены события и дальнейший результат покупки.
Обновляйте этот протокол после изменения оформления, подключения нового способа оплаты или переработки аналитики. Рабочая воронка остаётся полезной, когда команда понимает правила её расчёта и может повторить проверку, а каждое замечание ведёт к конкретной задаче.
Для внешнего контроля HTTP-доступности важных страниц подключите SiteGuard. Проверку шагов оформления и аналитических событий выполняйте отдельно по карте маршрута.