A help center search log is the most honest feedback channel you own. Nobody types a search query to be polite, and nobody is answering a question you chose to ask. It is a list of things people wanted, in their own words, at the moment they wanted them.
The analytics screen that summarises it is only useful if you know what each number is counting. This guide is about the mechanics: what gets recorded, what gets merged, what never arrives at all, and which figures are safe to quote in a meeting. For what to do with the resulting list, the guide on search inside live chat covers the editorial side.
Two places a search can come from
Searches reach the log from two surfaces, and every row is tagged with which one:
- widget — the visitor searched your articles from inside the chat window.
- helpcenter — the visitor searched from your hosted help center page.
The split is worth reading rather than collapsing, because the two populations behave differently. Someone searching inside the chat widget has already decided they want help and is one click from talking to a person, so a failed search there is expensive. Someone searching the help center may be browsing. A no-results query from the widget is a stronger signal than the same query from the help center.
One implementation detail matters if you ever see the numbers look lopsided: the tag is effectively two-valued, and anything that is not explicitly recorded as helpcenter is stored as widget. There is no third bucket and no unknown category, so widget is the one that absorbs anything ambiguous.
What a single search records
Each search writes one row containing the query as typed, a normalised form of that query used for grouping, the number of results it returned, and the source tag. That is the whole record.
Two things are deliberately not in it. There is no visitor identity attached to a search, so you cannot trace a query back to a person or join it to a conversation. And there is no click-through recorded — the log knows a search returned four results, but not whether anyone opened one. Any claim about whether a search succeeded is an inference from the result count, not a measurement of behaviour.
That limitation is the single most important thing to hold in mind. A query returning results is not the same as a query being answered.
How queries are grouped, and what that merges
The top-queries list groups by a normalised form of the query, not the raw text. Normalisation lowercases the query and replaces every run of non-alphanumeric characters with a single space, then trims it.
The effect is mostly helpful. These all collapse into one entry:
Reset passwordreset password?reset password!!!reset-password
Which is what you want: one row saying eleven people asked about resetting a password, rather than four rows of three.
The effect is occasionally misleading, and it is worth knowing where. Because punctuation is flattened to a space, distinctions that live in punctuation disappear — a product name written with a hyphen groups with the same words written separately, and a version number with a dot splits into two tokens. If you sell something whose name depends on punctuation, expect it to be grouped more coarsely than you would like, and read the raw query text before concluding that people are searching for a different thing.
Letters and digits from any language are preserved, so accented and non-Latin queries survive normalisation intact rather than being stripped.
The searches that are never logged
Two categories of search never reach the log at all, and both matter for interpretation.
Empty searches are dropped. Unsurprising, but it means the log is not a count of how many times the search box was used.
Queries longer than 200 characters are dropped entirely. This is the one that catches people out. A visitor who pastes an entire error message, a stack trace, or a paragraph from an email into the search box produces no row at all — not a truncated one, not a no-results one. Nothing. Those are often your most frustrated visitors, and they are invisible in this data by construction.
So the log undercounts exactly the population you would most want to see. If your product produces long error strings that customers copy and paste, assume the real volume of failed searches is higher than the screen shows.
Logging is also best-effort by design: if writing the row fails, the failure is swallowed so the visitor's search still works. A search is never broken by the analytics behind it, which is the right trade, but it does mean the log is an operational record rather than an audit trail.
Reading the counters
The headline figures are searches in the last 7 days, searches in the last 30 days, and no-results searches in the last 30 days. All of them are computed in UTC, not your local time zone or your business calendar. For a team well east or west of UTC the daily boundaries will not line up with your working day, which matters when you are comparing a specific day against a release or an incident.
The no-results figure is the one to watch, but watch it as a ratio rather than a count. A rising no-results count during a week when total searches also rose is not a content problem. The number that means something is no-results as a share of all searches, and the direction it moves over a month.
The daily search series underneath is best read for shape rather than level. Spikes usually have causes you already know about — a release, an outage, a campaign — and a spike whose cause you cannot name is itself worth a few minutes.
The article tables, including the harsh one
Alongside the query lists the screen reports on the articles themselves: how many are visible, total views, and the counts of helpful and not-helpful votes. These are the articles in your knowledge base, counted across both places a visitor can reach them.
There is also a low-rated table, and it has a threshold you should know before you react to it. An article only appears once it has at least three votes, which keeps a single grumpy reader from condemning a page. The list shows a handful of the worst offenders rather than everything below a line, so it is a worklist and not a full audit — clearing it does not mean every article is well rated.
One quirk: an article that has been deleted but still carries historical votes appears as (deleted article). That is not a bug to report. It is feedback that outlived the page it was about, and the row can be ignored.
Read the low-rated list alongside the no-results list, because they describe opposite failures. No-results means the article does not exist. Low-rated means it exists and is not doing its job, which is usually the cheaper fix.
When the screen is empty
An empty analytics screen has several possible meanings, and they are worth separating before assuming the feature is broken.
The ordinary explanation is that nobody has searched yet, which is common on a new help center or one whose search box is hard to find. Before investigating anything technical, confirm that search is actually reachable from where your visitors are.
The second explanation is age. Search log rows are covered by data retention and are purged once they pass the retention age, so this screen is a rolling window rather than a permanent archive. If you want a long-run trend, record the monthly figures somewhere yourself. Nothing in the product will reconstruct them for you later.
The third is that search logging has not been provisioned on your account, in which case searching works normally and the log stays empty rather than raising an error. If the screen is empty while you can demonstrably run a search and get results, that is the case to raise with support — and the useful detail to include is that search works but nothing is being recorded.
Put it into practice
- Read no-results as a ratio of total searches, not as a raw count, and track the direction over months.
- Split by source. A failed search inside the chat widget is a stronger signal than the same one on the help center.
- Open the raw queries behind a grouped row before rewriting anything, because normalisation merges punctuation differences.
- Assume long pasted queries are missing. Anything over 200 characters was never recorded.
- Work the low-rated list only above the three-vote threshold, and ignore rows marked as deleted articles.
- Snapshot the monthly totals yourself. The log is a rolling window, not an archive.
- Remember what is not measured — nobody's click-through is recorded, so results returned is not the same as question answered.
Used carefully this screen tells you what your customers could not find, in their vocabulary, ranked by how often it happened. Used carelessly it tells you that searches went up. The difference is entirely in knowing what the counters are counting.
If the structure itself looks wrong rather than the search terms, what renaming a help center category does to your articles covers how categories bind to articles and the two independent reasons one can be missing from your public site.
Searches that returned nothing also feed the AI knowledge backlog directly, deduplicated against your other coverage gaps. Where your AI source suggestions come from shows how they are ranked once they get there.