Маркетинг горить, трафік відливається, кампанії оплачуються — а пошук залишається «десь поза кадром». Команда знає, що модуль розумного пошуку має продавати, але в GA цьому бракує доказів.
Маркетолог опиняється в ситуації, коли йому потрібно обґрунтувати інвестиції в інструмент, але немає чіткої моделі: як саме довести, що Multisearch приносить гроші.
Навіть коли з Google-аналітикою та відстеженнями все ок, не завжди фіксуються купівлі, здійснені за допомогою мультипошуку. Як в такому разі ухвалювати рішення, коли даних немає, а відповідальність — є?
Де губляться транзакції?
Багато 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 повинен виправдовувати інвестиції.
Спробуйте діяти за покроковими інструкціями в статті або скористайтеся детальним гайдом для налаштування аналітики. Щоб рішення продовжити підписку грунтувалося на основі цифр і більше не відчувалося як ризикована пригода.