Маркетинг горит, трафик отливается, кампании оплачиваются — а поиск остается «где-то за кадром». Команда знает, что модуль умного поиска должен продавать, но в GA для этого не хватает доказательств.
Маркетолог оказывается в ситуации, когда ему нужно обосновать инвестиции в инструмент, но нет четкой модели: как именно доказать, что Multisearch приносит деньги.
Даже когда с Google Analytics и отслеживаниями всё в порядке, покупки, совершенные с помощью мультипоиска, фиксируются не всегда. Как в таком случае принимать решения, когда данных нет, а ответственность — есть?
Где теряются транзакции?
Многие e-commerce проекты сталкиваются с тем, что в аналитике не хватает ключевых метрик. Основная проблема — eCommerce-модуль не связан с поиском.
Даже при настроенных событиях покупки (purchase) система может «не знать», что покупка произошла после взаимодействия с Multisearch, и не может связать транзакцию с поисковым запросом.
Если в отчёте отсутствуют показатели конверсии или revenue — скорее всего, в настройках eCommerce-событий не передается параметр search_term.
📘 Рекомендуем гайд о том, как добавить этот параметр в ивент purchase из cookies. Но способ реализации также зависит от того, как именно у вас настроен Multisearch — сначала стоит уточнить технические нюансы.
Как настроить отслеживание внутреннего поиска и eCommerce-событий?
Чтобы правильно оценивать эффективность поиска — как в целом, так и в разрезе отдельных запросов — необходимо объединить события поиска с событиями eCommerce в рамках одного взаимодействия или сессии.
Попробуйте 4 базовых принципа:
1. Сохраняйте поисковой запрос (search_term) — например, в cookies или sessionStorage.
2. Передавайте этот параметр во все ключевые события: просмотр товара, добавление в корзину, начало чекаута, покупка.
*Такой параметр необходимо передавать только для событий, которые отправлялись при задействованном поиске.
3. Создайте специальные отчёты в GA4 с фокусом на метриках:
- Количество транзакций
- Доходы (revenue)
- Conversion Rate
- Средний чек
4. Сегментируйте данные по наличию поиска — отдельно для сессий с поиском и без.
Этот способ позволит:
✔️ Увидеть доход от поиска в целом
✔️ Определить наиболее конверсионные поисковые запросы
✔️ Понять, действительно ли поиск помогает продавать
✔️Просмотреть запросы с наивысшим или наименьшим уровнем конверсионности / доходности
Схема передачи параметров
| Принцип | Зачем это нужно |
| Передавать search_term | Чтобы можно было построить отчёт по запросам |
| Фиксировать клик на результат | Чтобы знать, что именно было выбрано из поиска |
| Сохранять контекст до покупки | Чтобы знать, что покупка состоялась после поиска |
|
Использовать user/session scoped параметры |
Для стабильной связи |
| Иметь структуру именования событий | Чтобы легко строить фильтры/сегменты в отчетах |
Что мы можем передавать или настраивать в GA4 для анализа влияния поиска на отдельные шаги и заказы:
| Событие | Когда запускать | Обязательные параметры |
| view_search_results | После выполнения поиска | search_term |
| search_result_click | Клик на результат в выдаче | search_term, item_id , position |
| search_input_start |
Когда пользователь начинает вводить запрос |
|
| search_suggestions_viewed |
Когда появляются автоподсказки в поле зрения пользователя |
|
| search_suggestion_click | Клик на автоподсказку | search_term, suggestion_text |
| search_history_clicked | Клик на один из предыдущих запросов | search_term |
| search_button_add_to_cart | Клик кнопки «добавить в корзину» в поиске | search_term, item_id |
| view_item | Просмотр страницы товара из поиска | search_term, item_id |
| add_to_cart | Добавление в корзину | search_term (если был поиск), item_id |
| purchase | Завершение покупки |
search_term або multisearch_used = true |
Что именно анализировать для оценки эффективности поиска?
Чтобы иметь стабильную связь между поиском и действиями пользователя, важно иметь продуманную структуру передачи событий и параметров в GA4.
Это позволит лучше понять, как именно поиск влияет на отдельные этапы взаимодействия пользователя и на заказы в целом.
Вот пример основных событий, которые стоит передавать:
- Событие выполнения поиска — фиксируется, когда пользователь вводит запрос и нажимает Enter (или «поиск»).
- Клик на товар в результатах поиска — передаем item_id, а также, например, search_term, чтобы знать, из какого запроса пришли к этому товару.
- Тип товара — полезно добавлять как отдельный параметр, если нужно анализировать эффективность поиска в контексте категорий или групп продуктов.
- Взаимодействие с автоподсказками — если пользователь взаимодействует с автозаполнением в поиске, это также можно фиксировать как отдельное событие.
Такие события дают возможность создать полноценную воронку, где первый шаг — это поиск, а следующие — переходы на карты товаров, добавление в корзину и покупка.
Эта структура позволяет измерить влияние поиска на все этапы в процессе заказа.
Как отслеживать эффективность поиска отдельно и в рамках A/B тестирования?
Если имеется в виду обычное отслеживание и тестируется сам поиск, то основная метрика теста должна отвечать на вопрос о его эффективности (например, изменение в конверсии или revenue).
Если же нужно отследить эффективность поиска как отдельную поведенческую метрику в рамках A/B теста, тогда важно, чтобы инструмент тестирования позволял интеграцию с Google Analytics 4.
Например:
🔹 VWO поддерживает такую интеграцию. После ее настройки можно:
- сохранять идентификаторы вариантов A и B;
- создать два сегмента в GA4 (один для контрольной, второй — для тестовой версии);
- сравнить показатели в Free Form Report (раздел Explore).
Это позволяет оценить изменение в поведении пользователя в обеих версиях: улучшилась ли конверсия, средний чек, количество просмотров товаров и т. д. — именно в контексте взаимодействия с поиском.
👉Инструкция VWO–GA4 интеграции
В отчёт можно добавить метрики из таблицы ниже или выбрать те, которые вас интересуют:
| Метрика | Что означает | Зачем нужна |
| ARPPU (Average Revenue Per Paying User) | Средний доход с платного пользователя |
Показывает изменения в поведении покупателей, использовавших поиск |
| ARPU (Average Revenue Per User) |
Средний доход со всех пользователей |
Отражает общее влияние вариаций на доход |
| Session key event rate |
Доля сессий с ключевыми событиями |
Может включать purchase и другие |
| User key event rate |
Доля пользователей, выполнивших ключевые действия |
Может включать purchase и другие |
|
Total revenue |
Общий доход |
Даёт представление о финансовом влиянии изменений |
| Transactions per purchaser |
Среднее количество транзакций на 1 покупателя |
Указывает на рост / падение повторных покупок |
| Total users |
Количество пользователей |
|
Итак, мы добавили примеры и можем создать их как сегменты, чтобы посмотреть разницу между А и В версиями в отдельных метриках.
Если события настроены правильно, поиск перестаёт быть «статьёй расходов» и становится активом, который генерирует продажи и сокращает затраты. Любой инструмент в e-commerce должен оправдывать инвестиции.
Попробуйте действовать согласно пошаговым инструкциям в статье или воспользуйтесь подробным гайдом для настройки аналитики. Чтобы решение продлить подписку основывалось на цифрах и больше не переживалось как рискованное приключение.