Поиск по сайту в GA4: как узнать, что посетители ищут и не находят

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

Настройка поиска по сайту в GA4 начинается с события view_search_results и параметра search_term. Дальше потребуется договориться о правилах подсчёта, проверить разные поисковые формы и отдельно передать результат обработки. Автоматическое событие не читает мысли пользователя и не оценивает полезность найденных страниц.

Что именно нужно измерять во внутреннем поиске

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

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

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

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

Когда GA4 автоматически распознаёт поиск

В расширенной статистике GA4 предусмотрено событие view_search_results. Оно распознаёт показ страницы поиска по параметру URL. По умолчанию используются q, s, search, query и keyword; в настройках можно указать другие имена. Текст запроса передаётся в search_term.

https://example.com/catalog/search?q=demo_lamp_473
https://example.com/help?search_query=demo_delivery_473

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

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

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

Как учитывать каталог, справку и мобильную форму

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

Поиск	Условный технический маршрут	Что проверить
Каталог	/catalog/search?q=...	Фраза и результат поиска товаров
Справка	/help?search_query=...	Дополнительное имя параметра
Мобильная панель	Ответ API без нового URL	Сигнал после отображения результата
Личный кабинет	Поиск по собственным документам	Допустимость передачи текста запроса

Для собственной схемы полезен параметр search_area со значениями catalog или help. Это параметр проекта, а не встроенное обещание GA4 автоматически определить область поиска. Передавайте его из контекста интерфейса. Позицию поля, например header или mobile_panel, можно учитывать отдельно, если от неё зависит конкретное решение.

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

Как исключить личные данные из поисковых фраз

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

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

В GA4 доступна редакция данных веб-потока: она помогает удалять вероятные email и указанные URL-параметры до отправки. Распознавание email выполняется по принципу best effort. Настройка очистки URL не является гарантией очистки произвольного текста во всех ваших пользовательских параметрах.

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

Как не посчитать один поиск дважды

У одного действия должен быть определённый отправитель. Частая ошибка возникает, когда расширенная статистика уже создаёт view_search_results, а Google Tag Manager или код сайта отправляет ещё одно такое событие при загрузке выдачи. Итоговое количество растёт, хотя посетители не стали искать чаще.

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

В справочнике рекомендуемых событий есть также search с параметром search_term. Это допустимый вариант собственной реализации. Но одновременные search и view_search_results не становятся автоматически двумя разными поисковыми попытками. Определите их смысл и не складывайте показатели без проверки.

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

Как передать ноль результатов и отделить его от ошибки

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

В условной схеме проекта введём пользовательское событие site_search_outcome. Оно отправляется один раз для завершившейся поисковой попытки. Параметр result_state принимает results, empty или error. Для успешного ответа result_count содержит общее число найденных элементов; при ошибке он отсутствует. Это наши имена и правила, а не автоматически собираемые поля GA4.

gtag('event', 'site_search_outcome', {
  safe_search_term: 'demo_missing_473',
  search_area: 'catalog',
  result_state: 'empty',
  result_count: 0
});

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

Ошибка API, тайм-аут и неразобранный ответ получают отдельное состояние error. Если система показывает рекомендации при нулевой точной выдаче, заранее определите, что считается найденным результатом. Иначе одинаковое число ноль у разных разработчиков будет означать разные ситуации.

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

Где провести границу одной поисковой попытки

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

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

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

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

Какие измерения и фильтры нужны в отчёте

Для базового анализа используйте имя события view_search_results, измерение Search term и число событий. По актуальному справочнику измерений GA4, Search term — встроенное измерение, заполняемое search_term в событиях search или view_search_results. Создавать его дубликат как пользовательское измерение по старой инструкции обычно не требуется.

Для нашего site_search_outcome нужен отдельный отчёт с точным фильтром по этому имени. Параметры safe_search_term, search_area и result_state зарегистрируйте как пользовательские измерения уровня события. Если требуется анализ числового result_count, настройте соответствующую пользовательскую метрику. Эти значения не появляются в отчётах только потому, что отправлены в запросе.

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

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

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

Учебный расчёт: поиски, пользователи и пустая выдача

Предположим, за контрольный период 120 измеренных пользователей выполнили 200 поисковых попыток. По принятому контракту каждой соответствует одно site_search_outcome. Все события корректно получены, технических дублей нет. Получилось следующее распределение:

Исход	Число попыток	Интерпретация
results	160	Получена непустая выдача
empty	30	Подтверждено отсутствие результатов
error	10	Поиск завершился технической ошибкой

Успешно обработано 160 + 30 = 190 попыток. Доля пустых выдач среди успешно обработанных равна 30 / 190, примерно 15,8%. Доля технических ошибок среди всех попыток — 10 / 200 = 5%. Если делить пустые выдачи на все попытки, получится 15%; такой показатель тоже возможен, но его знаменатель нужно явно указать.

Среднее число попыток на измеренного пользователя составляет 200 / 120, около 1,67. Число 30 не означает тридцать недовольных людей: один посетитель мог получить пустую выдачу несколько раз. Также нельзя сложить пользователей по всем поисковым фразам и считать сумму уникальной аудиторией.

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

Как сравнивать группы без ложных выводов

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

Сегмент «пользователи, у которых была пустая выдача» способен включать и другие действия этих людей в выбранном периоде. Он не доказывает, что любая их последующая покупка относится к конкретному неудачному запросу. Сформулируйте вопрос до построения сегмента и проверьте последовательность на контрольном примере.

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

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

Как проверить настройку безопасными сценариями

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

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

1. Запустите поиск существующего тестового объекта и проверьте непустой исход.
2. Отправьте безопасную отсутствующую фразу и подтвердите empty с result_count равным нулю.
3. Смоделируйте ошибку в тестовой среде: она должна отличаться от пустой выдачи.
4. Повторите запрос, обновите страницу и проверьте согласованные правила повторов.
5. Пройдите каталог, справку и мобильный интерфейс, сравнив ожидаемые имена событий.
6. Убедитесь, что исходные личные данные не уходят через параметры, адрес и заголовок страницы.

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

Как превратить отчёт в задачи для сайта

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

В карточке задачи укажите безопасную фразу, область поиска, ожидаемый результат и критерий проверки. Например: «В тестовом каталоге запрос demo_lamp_473 показывает подготовленный товар, отправляется один непустой исход, мобильная форма ведёт себя так же». Это проверяемое условие без обещаний роста продаж.

После изменения сравните сопоставимые периоды и состав запросов. Зафиксируйте дату релиза и версию правил измерения. Уменьшение доли пустых выдач при одновременной потере отправки empty не является улучшением. Сначала подтвердите корректность данных, затем оценивайте поведение пользователей.

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