• Головна
  • /
  • Блог
  • /
  • Як правильно аналізувати внутрішній пошук користувачів на вебсайті?
03.06.24
bg-image

Як правильно аналізувати внутрішній пошук користувачів на вебсайті?


Сьогодні продовжуємо говорити про івенти розширеної статистики в Google Analytics 4. Якщо ви пропустили, то ось лінки на інші статті з цієї серії:

  1. Як правильно аналізувати кліки по зовнішнім лінкам в GA4?
  2. Чому важливо аналізувати скролінг сторінок, та як це зробити з допомогою GA4.

У цій статті будемо розбирати такий івент розширеної статистики, як відслідковування взаємодії користувача з внутрішнім пошуком. У GA4 ця подія називається view_search_results.

В статті поговоримо про наступне:

Якщо ви надаєте перевагу відео-контенту, то ви маєте можливість переглянути відео-інструкції розбору внутрішнього пошуку користувачів на сайті. Посилання залишу тут:

Почнемо з того, що таке взагалі внутрішній пошук на сайті та що Google Analytics 4 розуміє, під внутрішнім пошуком на сайті. Для нас все дуже просто, на більшості сайтів є поле для вводу, в яке ми можемо ввести наш запит, наприклад назву товару, і сайт поверне нам сторінку з результатами пошуку. Наприклад, ми ввели слово “тест” і отримали такий результат пошуку:

Зверніть увагу, є свого роду два різновиди такого пошуку:

  1. Перший варіант - ми пишемо щось, наприклад, “test”, натискаю “Enter”. І в цьому випадку нас кидає на сторінку результатів пошуку.

При цьому в URL у нас з'явився спеціальний get-параметр, назва якого в даному випадку query, але взагалі може бути й інша. Його значення, в нашому випадку - це “test”. Це значення і є пошуковим запитом, який ввів відвідувач.

3.2 1-варіант пошуку w

2. Може бути також інший різновид пошуку. Наприклад, ми хочемо ввести “телевізор Sony”, і вже після того як ми вводимо перший символ, сайт одразу пропонує певні варіанти.

3.4 2-варіант пошуку w

І ми можемо перейти, на конкретний товар, який система вирішила нам показати.

3.4.2 немає get-параметра w

Цей випадок має деякі відмінності від попередника:

  • по-перше, якщо я клікну на товар в блоці “Популярні товари” - мене перекине не на результати пошуку, а одразу на сторінку конкретного товару;
  • по-друге, швидше за все в кінцевому URL картки товару не з'являться ніякі додаткові get-параметри.

Чому я звернув увагу на ці два моменти? І чому взагалі виділив два окремих типи внутрішнього пошуку на сайті? Все дуже просто: для відвідувачів сайту різниці не має, що перший випадок, що другий - це взаємодія з внутрішнім пошуком, але для Google Analytics 4 ситуація виглядає інакше, оскільки він бачить тільки той тип пошуку, коли з'являються додаткові get-параметри.

Чому стандартне відслідковування взаємодії з внутрішнім пошуком підійде не для всіх сайтів, та як бути в такому випадку

Зараз я поясню чому взагалі в рамках статті, яка мала бути про роботу з даними, я на початку додав таку вставку, де ми говоримо про внутрішній пошук, і взагалі чому я пишу про якісь незрозумілі, можливо, багатьом get-параметри? Тому що насправді ось це налаштування, яке ви бачите в розширеній статистиці, що підписано тут як site search, допомагає відслідкувати не весь внутрішній пошук на сайті, а тільки певну його частину.

3.5 де побачити get-параметри w

Якщо ми натиснемо “Show Enhanced Settings” (Показати розширені налаштування), то ми побачимо get-параметри, які вже підтримуються за замовчуванням. Зверніть увагу, наприклад, на нашому сайті був параметр query.

3.6 get-параметр query w

Якщо ми подивимось налаштування, то помітимо, що такий параметр в нас є за замовчуванням. Тому саме ця частина пошуку на сайті у нас би прекрасно спрацювала. На жаль, той випадок, коли люди відразу потрапляють на картку товару, цей функціонал не покриває. Тому вам потрібно буде робити певні налаштування додатково.

Зверніть увагу! Навіть коли нас перекидає на сторінку результатів пошуку, не завжди з'являються додаткові get-параметри. Це залежить від того, яку саме CMS-систему ви використовуєте.

Тому, перш ніж читати далі, скористайтесь пошуком на своєму сайті та перегляньте чи додається у вас до сторінки результатів пошуку get-параметр і який саме. Якщо вашого параметру немає серед зазначених, то вам не потрібно бігти і робити якесь складне налаштування. Достатньо просто прописати свої параметри в “Additional Query Parameters” (Додаткові параметри запиту) .

3.7 додаткові get-параметри w

Тобто в цьому випадку ніяких складнощів не буде. Зовсім інша справа, якщо у вас взагалі не використовуються get-параметри, тоді вам потрібно або змінити функціонал пошуку на сайті, або налаштувати відслідковування взаємодії з ним через GTM та передачу кастомних івентів.

Що ж, уявимо, що вам пощастило, і весь ваш внутрішній пошук на сайті веде на сторінки з get-параметрами. Де ж знайти потрібні значення в інтерфейсі аналітики та як взагалі ними можна скористатись і, головне, - для чого?

Цей івент, як і будь-який інший, ви можете знайти в звіті “Events” (Події). Наш івент називається view_search_result. Написавши в пошуку “search”, ми швидко знайдемо потрібний нам івент.

3.8 де знайти івент внутрішнього пошуку

Але як завжди в цьому стандартному звіті немає ніякої додаткової інформації про те, де люди шукали, і що саме шукали у вас на сайті(

Як створити та використовувати звіт внутрішнього пошуку для аналізу вебсайту

Щоб це виправити нам доведеться йти в блок “Explore“ (Дослідження) і будувати там потрібне дослідження. Відкриваємо нове дослідження, і додаємо потрібні параметри та показники.

3.9 нове дослідження

Якщо ви ще не знайомі з цим блоком і не знаєте з чого тут взагалі почати і як, то це я розбираю у іншій статті з цієї ж серії. У ній ми якраз говорили про те, як побудувати свій перший звіт в блоці дослідження на прикладі івенту click - Як правильно аналізувати кліки по зовнішнім лінкам в GA4?

Ну а ми повернемось до сьогоднішньої теми. Нам з вами знадобляться наступні параметри:

  • Search term (Пошуковий термін) у розділі General (Загальні). Він означає саме те слово або те словосполучення, яке користувач вводив у поле внутрішнього пошуку.
3.10 параметри для звіту по site search
  • Page Location (Місцеположення сторінки) або Page Path and Screen Class (Шлях до сторінки й клас екрана). Вони потрібні для того, щоб зрозуміти на якій сторінці відбулась дія.
3.11 параметри для сторінки (1) w
  • Event name (Назва події). Потрібен для того, щоб правильно задати фільтри.
3.12 параметри для івенту (1) w

Щодо метрик ми скористаємося двома класичними:

  • Total users (Усього користувачів)
3.13 метрика total users (1) w
  • Event Count (Кількість подій).

Натискаємо “Import”.

3.14 метрика event count (1) w

Тепер давайте зберемо все і подивимось, що у нас фінально вийде.

Отже, якщо ми хочемо дізнатися які найпопулярніші пошукові запити вводять наші відвідувачі сайту, нам потрібно вкинути параметр Search term (Пошуковий термін) та додати два наші показники Event Count (Кількість подій) та Total users (Усього користувачів). І ось ми з вами вже бачимо відповідь на наше питання.

3.15 дивимось найпопулярніші пошукові запити w

Зверніть увагу, у нас є пустий рядок. Це тому, що ми не додали фільтр по потрібному нам івенту.

3.16 додаємо фільтр Event name w

Тобто якщо ми використаємо Event Name (Назва події), з умовою exactly matches та view_search_result, то, відповідно, у нас з вами пустий рядок зникне.

3.17 пустий рядок у звіті зник w

Для чого взагалі може знадобитися ця інформація?

Наприклад, аби розуміти, що саме люди не можуть швидко знайти на вашому сайті. Або ви також можете використати ці запити, щоб підібрати ключові слова для запуску реклами в Google Ads.

Але звісно на цьому аналіз даних внутрішнього пошуку не закінчується: коли ви бачите, що саме люди у вас шукають, було б також правильно зрозуміти де саме вони це шукають.

Наприклад, ви потрапили в наступну ситуацію. Є реклама, люди по рекламі переходять на певну сторінку, але там не знаходять товар, який очікували побачити. Тому вони ідуть користуватися внутрішнім пошуком. Як це можна побачити?

Перш за все, ми з вами можемо додати Page location (Місцезнаходження сторінки) до нашого звіту.

3.18 додали page location w

Це допоможе нам зрозуміти на якій саме сторінці у нас відбулась подія. Але є один важливий нюанс - подія пошуку у нас завжди відбувається на сторінці результатів пошуку.

Зверніть увагу, на скріні ми з вами бачимо в URL ту ж саму фразу, у нас сторінка завжди - shop.merch.google/search

3.19 shop.merch.google w

Тобто ця інформація не несе нам багато цінностей. Що робити в такому випадку?

В такому випадку вам знадобиться не Page location (Місцезнаходження сторінки), а Page Referrer (Напрямок переходу на сторінку), це попередня сторінка перед результатом пошуку. Давайте перейдем в “Dimensions” (Параметри) та додамо ще один параметр Page Referrer (Напрямок переходу на сторінку).

3.20 додаємо page referrer w

Виведемо його, а Page location (Місцезнаходження сторінки) ми можемо прибрати.

3.21 додали page referrer w

Тепер стало цікавіше:

  • На скріні нижче ми можемо побачити, що в нас є люди, які перейшли з домену google.com, і вони одразу потрапили на сторінку пошуку.
3.22 дивимось на рядок без referrer w
  • Є також інший випадок, коли referrer взагалі відсутній, але людина теж одразу потрапила на сторінку пошуку. Наприклад, через те, що хтось скинув своєму другу лінк одразу на сторінку пошуку.
  • Окрім того, не завжди люди будуть переходити з якихось зовнішніх доменів чи зовнішніх лінків одразу на сторінки пошуку. Може бути ситуація, коли ми бачимо, що людина перейшла з головної або з якоїсь іншої сторінки сайту. У такому разі відбувається внутрішній перехід, і саме в цьому випадку буде цікаво, з якого джерела трафіку був перехід на наш сайт. І це ми теж можемо дізнатися.

Переходимо в “Dimensions” (Параметри) і нам з вами знадобляться саме ті джерела трафіку, які починаються на “Session” (Сеанс). Подивимось на прикладі Source/Medium (Джерело/Канал). Якщо я напишу Source/Medium (Джерело/Канал), то у нас з’являються декілька варіантів: просто Source/Medium (Джерело/Канал), Session Source/Medium (Джерело/Канал сеансу), First user Source/Medium (Джерело або канал першого залучення користувача). Все це різні параметри.

3.23 source medium w

Зараз нам з вами потрібен саме Session Source/Medium (Джерело/Канал сеансу), вибираємо його і одразу додаємо у звіт.

3.24 додали source medium w

Що ми тепер бачимо:

  1. Тут люди потрапили до нас з LinkedIn і одразу на сторінку пошуку (див. №1 зі скріну вище)
  2. Тут люди потрапили з google/organic на головну сторінку, а потім перейшли на сторінку пошуку (див. №2 зі скріну вище)

І таким чином, ми з вами розуміємо, що саме люди шукали, яка була попередня сторінка перед пошуком та з якого саме джерела вони наш сайт відвідали.

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

  • З однієї сторони, це може бути точкою росту. Ви можете почати продавати такі товари. Або якщо ми говоримо про блоги, як альтернативний ресурс, де теж може бути внутрішній пошук, то ви можете писати статті на потрібні теми.
  • Або з іншої сторони - ви можете зрозуміти, що у вас таких товарів ніколи не буде, але піти подивитись на джерело трафіку і побачити, що це платна реклама. І тоді є сенс піти до вашого ppc-шника і показати йому, який трафік він приводить, і що людей, насправді, цікавить щось інше, чого на вашому сайті немає.

Замість висновку

Тепер ви знаєте все про подію view_search_results: як вона працює та що показує. Сподіваюсь, ви зможете використати цю інформацію для покращення ефективності вашого сайту.

Якщо вам сподобалась ця стаття, не забудьте поділитись нею з друзями.

Ще більше корисної та цікавої інформації буде виходити в наступних статтях вже дуже скоро. Ну а якщо ви хочете отримати побільше таких лайфхаків та глибше зануритися в аналітику вебсайту, то ви можете зробити це записавшись на курс від PROANALYTICS.ACADEMY. Можливо курс “GA4 Basics” - це саме те, що вам зараз потрібно для того, щоб підвищити свій рівень роботи з Google Analytics 4. Таких нюансів та цікавих способів використання даних, як ви побачили у статті, на курсі дуже-дуже багато.