Wyszukiwarka wewnętrzna w GA4: czego szukają klienci i czego dane nie pokażą

Wyszukiwarka wewnętrzna to jedno z niewielu miejsc w serwisie, gdzie użytkownik sam mówi, czego szuka. Nie zgadujemy intencji z kliknięć, tylko czytamy wpisane słowa. W GA4 ten sygnał zbiera zdarzenie view_search_results. W praktyce połowa wdrożeń go nie ma, bo strona wyników nie zmienia adresu URL.

Zdarzenie jest proste w założeniu i kruche w szczegółach: wystarczy jedna decyzja techniczna przy budowie wyszukiwarki, żeby przestało się wywoływać, a nikt tego nie zauważy przez rok.

Kiedy Google wywołuje view_search_results

Warunek jest jeden: użytkownik musi zobaczyć stronę wyników wyszukiwania, a rozpoznanie opiera się na obecności parametru zapytania w adresie URL. Pomiar zaawansowany rozpoznaje pięć domyślnych parametrów: q, s, wyszukiwanie, zapytanie oraz słowo kluczowe. W ustawieniach zaawansowanych zdarzenia możesz dodać własne nazwy parametrów, jeśli Twoja wyszukiwarka używa innego klucza.

Parametr search_term wypełnia wymiar Wyszukiwane hasło. Zdarzenie wysyła też parametr unique_search_term, ale tylko wtedy, gdy ma on wartość 1, czyli gdy hasło jest unikalne w ramach sesji. To szczegół, który tłumaczy, dlaczego liczba unikalnych haseł w eksploracji nie równa się liczbie wyszukiwań.

Osobny warunek dotyczy tagu Google. Jeśli strona korzysta z tagu Google, każde zdarzenie musi być objęte automatycznym wykrywaniem w ustawieniach tagu. Domyślnie wszystkie typy zdarzeń są włączone, ale przy wyłączaniu reklamowych typów zdarzeń łatwo wyłączyć też wyszukiwanie.

Pierwsza kontrola: czy adres się zmienia

Wejdź na swoją stronę, wpisz w wyszukiwarkę dowolne hasło i popatrz na pasek adresu. Jeśli po zatwierdzeniu pojawia się coś w rodzaju /szukaj?q=raport, pomiar zaawansowany ma sygnał i zdarzenie powinno się rejestrować. Jeśli adres zostaje ten sam, a wyniki pojawiają się pod spodem, zdarzenie nie ma czego wykryć.

Dokładnie tak działają wyszukiwarki oparte na AJAX-u, większość sklepów z filtrowaniem po stronie klienta i aplikacje jednostronicowe. Parametr może też lecieć metodą POST, czyli w treści żądania, do której tag nie ma dostępu. Wtedy trzeba dopisać zdarzenie ręcznie, bo żadne ustawienie w GA4 tego nie naprawi.

Ręczne wdrożenie przez GTM

Potrzebne są dwie rzeczy: wyzwalacz i tag. Wyzwalacz to zdarzenie niestandardowe, które dostaje push do dataLayer w momencie pokazania wyników, albo zmiana historii przeglądania połączona ze zmienną typu URL odczytującą parametr. Druga droga ma tę zaletę, że nie wymaga zmian w kodzie sklepu, o ile wyszukiwarka dopisuje parametr do adresu. W praktyce dataLayer jest wygodniejszy, bo uniezależnia tag od struktury adresu i od tego, czy platforma zmieni sposób budowania linków.

Tag to zdarzenie GA4 o nazwie dokładnie view_search_results, z parametrem search_term ustawionym na wartość z adresu lub z dataLayer. Nazwa musi być wpisana ręcznie, bo lista zdarzeń w interfejsie pokazuje tylko zdarzenia już zarejestrowane. Pamiętaj o jednej rzeczy: jeśli pomiar zaawansowany nadal działa, uruchomienie własnego tagu da podwójne zliczanie. Wyłącz opcję Wyszukiwanie witryn w pomiarze zaawansowanym albo nie dodawaj tagu w GTM.

Gdzie to zobaczyć w GA4

Osobnego raportu wyszukiwania w GA4 nie ma. Analiza idzie przez Eksploracje: w panelu Zmienne dodajesz wymiar Wyszukiwane hasło i ustawiasz go w wierszach. Bez filtra zobaczysz głównie wiersz (nie ustawiono), bo wymiar jest pusty dla wszystkich pozostałych zdarzeń. Filtr o nazwie zdarzenia z dokładnym dopasowaniem do view_search_results zostawia tylko wyszukiwania.

Jest tu drobna niespójność w dokumentacji Google. Tabela wymiarów podaje Wyszukiwane hasło jako wymiar standardowy, wypełniany parametrem search_term. Poradnik Eksploracji każe jednocześnie włączyć search_term jako wymiar niestandardowy. W praktyce sprawdź, czy wymiar jest widoczny. Jeśli nie jest, zarejestruj go jako wymiar niestandardowy o zasięgu zdarzenia. Kosztuje to jedno z pięćdziesięciu miejsc w usłudze standardowej, a po osiągnięciu limitu i usunięciu wymiarów na zwolnione miejsce czeka się 48 godzin.

Wysoka moc zbioru, czyli wiersz (inne)

Hasła wyszukiwania są z natury unikalne, więc wymiar ma wysoką moc zbioru. Google ostrzega, że takie wymiary obciążają raporty i eksploracje oraz powodują zbieranie danych w wierszu (inne). Dla decyzji biznesowych wystarczy zwykle dwadzieścia do trzydziestu haseł z góry listy. Pełny ogon zostawiasz w eksporcie do BigQuery, gdzie nic nie jest agregowane.

Czego to zdarzenie nie mówi

Nie ma w nim liczby wyników. Nie dowiesz się, czy wyszukiwanie zwróciło zero produktów, czy trzysta. To najczęstsza luka w analizie wyszukiwarki, bo hasła bez wyników są najcenniejszą częścią danych.

Nie ma też informacji o kliknięciu w wynik ani o tym, czy użytkownik znalazł to, czego szukał. Jeśli potrzebujesz liczby wyników, dodaj do zdarzenia własny parametr, na przykład results_count, i zarejestruj metrykę niestandardową. Drugie podejście jest prostsze: wysyłaj osobne zdarzenie, gdy lista wyników jest pusta.

Pytania, na które te dane odpowiadają

W sklepie najciekawsze są hasła, których nie ma w katalogu: nazwy modeli, których nie sprzedajesz, synonimy, których nie przewidziałeś, i literówki. Każde takie hasło to albo luka w asortymencie, albo brak aliasu w wyszukiwarce.

W serwisie treściowym powtarzające się hasła pokazują temat, którego nie obsługujesz, mimo że ludzie go szukają. W firmie B2B widać numery katalogowe, nazwy integracji i frazy typu cennik czy wdrożenie, czyli moment, w którym ktoś jest gotowy rozmawiać.

Osobna kategoria to hasła obsługowe: zwrot, dostawa, reklamacja, faktura. Jeśli pojawiają się często, problem nie leży w wyszukiwarce, tylko w informacji, której nie ma na stronie produktu. To zadanie dla treści, nie dla analityka.

Hasła konkurencji mają inną wartość: pokazują, z czym użytkownik Cię porównuje. To dane do działań marketingowych, nie do poprawiania wyszukiwarki.

Hasła to dane, które ludzie wpisują sami

W polu wyszukiwania lądują adresy e-mail, numery zamówień, nazwiska, a przy odrobinie pecha numery PESEL. Google wprost zabrania przesyłania danych umożliwiających identyfikację i wymienia adresy e-mail, prywatne numery telefonów oraz numery PESEL jako przykłady.

Pierwsza linia obrony to pomijanie danych, ustawienie strumienia danych z sieci. Działa po stronie klienta, usuwa adresy e-mail z parametrów zdarzeń oraz wskazane parametry zapytania z adresów w polach page_location, page_referrer, page_path, link_url, video_url i form_destination. Przy nowych usługach pomijanie adresów e-mail jest domyślnie włączone, starsze usługi trzeba włączyć ręcznie.

Pułapka jest oczywista, gdy się ją zobaczy: dopisanie q do listy pomijanych parametrów usuwa także wyszukiwane hasło. Zyskujesz czystość danych, ale tracisz całą analizę. Wybór jest więc świadomy, albo zbierasz hasła i pilnujesz, co ludzie wpisują, albo rezygnujesz z wymiaru na stronach, gdzie wyszukiwarka obsługuje sprawy klienta.

Pomijanie danych ma granice: działa tylko dla strumieni z sieci, nie sprawdza nagłówków HTTP, nie obejmuje Measurement Protocol ani importu danych. Ostateczna odpowiedzialność zostaje po stronie administratora usługi, a art. 5 ust. 1 lit. c RODO wymaga ograniczenia danych do tego, co konieczne.

Lista kontrolna na dziś

• Wpisz hasło w swojej wyszukiwarce i sprawdź, czy parametr pojawia się w adresie.
• Sprawdź, czy opcja Wyszukiwanie witryn jest włączona w pomiarze zaawansowanym i w automatycznym wykrywaniu tagu Google.
• Zbuduj eksplorację z wymiarem Wyszukiwane hasło i filtrem na nazwę zdarzenia.
• Dodaj parametr z liczbą wyników albo osobne zdarzenie dla pustej listy.
• Przejrzyj dwadzieścia najczęstszych haseł i zapisz trzy wnioski: luka w asortymencie, brak treści, brak aliasu.
• Sprawdź, czy hasła nie zawierają danych osobowych, i zdecyduj, co robisz z parametrem q.