Most stores can tell you their top search terms and nothing else, which is like knowing what questions were asked but none of the answers. The instrumentation that actually improves search is a join: every search query linked to the click that followed it, and the click linked to the add-to-cart after that. Without that join you are tuning search by taste. With it, search tuning becomes evidence. This is the event schema we run, the three reports it unlocks, and how to build it without drowning in personal data.
Why top-terms reporting is not enough
A list of popular queries tells you what shoppers want but not whether they found it. "Protein" might be your most searched term and also one of your worst-performing, and a top-terms report cannot tell the difference. The questions that move revenue are relational: after searching X, did anyone click? After clicking, did anyone buy? Which position did they click — the first result, or the fourth, because the first three were wrong? None of those are answerable from query counts alone. You need events that reference each other.
The event schema: one id ties it together
The whole system rests on a single idea: give each search a request id, and make every downstream event carry it.
Every search event carries a per-request id, and the click event that follows references it, so "what did shoppers click after searching X" is a query, not a guess. That join is ground truth. It is also how we review zero-result queries systematically — the same instrumentation that captures the click captures the result count, so a search that returned nothing is a first-class event rather than an absence.
Concretely, you emit a small set of events, each stamped with the search request id where relevant:
- search — the raw query, the result count, the timestamp, the request id.
- result_click — the request id, the product clicked, and its position in the results.
- add_to_cart — the product, and the request id if the add followed a search.
That is enough to reconstruct the entire search-to-cart path for any query. The position on result_click is the field people forget and later wish they had, because it is what separates a ranking problem from a catalogue problem.
The three reports that matter
From that schema, three reports do most of the work. Each isolates a different class of problem, which is the point — an undifferentiated "search is bad" complaint is not actionable, but "position one is being skipped on these twenty queries" is.
| Report | Question it answers | Fix it points to |
|---|---|---|
| Zero results | Which queries return nothing? | Synonym, catalogue gap, enrichment |
| Skipped position one | Is the top result wrong? | Ranking and relevance tuning |
| Clicks without carts | Found but not bought — why? | Price, stock, PDP, sourcing |
The zero-results report is a synonym and catalogue to-do list. The skipped-position-one report — queries where shoppers routinely click the third or fourth result rather than the first — is a ranking signal: your top result is confident and wrong. The clicks-without-carts report is the subtle one, because search did its job (the shopper found and clicked the product) and the problem lies past search, in price, availability or the product page. Keeping these separate stops you retuning ranking to fix what is actually a pricing problem.
A fourth view is worth adding once the three basics are running: search-to-cart broken down by query class — lexical versus intent, one-word versus long. This is how you find out whether an expensive layer is earning its place. If intent queries routed through the semantic layer convert as well as your lexical queries, the vector spend is justified; if they lag badly, the problem is either your triggering rules or the products those queries reach, and the join tells you which.
Build it GDPR-clean from the start
Search analytics does not need to be invasive to be useful, and building it clean is far easier than retrofitting. The join key is a per-request id, not a person — you are linking a query to a click within a session, which requires no identity at all. Treat behavioural analytics as consent-gated, keep the raw query text free of anything a shopper might paste that identifies them, redact and set a retention window, and remember that low counts after consent-gating mean fewer measured sessions, not broken tracking. This first-party, id-joined approach also sidesteps the blind spots of third-party analytics — it lives in your own event pipeline, and the same discipline that governs it is the consent model you already owe your shoppers.
What not to measure
A search dashboard fills up with numbers that look meaningful and change nothing. Total search volume is one — it moves with traffic, not with search quality. Average results per query is another — more results is not better, and this number rewards exactly the over-broad matching you should be fighting. Even a raw top-terms list, useful as a sanity check, is a poor optimisation target because your most-searched term is not necessarily your most-broken one. Anchor on the relational metrics — zero-result rate, search-to-cart by query class, and the click-position distribution — and treat the volume charts as context, not goals. A metric you cannot tie to a fix is decoration.
Instrument, then act weekly
The reports are worthless unread. The habit that improves search is a standing weekly review: open the three reports, take the single worst query in each, and fix it — a synonym for the zero-result, a ranking tweak for the skipped position one, a price or stock check for the click-without-cart. The synonym list and the ranking config are where those fixes land, and next week the join tells you whether they worked. Search quality is not a project you finish; it is a loop you run, and the query-to-click join is the instrument that keeps the loop honest.
Key takeaways
- Top-terms reporting is not enough — the questions that move revenue are relational, and only a query-to-click join can answer them.
- Stamp every search with a request id and make the click and add-to-cart events carry it; capturing click position is the field you will wish you had.
- Run three reports — zero results, skipped position one, and clicks without carts — because each isolates a different class of problem.
- Keep ranking, product and catalogue problems separate so you do not retune search to fix what is actually a pricing issue.
- Build it GDPR-clean: join on a per-request id, gate on consent, redact query text and set a retention window.
- Review weekly and fix the worst query in each report — the join then tells you whether the fix worked.
Frequently asked questions
What is site search analytics?
What is the query-to-click join?
Which site search reports should I build first?
How do I track search analytics without breaking GDPR?
Stop tuning search by taste.
The query-to-click instrumentation in this article is part of the marketplace and analytics stack we run on sites that already have traffic.
Request early access See the live marketplace →