Tracked events

A pageview says which page was opened. It does not say whether the reader copied the snippet, asked the assistant, scrolled past the intro, or left for your signup page. This page is the whole list of what else is recorded, field by field, so you can tell before you build a goal or a funnel whether the thing you want to measure is already being measured.

What you get#

Thirty-six named docs.* events, in seven categories, recorded on every documentation site with no configuration and no tag manager. Each one is a row you can filter in Feeds, match a goal against, rank in the analytics overview, or read back per visitor over MCP.

Recording them costs nothing against your project's balance, and nothing about the list changes with your plan.

The catalogue#

Every event carries your project's full name (owner/repo). The Also carries column is what it adds on top of that. Events marked beacon are delivered by navigator.sendBeacon at the moment the reader leaves; the rest ride the ordinary logging transport, which batches for two seconds.

AI assistant#

docs.ai_navigate and docs.ai_outbound are deliberately two events, not one. The first says the reader trusted the answer enough to open the page it cited; the second says the assistant handed them to your app, your repo, or somewhere else entirely — a commercial question, not a comprehension one.

Search#

Reading and engagement#

docs.pageview is the one event the browser does not send. It is written server-side, so it exists for readers with JavaScript disabled — which is also why a visit made of nothing but pageviews is treated as a crawler. On pages served from the cache the pageview is beaconed from the browser instead, and the ingest endpoint fills in the same IP and geography, so the two paths produce the same row.

seconds is emitted raw and clipped at 300 seconds before any report sums it. That clip, and why it exists, is in read time.

Content actions#

Navigation#

docs.heading_nav and docs.heading_view share the #anchor format on purpose, so a section aggregates the same whether readers jumped to it or scrolled to it.

Exits and sources#

docs.page_exit fires only on a real exit or reload. In-site navigation does not produce one, which is what makes the last docs.page_exit of a visit the page the reader actually left from.

Feedback#

The direction lives in the event name, not in a vote field: the event store's schema is a fixed set of field names, and an unrecognised field is rejected outright rather than dropped. Votes are recorded through a server route so a webhook can fire on them; if that request fails, the browser records the same event directly, so the count survives.

Automatic, or dependent on a feature#

There is no tracking toggle anywhere in Docsbook, and no enabled flag on any event. Every event above is emitted whenever the thing that produces it exists, which splits the list in two:

An "empty" event in your reports therefore has two possible readings, and they are different: nobody did it, or nothing can do it yet.

How it is delivered#

Ordinary events go through a transport that batches for two seconds and posts over fetch. That is fine for a click that leaves the page standing, and it loses everything for a click that does not — which is why the events tied to leaving take a second path:

1. Components register an exit collector. On pagehide, every collector is drained into one beacon, capped at 100 events, posted to a same-origin endpoint.
2. On iOS, visibilitychange → hidden triggers the same flush, because pagehide is unreliable there.
3. Collectors return only what they have not already sent, so an iOS flush followed by a real exit does not double-count, and a page restored from the back/forward cache can flush again.

Heading views are collected with an IntersectionObserver at threshold 0 with a -15% bottom margin, and each heading is unobserved once seen: a heading counts once per pageview, and only after it clears the bottom of the viewport rather than the instant it peeks in.

Why this is the right way#

How to read one visitor's events#

Two MCP tools reconstruct one anonymous visitor's path end to end, and both are reads: get_top_visitors lists the busiest visitors over a period, get_visitor_activity returns one visitor's events in order.

get_top_visitors(period: "7d", limit: 25)
  → [{ visitor_id: "a1b2…", pageview_count: 14, first_seen, last_seen, country }, …]
 
get_visitor_activity(visitor_id: "a1b2…", period: "7d")
  → { first_seen, last_seen, country, language, pageview_count,
      events: [
        { event: "docs.pageview",           at, path: "guides/quick-start" },
        { event: "docs.page_feedback_down", at, path: "guides/quick-start" },
        { event: "docs.search_no_result",   at, query: "rotate api key" },
        … ] }

visitor_id is a salted hash of the reader's IP scoped to your project; raw IPs are never returned. See how measurement works.

Limits and open questions#

• No webhook can fire on a docs.* event. These events live in the event warehouse, and nothing dispatches them. They can be filtered in Feeds and saved into a list, and they read as not_sent there because that is what they are. Alerting on reader behaviour goes through the derived webhook events — traffic drop, popular search, no-result search — not through this catalogue. See webhooks.
• Events are counted per event, not per visit. One reader copying five snippets is five docs.copy_code rows. Anything that has to be counted per visit — bounce, conversion, a goal — is derived by reconstructing the visit, not by summing this list.
• A reader with JavaScript disabled contributes only docs.pageview. Every other event above needs a running script, which is exactly what the behavioural crawler filter relies on.
• question and answer fields carry whatever the reader typed. Raw event reads are passed through a redactor that masks any field whose key or value looks like a token, key, JWT or authorization header, but a reader who types something personal into your assistant has typed it into your event store. Retention is 30 days.
• Under question: the catalogue is authoritative, but not exhaustive of the stream. What is verifiable is that these 36 names are the ones every surface — the panel, Feeds, goal validation, MCP — reads from one shared list, so a goal can only be declared on a name in it. What is not: a handful of additional docs.* names are emitted by the unclaimed-site teaser flow and are not in that list, which means they reach the store and are invisible in the UI. Treat the 36 as the complete set of events you can act on, not as a complete inventory of every string in the stream.

Related#

• How measurement works — visitor identity, bot filtering, retention and privacy for everything on this page
• Analytics overview — the cards and figures these events feed
• Goals and funnels — declaring an outcome on one of these event names
• Read time — docs.read_time as a report
• Webhooks — the events that can notify you