Website event tracking

Event tracking is where analytics setups go to die. It starts well, with three or four sensibly named events, and eighteen months later there are ninety of them, four mean roughly the same thing, two were renamed by somebody who has left, and nobody trusts any of it.

That outcome is almost entirely a design problem rather than a tooling problem, so most of this page is about design. The tooling section is short because the tools are less different than they look.

What is worth making an event

An event should represent a thing a person did that you would change the site over. That is a higher bar than most implementations apply, and applying it is what keeps the list short enough to trust.

Good candidates: a form submitted, a file downloaded, a video started and finished, a plan selected, a search performed with no results, an outbound link clicked, a checkout step reached. Each of those has an obvious decision attached if the number moves.

Bad candidates: every click on every element, scroll depth at ten per cent intervals, hover states, and anything captured because it was easy rather than because somebody asked for it. Autocapture tools make this failure mode cheap to commit and expensive to unwind.

A naming scheme that survives contact with a team

Pick one convention and write it down somewhere the next person will find it. The one that ages best is object then past-tense verb, lower case, underscore separated: `signup_completed`, `pricing_viewed`, `demo_requested`, `checkout_started`.

Put the variable part in properties rather than in the name. One `plan_selected` event with a `plan` property beats three events called `starter_selected`, `growth_selected` and `business_selected`, because the first can be grouped and the second cannot, and because the fourth plan you launch does not require a code change.

Agree the list before you implement it, and keep it in version control next to the code rather than in a document nobody opens. An event taxonomy is an interface between your site and your future self, and it deserves the same care as any other interface.

Events usually cost you money, and nobody reads that part

This is the practical detail that surprises people at renewal. On most analytics pricing, custom events count against the same allowance as pageviews.

Fathom's own FAQ confirms events count towards your monthly pageviews. Pirsch counts custom events and a share of session-extension events towards the page view limit. Absolutely Analytics counts pageviews and custom events against one combined allowance and says so on its pricing page. Matomo meters hits, which includes events, downloads and outlinks, so an event-heavy site consumes a Matomo plan considerably faster than its pageview count implies.

The consequence is that a chatty implementation can double your bill without doubling your traffic. This is another argument for a short, deliberate event list: it is cheaper as well as more useful.

What the tools actually differ on

For web analytics tools the differences are narrow. Nearly all of them support custom events with properties, most support defining goals from events without code, and several can track file downloads and outbound clicks automatically without you instrumenting anything.

The real split is between web analytics and product analytics. If your question is how many people clicked the download button, any tool here does it. If your question is which sequence of events predicts whether somebody is still using the product in week four, you want a product analytics platform with cohort analysis, and you want to accept the script weight, the cookies and the consent banner that come with it.

Buying the second when you needed the first is the most common and most expensive mistake in this market.

The rest of the field

Common questions

Related guides