Site Search in Ecommerce: GA4 Tracking, Baymard UX, and Filters

Site search in an online store is one of the few places where a customer tells you, in their own words, exactly what they're looking for — you don't have to guess from clicks, you can read the query they typed. The trouble is this data is easy to collect by accident, or not at all, if you confuse two completely different "search" tools: the one that brings customers to your store from Google, and the internal one they use once they're already on your site. This article treats site search as a source of two different kinds of data at once: what customers search for and don't find — readable in Google Analytics 4 — and whether the results list itself helps them or gets in their way — measured against the UX guidelines Baymard has spent years testing. Both layers meet in one place that easily turns into a dead end for the store: the no-results page.

Two different search tools: Search Console and your store's internal search

It's easy to confuse these two tools, because both talk about "search" and both have a data panel inside Google. Search Console's help page describes the Performance report as showing "important metrics about how your site performs in Google Search results" — Clicks is "the number of times a user clicked your site from Google Search results," Impressions is "how many times your site appeared in Search results," and the Queries dimension in that report is a search query users typed into Google, before they ever reached your page. You can filter the report by search type (web — text-based or multimodal — image, video, news) — but those are still types of search on Google's side, not a window into what customers type into your store's own internal search box.

Search Console doesn't have, and can't have, that visibility — it has no way of seeing what happens on your site after someone lands on it. That's why you need a separate data source for internal search: the view_search_results event in Google Analytics 4. These two sources answer different questions — Search Console tells you what brings traffic in from Google (external discovery), GA4 tells you what people search for once they're already in the store (internal discovery) — and neither can stand in for the other: you need both.

How to set up site search tracking in GA4

GA4's Enhanced measurement ships with a built-in view_search_results event, which fires "each time a user is presented with a search results page, as indicated by the presence of a URL query parameter" (Google Analytics Help). By default, GA4 looks for one of five parameters in the URL: q, s, search, query, keyword. If your store's internal search uses a different parameter name — say, a custom implementation that uses term or searchterm — the view_search_results event will never fire until you add that parameter manually in GA4 under Admin → Data streams → your web stream → Enhanced measurement settings.

This detection works purely from the URL parameter. A search implemented through a POST request, through an SPA router with no parameter in the address, or through a path segment (e.g. /search/product with no ?q=) won't be picked up automatically — you'll need a manual gtag/GTM event or an extra rule in your tag configuration instead.

One configuration choice deserves particular attention: queries that return zero results. GA4 doesn't isolate these as a separate category on its own — you have to deliberately pull them out of view_search_results, for example by passing an extra parameter with the number of results returned (results_count or similar, set in GTM at the moment the results page renders). In practice, a list of zero-result queries is a list of two different problems at once: either a product the store genuinely doesn't carry, or a product the store does carry but has named or tagged in a way the search engine can't match. Telling those two cases apart — missing stock versus missing metadata — is the first step toward deciding what to do about the list.

What to read from the data: zero-result queries, popular queries, search exits

Once tracking is set up, you have three different angles on the same data, each answering a different question:

• Zero-result queries. As above — each one signals either a gap in the catalogue or a gap in synonyms/tags. A regular review of this list (not a one-off) shows whether the problem is growing after a new category launch or a product-naming change.
• Popular queries. What customers search for most often, regardless of whether search actually found it for them. If a popular query leads to a poorly visible category or a low-stock product, that's a concrete reason to improve its visibility in navigation, not just in search.
• Search exits. A session where the user searched, got results, and left without any further interaction — a different signal from a zero-result query, because results existed, they just didn't convince. It's worth checking whether the problem sits in result ranking (relevance) or in the list's presentation itself — which leads straight into the UX question about search and product lists covered below.

A no-results page must not be a dead end

A zero-result query doesn't have to be the end of the customer's journey — yet according to Baymard's benchmark, close to half of stores give that page no effective way forward. The worst version is a blank page with a single line reading "no results found" and nothing else — the moment a customer most easily just closes the tab, because the page offers no next step at all. Baymard puts it plainly: many sites "include 'search tips' on 'No Results' pages, such as suggesting users check for spelling errors or try broader, more general terms. While these tips are well-intentioned, we've observed that users rarely read or apply them effectively" — a no-results page needs concrete elements, not just advice.

Baymard lists five specific strategies that together reduce how many sessions end on an empty results page:

• Links to related categories, or an already-filtered list closest to the query's intent.
• Alternate-query suggestions with a product preview — Baymard recommends you "display a preview of the top 3–5 products for each alternate query," not just a plain text list of suggestions.
• Personalised recommendations, if the store already has behavioural data on the customer.
• Visible, direct support contact — Baymard advises "displaying the direct phone number — rather than hiding it behind a generic support link" to make it easier for a frustrated customer to reach out.
• Promoting popular products and categories (e.g. "Trending Now," "Best Sellers") as a last resort when the query doesn't match any category or product type.

A separate, closely related topic is typo tolerance in autocomplete suggestions. Baymard reports that "69% of sites don't support autocomplete spelling suggestions for slightly misspelled queries" — meaning a typo that doesn't exactly hit a product name often gets no suggestion at all, instead of being auto-corrected or suggested. Caveat: both Baymard facts come from its benchmark of US and European stores (not a survey of the European market specifically), and the articles carry their own dates — the no-results piece was published in 2019 and updated in February 2025, the misspellings piece dates from August 2021 — so treat these figures as an indication of the scale of the problem, not a current reading of any one market.

None of these elements require a catalogue change — they're changes to the results page's own logic and layout, and to autocomplete, independent of whatever the zero-result-query analysis from the previous section turned up. A well-designed no-results page and a regular review of the queries that lead to it are two separate, complementary actions — one improves the experience immediately, the other fixes the underlying cause over time.

Autocomplete: rules most stores don't fully meet

Before a customer reaches the results page, or the no-results page, they pass through autocomplete — and that's where Baymard finds a separate, recurring set of mistakes. According to Baymard, "search autocomplete is provided on 80% of e-commerce sites" in its benchmark, but "only 19% of sites get all the implementation details right" (article from August 2022). Selected practices from that list:

• A suggestion list that's too long. In Baymard's testing, once the list grows past around 10 items on desktop (around 8 on mobile), suggestions start to cause "choice paralysis" rather than help; its recommendation is no more than 10 suggestions on desktop and 4–8 on mobile.
• No visual distinction between suggestion types. "Scope" suggestions (a proposed category or brand, for example) should carry a different style from suggestions that simply match the typed text — otherwise the customer can't tell whether they're clicking the next step of the same query or a completely different path.
• Too much emphasis on what the customer already typed, rather than what the search engine is adding — the predictive part of a suggestion should be visually set apart, not just appended.
• Touch targets that are too small on mobile — when the spacing between suggestions is too tight, it's easy to tap the wrong one with a thumb, which isn't a problem with a mouse on desktop.

These figures come from Baymard's benchmark described in a 2022 article — treat "80%"/"19%" as an order of magnitude for the scale of the problem, not a current measurement of the European market.

Site search under Baymard's research lens

The scale of independent UX research into ecommerce search gives a sense of how widespread this problem is. Baymard tested search usability on "19 leading e-commerce sites across 8 different verticals," during which "more than 700 search-specific usability issues arose." That testing, together with a separate benchmark of 343 US and European sites (5,000+ manually reviewed search elements and 4,500+ categorised best- and worst-practice examples), was distilled according to the research page into 31 UX guidelines, described across five sub-reports: search query types, search form and logic, autocomplete, results logic and guidance, and results layout and filtering.

Baymard sums it up directly: ecommerce search "isn't as easy to use as it should be," and poor search quality "is present within all industries." The research page doesn't give a single update date for the benchmark — treat these figures (19 stores, 700+ issues, 343 benchmarked sites) as the cumulative output of Baymard's whole research programme, not one study from one year.

Filters and product lists — where search ends at a list

Search rarely works in isolation from the product list and its filters — a customer who typed a query usually still needs to filter the result by size, price, or colour. Baymard's separate research into product lists, filtering, and sorting describes an identically structured testing methodology to the search study ("19 leading sites across 8 verticals," participants aged 21–56), but here "more than 700 usability issues" relates to product lists, filtering, and sorting — the page doesn't say outright whether it's the same round of testing, so the two 700-issue figures aren't added together. Baymard distils those issues into 83 product-list usability guidelines. A separate benchmark covered "343 top grossing US and European e-commerce sites" assessed against the 70 most important (weighted) product-list guidelines, with 11,000+ UX performance scores and 9,000+ categorised examples.

The strongest single line from that research: "36% of sites [have] such severe design and feature flaws that it was downright harmful to their users' ability to find and select products." Baymard also estimates that the average site needs 35 design changes to reach optimal product-list usability — its own conclusion from its benchmark, not an independent audit.

Filters have one more consequence beyond UX itself: the URLs generated by filter combinations (faceted navigation) can create a practically unbounded address space for Google to crawl — which, left unmanaged, spends crawl budget that could otherwise go toward indexing genuinely new pages. That's a separate, technical SEO topic, which we cover with sources straight from Google's own documentation in our ecommerce SEO guide — here it's enough to note that a well-built filter solves both a UX problem and a crawling problem, and the two are worth solving together, not separately.

30-day plan: from tracking to fixes

Instead of waiting for a "full audit," this plan spreads the work across four weeks, from setup to the first fixes:

• Days 1–7 — setup. Check in GA4 DebugView whether view_search_results actually fires when someone searches in your store. If it doesn't, add the right URL parameter in Enhanced measurement settings, or configure the event manually through GTM. Also add a result-count parameter so you can isolate zero-result queries.
• Days 8–14 — data collection. Let data accumulate for a week, then pull three lists: zero-result queries, the most popular queries, and search sessions that ended in an exit with no further action.
• Days 15–21 — UX audit of search and the results list. Go through the search form, autocomplete, the results page, and the no-results page against the areas above — typo tolerance, suggestion styling, related categories, popular products on the no-results page, and whether the default sort order on the list actually matches intent.
• Days 22–30 — implementation and re-measurement. Make the fixes the query lists point to (missing synonyms, new tags, product-name corrections) and the ones the UX audit points to, then compare the same three lists from days 8–14 a month later, to see which zero-result queries disappeared and which still need a genuine catalogue change.

If you'd rather work through GA4 setup and a site-search UX audit together with someone who'll do it for the whole store, get in touch — it's also one of the items on our UX checklist for your store, alongside checkout and the product page, which we cover in our wider UX/UI section.