Аналитика форм в Метрике: как найти поля, из-за которых не отправляют заявку

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

Ниже разобран полностью условный пример формы заявки. Все количества и результаты придуманы для обучения. Инструкция посвящена удобству заполнения: отправка формы в отчёте не подтверждает получение заявки в CRM, заключение сделки или оплату.

1. Выберите одну форму и определите смысл показателей

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

В справке об аналитике форм описаны два режима. «Конверсия формы» показывает просмотры страницы с формой, взаимодействия и отправленные формы. «Поля формы» помогает изучить время взаимодействия, незаполненные поля и поля, после которых страницу покидают без отправки.

Просмотр страницы не равен доказанному внимательному просмотру формы. Она может располагаться ниже первого экрана, появляться после действия или конкурировать с другим содержимым. Аналогично начало заполнения не означает твёрдого намерения оставить заявку: человек может проверять условия или сравнивать предложения.

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

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

2. Проверьте подключение и контрольный сценарий

По инструкции настройки Вебвизора включите соответствующие опции счётчика и установите обновлённый код на страницы сайта. Изменение настройки в кабинете и наличие нужной конфигурации на рабочей странице стоит проверить отдельно, особенно если код устанавливает CMS или менеджер тегов.

Для корректного сбора по формам Яндекс указывает UTF-8, передачу через событие submit и отсутствие скрытия анализируемых полей через display: none. Для многошаговой формы проверяйте фактически открытый шаг; не приравнивайте невидимый элемент к полю, которое посетитель сознательно пропустил.

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

Если контрольное действие не наблюдается, сначала разбирайте сбор. Нулевое число отправок может означать как проблему интерфейса, так и неподдерживаемый способ отправки. До проверки этого различия вывод «все пользователи бросают форму» будет преждевременным.

3. Разберите submit и нестандартный JavaScript

В пояснении Яндекса о неисправностях аналитики форм отдельно сказано: отправка через другие JavaScript-события вместо submit не попадает в этот отчёт. Кнопка, чей обработчик click напрямую вызывает запрос к API, не становится поддерживаемой формой только из-за похожего внешнего вида.

Попросите разработчика проверить реальный элемент <form>, его элементы управления и цепочку обработчиков. По описанию события submit в MDN, событие возникает на форме. Прямой вызов form.submit() его не создаёт; requestSubmit() проходит обычный механизм отправки. Если встроенная проверка браузера отклоняет данные, отправка блокируется и submit не возникает.

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

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

4. Сопоставьте поля с HTML и назначением

Составьте короткую карту: подпись поля, назначение, обязательность, технический идентификатор и правило проверки. Названия «Поле 1» или «input» неудобны для обсуждения. Команде нужно однозначно понимать, идёт ли речь о контактном телефоне, добавочном номере или скрытом техническом параметре.

Атрибуты имеют разный смысл. При явной связи label с полем значение for соответствует его id; идентификатор должен быть уникальным в документе. Атрибут name у input задаёт имя значения при обычной отправке формы. Это не одно и то же, и одинаковый name может быть намеренным, например у группы радиокнопок.

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

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

5. Сохраните приватность при просмотре записей

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

В настройках Вебвизора можно отключить запись всех полей; их содержимое заменяется звёздочками. Для отдельных input и textarea предусмотрен класс ym-disable-keys, а для скрытия содержимого произвольного блока — ym-hide-content. Эти способы описаны в инструкции Яндекса по записи содержимого. Автоматическое распознавание конфиденциальных полей не заменяет проверки собственных настроек.

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

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

6. Оцените ограничения данных до расчёта конверсии

Текущие ограничения Вебвизора предусматривают хранение записей 15 дней, включая текущий день. Число записей в сутки определяет алгоритм, оно может меняться. Поэтому не обещайте фиксированный дневной объём и не откладывайте изучение нужного периода на неопределённое время.

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

Для собственного сравнения зафиксируйте период, адреса, устройство, версию формы и единицу подсчёта. Уточните, считаются ли просмотры, взаимодействия, отправки или визиты с действием. Повторная загрузка и несколько попыток способны создавать разные количества. Числитель и знаменатель должны описывать совместимую совокупность.

Отдельно учитывайте техническую воспроизводимость записей. Например, Яндекс не поддерживает Shadow DOM в Вебвизоре; содержимое стороннего iframe требует специальной настройки. Если нужный компонент не виден в записи, это ограничение наблюдения, а не доказательство, что посетитель его не использовал. Пустую запись нельзя автоматически записывать в отказы.

7. Учебный пример: посчитайте потери между этапами

Предположим, анализируется форма на https://example.com/request/. В условной сводке есть 1 200 наблюдаемых просмотров, 600 начал взаимодействия и 240 отправок. Для простоты каждый включённый визит содержит один просмотр этой страницы, не более одного начала и одной отправки. Это допущение примера, а не обещание такого устройства любого отчёта Метрики.

Показатель	Расчёт	Результат
Начали взаимодействие	600 / 1 200	50%
Отправили среди начавших	240 / 600	40%
Отправили среди просмотров	240 / 1 200	20%
Начали, но не отправили	600 − 240	360 визитов

Здесь 360 / 600 = 60% начавших не завершили отправку в наблюдаемом сценарии. Это не 60% всех просмотров: относительно 1 200 их доля равна 30%. Разница важна, когда владелец оценивает масштаб проблемы и выбирает, улучшать ли обнаружение формы или её заполнение.

Не называйте оставшиеся 600 просмотров без начала потерянными заявками. У людей могли быть другие задачи. И не приписывайте все 360 незавершений одному полю: на этом этапе известен только разрыв. Причину предстоит проверить по полям, записям и воспроизведению.

8. Найдите подозрительные поля, не назначая виновника заранее

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

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

Последнее поле	Незавершённые визиты	Что проверять
Телефон	180	Маску, вставку, сообщение об ошибке
Компания	90	Обязательность и понятность требования
Комментарий	60	Ожидаемый объём и подсказку
Другие поля	30	Индивидуальные сценарии

Сумма равна 360. Телефон встречается в 180 / 360 = 50% незавершений, но это не доказательство, что он вызвал половину всех уходов. Относительно 600 начавших это 30%. Приоритет проверки высокий; причинный вывод пока отсутствует.

Если несколько полей редактировали повторно, не складывайте такие взаимодействия как независимые потерянные заявки. Один визит может дать несколько сигналов. Для задач разработчика полезнее последовательность «вставка — ошибка — исправление — уход», чем сумма всех подсвеченных элементов.

Для каждого подозрительного поля выясните, какие сведения посетитель должен иметь под рукой. Номер договора, точный бюджет или реквизиты компании могут требовать подготовки вне сайта. Причиной паузы тогда может быть необходимость подготовить сведения, а не работа маски ввода. Обсудите с владельцем услуги, можно ли запросить сведения позже или объяснить заранее, что понадобится. Эта проверка помогает выбрать полезную правку вместо косметического изменения цвета и размера поля.

9. Выберите записи по правилу и сравните разные исходы

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

В нашем примере команда отбирает 30 незавершённых и 15 завершённых визитов — всего 45 записей. Правило отбора и период фиксируются заранее. В 12 незавершённых записях видны повторные исправления телефона; похожее поведение есть и в четырёх завершённых. Это повод воспроизвести ввод, а не утверждать, что любое исправление приводит к уходу.

Записывайте наблюдаемое: посетитель вставил значение, появилась подсказка, фокус вернулся назад, кнопка оказалась закрыта клавиатурой. Формулировка «ему не понравилось поле» описывает мысли, которых запись не показывает. Если содержимое скрыто, не угадывайте его и не снимайте защиту: проверяйте аналогичные сценарии условными данными.

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

Не меняйте правило отбора по ходу просмотра только ради подтверждения первой догадки. Отмечайте записи, которые ей противоречат, и случаи, где действие невозможно разобрать. Для каждой находки полезно хранить две отдельные строки: что видно и что предполагается. Например, «трижды возвращается к телефону» — наблюдение, а «маска отвергает корректный номер» — гипотеза, пока команда не воспроизвела отказ. Такая дисциплина делает обсуждение конкретным и уменьшает число необоснованных переделок.

10. Превратите наблюдение в проверяемую гипотезу

Для телефонного поля гипотеза может звучать так: «Маска неверно обрабатывает вставку номера с пробелами, поэтому часть посетителей повторяет ввод и не завершает форму». Проверка начинается на безопасном тестовом сценарии: вставить разные допустимые варианты, увидеть ошибку и определить, какое преобразование её вызывает.

Изменение должно устранять обнаруженную помеху. Например, корректно нормализовать допустимый ввод и объяснять ожидаемый формат до ошибки. Не отключайте проверку данных целиком ради увеличения числа отправок. Сохраните требования, которые нужны для дальнейшей обработки, и сделайте их понятными посетителю.

Для поля компании вопрос другой: действительно ли оно необходимо до первого контакта? Если бизнес может получить эти сведения позже, обсудите необязательность. Если поле нужно обязательно, объясните зачем. Универсального правила «чем меньше полей, тем лучше результат» для каждой задачи нет.

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

11. Повторите измерение и не перепутайте проценты

После выпуска проверьте успешный ввод, ошибку, исправление, клавиатуру смартфона и сбор данных. Затем сравните сопоставимые группы. Вторая условная сводка сохраняет прежние допущения подсчёта: 1 200 просмотров и 600 начавших, но уже 300 отправок.

Показатель	До	После
Отправки среди начавших	240 / 600 = 40%	300 / 600 = 50%
Отправки среди просмотров	240 / 1 200 = 20%	300 / 1 200 = 25%
Незавершённые среди начавших	360	300

Первый показатель вырос на 10 процентных пунктов, или на 25% относительно прежних 40%. Второй вырос на 5 процентных пунктов, тоже на 25% относительно прежних 20%. Количество отправок увеличилось на 60. Эти формулировки описывают разные величины и должны сопровождаться исходными числами.

Сравнение «до и после» ещё не доказывает эффект правки. Могли измениться реклама, устройства, спрос или состав наблюдаемой выборки. Проверьте сопоставимость и разбивку по значимым группам; при возможности используйте заранее спланированное случайное разделение вариантов. Не объявляйте победу по кратковременному скачку и не останавливайте наблюдение только потому, что цифра стала приятной.

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

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

12. Закрепите результат в понятной рабочей процедуре

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

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

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

Подключите SiteGuard для внешнего HTTP-контроля доступности страницы заявки. Удобство полей и изменения конверсии оценивайте отдельным анализом в Метрике.