A manual only helps when readers can find the topic they need and writers can see how it is used. Two features support both sides. Full-text search helps readers reach answers quickly, while web analytics can show which topics attract visits and how readers move through the help site. An online help authoring tool provides the search and lets you connect usage data, turning the help site into a resource you can measure and improve.
Search That Gets Readers to the Answer
Built-In Full-Text Search
Web help from an online help authoring tool includes full-text search across every topic. The reader types a word and gets a list of matching pages. Dr.Explain generates the search field along with the rest of the help interface automatically, with no code to write on your side, so search ships as part of the output rather than something you add afterward. It stays current with the content, because it is produced each time you publish.
Why Search Beats Scrolling
A table of contents assumes the reader knows which section holds their answer. Search does not. Someone who types the error message they see can find matching topics, even if the relevant page sits three levels deep. For a manual that grows with the product, search keeps every topic reachable without a menu that gets longer with each release.
Search in Web Help and in CHM
Search is not limited to the web output. A compiled CHM carries its own search: the Search tab in Microsoft’s HTML Help viewer gives desktop users full-text search too (Microsoft, HTML Help), and Dr.Explain produces both the web help and the CHM from one project. What differs is measurement. A hosted web page can send usage data to an analytics service, while a local CHM does not provide the same web analytics data, so the analytics below apply to the web output.
Analytics That Show What Readers Do
Connecting Web Analytics
Dr.Explain lets you integrate a web analytics tracker into the published help by adding its tracking code, so you can gather data on visitors and how they behave. Any standard analytics service works through that same mechanism, with Google Analytics the common choice. Once the code is in place, the web help can report page views and engagement through the analytics service you use. GA4, for example, reports average engagement time and page-level activity. One caveat on the metrics themselves. Google now runs on Google Analytics 4, which measures average engagement time rather than the older time-on-page figure that left with Universal Analytics when it stopped processing data on 1 July 2023 (Google). Reading the reports usefully means reading the current metric.
What the Numbers Tell You
The data points to specific fixes. The table pairs a common signal with the action it suggests.
| What you see | What it suggests |
| High views but short engagement time | Check whether readers find the answer quickly or leave because the page is unclear |
| A topic almost no one opens | Check whether it is hard to find, rarely needed, or a candidate for removal |
| Many sessions end on one page | Check whether the page resolves the reader’s need or leaves them without a useful next step |
None of these proves anything on its own, but each gives you somewhere to look that guesswork might miss. A topic no one opens deserves a closer look. It may be hard to find, rarely needed, or ready to be removed.
Turning Help into a Feedback Loop
From Guesswork to Evidence
Without data, a documentation team guesses which topics need work. Page analytics give you evidence: you see which topics attract visits, how readers engage with them, and which pages deserve a closer look. An online help authoring tool that builds in search and supports analytics turns the manual into a product you improve from real usage instead of assumptions. Checked with each release, the numbers show which topics attract visits, how readers engage with them, and which pages deserve another look.
