Documentation

What is recorded without you writing any code

• Page views: on every page load. Also whenever the site changes the address in the browser bar without loading a fresh page — the way most modern sites move between screens, sometimes called a single-page app. The tracker watches the three browser events that do that (pushState, replaceState and popstate). Recorded with each page view: the address, and the page the visitor came from before it.
• Clicks: on the things people can click — links, buttons, submit inputs, elements carrying an accessibility role such as [role=menuitem], and anything you have marked with a data-track attribute. When someone hits the icon inside a button, the tracker looks up to three levels outwards to find the button itself. The record then names the control rather than the icon.
• Form submissions: when a <form> is submitted. The tracker never reads what people type into a form. It records that the form was sent, which form it was, and any data-track attributes on it.

The counts at the top

Five totals — everything, page views, clicks, submitted forms and your own custom events — each with its change against the period immediately before the one you are looking at. The chart below them splits the same total by type, day by day, which is where you notice one kind of event falling away while the rest hold steady. Both follow the date range at the top of the Events page.

The list of individual events

One row per recorded event, newest first, in pages you can step through. You start with the time, the type, the page and the feature name. The Columns button adds more: the URL parameters, the anchor (the <code>#section</code> at the end of an address), the element, its visible text, the referrer (the page the visitor came from), the data-track name and the attributes you attached yourself. Opening a row’s menu shows the complete record of that one event. That is the fastest way to confirm a new tracking attribute is arriving the way you meant it to.

Narrowing the list

The date range decides which days you see. The Filters button opens a panel where you pick an event type — page view, click, form submission or custom. You can then add conditions on what was recorded: the page path, the site address, the anchor, a single URL parameter, the element’s tag, or the attributes you attached yourself. Filters take effect when you confirm them, so you can set up several at once without the table reloading in between.

What is kept with each event

Each event keeps what was true at the moment it happened. The address is split into four parts and stored separately: the site, the path, the URL parameters and the anchor — the #section at the end. Alongside it the event keeps the element’s tag, a CSS selector pointing at it, a more general version of the same selector, and the element’s visible text. A CSS selector is the element’s address inside the page, written the way a stylesheet picks things out. A page view also keeps where it came from, and any data-track or data-track-* attributes you put on the element are kept too. A page is its site and path alone, so /search is one page however it was searched. Password fields, hidden fields and credit card inputs are never recorded at all, and URL parameters that tend to carry personal data are removed before anything is sent.