Updated 2 October 2026

How accurate is trckable?

We do not ask you to take our word for it. Scripted visitors with known numbers visit a real server in three browsers, and every count in the report must match exactly. Here is what that covers, and what it cannot.

In short

  • 40 scenarios run on every change to the tracker, the npm package or the server's ingest, sessions and reports, in 3 browsers. Each states its numbers before it runs, and the report has to agree exactly. Only time is allowed a range.
  • The suite is a controlled test, not a claim about your site. It shows that what reaches the server is counted correctly, once. It cannot show that every visitor reaches the server.
  • The limits are on this page too: blocked scripts, no-JavaScript visitors, declined consent, bots and cookieless days.

The suite in numbers#

CI runs the suite and publishes its score, and this page is drawn from it: nothing here is typed by hand. The figures are those of CI's latest run.

In CI's latest run
Scenarios40
Browsers, running the same scenarios3 (Chromium, Firefox and WebKit)
Scenarios run in every browser38
Runs in all116
Numbers compared with their expected value585
Runs that matched exactly100%

The check fails the build unless every scenario of every browser was exact, and every browser ran the same scenarios. A change that makes a count wrong does not ship.

How a scenario works#

Each scenario gets its own site on a real trckable server, beside a real web server serving small pages. A scripted visitor (a real browser) then does things: loads pages, clicks buttons, goes offline, closes a tab, refuses a cookie. The scenario writes down the truth before it starts: how many visitors, sessions, page views, goals, and which sources and pages. Then it asks the server's report what it saw and compares field by field, exactly.

The one tolerance is time. A number of seconds is a range, because a browser's clock is not ours.

Everything runs against the program we ship, the same one that runs trckable Cloud, so there is no test double for the part being tested.

What the scenarios cover#

Pages and navigation

  • A plain page, a single-page app's route changes, and the same address again, which is not a new page.
  • Back and forward, a page prepared in the background, and hash routes when a site routes by them.
  • Typing in a search box that keeps its text in the address bar counts as one page.
  • The tag loaded twice, and the npm package on top, still counts a page once.

Delivery

  • Events made while offline arrive once the visitor is back online.
  • An answer that never came back is not counted twice when the event is sent again.
  • Events that never reached the server are sent on the next page, once.
  • A slow server and a quick visitor lose nothing.

A server that restarts

  • A server that crashes (kill -9) or is redeployed in the middle of a visit loses nothing and counts nothing twice.
  • A crash in the middle of a burst of clicks counts every one exactly once.
  • Ten thousand events sent twice, at once, are counted exactly once.

Consent and privacy

  • What a visitor does before answering the cookie banner is counted once they accept.
  • A visitor who declines is not counted at all, by a cookie or without one.
  • A visitor who leaves without answering is counted without a cookie.
  • Do Not Track and Global Privacy Control are honoured, directly and through the proxy.
  • A browser that refuses cookies is one visitor, not one per event.
  • Without a cookie or storage, an event the server refused is sent again from memory, once.
  • Leaving your own browser out with ?trckable=ignore holds on every page.
  • Cookieless visitors across UTC midnight are counted as the guide describes: a new day is a new hash.

Through your own domain

  • With the proxy and its key, visitors keep a long cookie and stay one person each.
  • A click before the first answer is the same visitor, and the checkout link carries them.
  • A proxy with no key says so loudly and counts nothing wrongly.
  • A reverse proxy that adds no key still sees every person as themselves.

Robots

  • Robots, scripts and referrer spam are not visitors, and a person beside them still is.
  • A browser under automation is not counted unless the site says it is testing.
  • AI crawlers are counted by what they were doing, and are never visitors.
  • Visits from data-centre networks are dropped by default.

Time, sources and goals

  • Time on a page is the time it was in front of the visitor, not the time it was open.
  • Closing the tab mid-visit still reports the time spent.
  • A page read for thirty-five minutes keeps its time in its own session.
  • Every visit keeps the source it arrived with, through pages and routes.
  • Every goal is counted once, for the visitor who reached it, and only a visit with none is a bounce.

What the suite does not prove#

A test of a controlled world cannot prove the real one. These are the limits, and none of them is peculiar to trckable.

  • Blocked scripts. A visitor whose browser or extension blocks the tracker is not counted. Sending events through your own domain avoids blocklists that match an analytics file or host by name, but nothing is unblockable, and we do not claim it is.
  • Visitors without JavaScript. The tracker is JavaScript, so a client that runs none is not a visitor. (AI crawlers are counted separately, from your server.)
  • Declined consent. If you use a cookie banner, visitors who decline are not counted. That is the point of asking.
  • Bots. Known robots, automation, referrer spam and, by default, data-centre networks are dropped. That is a filter, not a guarantee: a bot that looks like a browser from a residential address gets through.
  • Cookieless days. In cookieless mode a visitor is unique per UTC day. Someone who changes network or whose browser updates counts again.
  • Cookies in Safari. A cookie set by the page's script is capped at seven days there. A cookie set by your own server route lasts longer.
  • Very large ranges. Where a report would be slow to count exactly, breakdowns use an approximate count and say so.
  • Time. Time on a page is measured in the visitor's browser, and its clock is theirs.
  • Revenue. Revenue is the amount paid excluding tax and before fees, converted at the European Central Bank's rate, with refunds and lost disputes taken out. It is reconciled with your payment provider, not identical to its dashboard.

If you read nothing else: trckable counts what reaches it exactly once, and tells you where it cannot see.

Getting the most accurate setup#

  1. Install through your own domain. In Next.js it is two lines and two environment variables; for other servers, the same-origin proxy does the same. Set the proxy key: without it the route says so and counts nothing wrongly, instead of counting every visitor as your server.
  2. Check it. npx trckable doctor reads your setup and reports what it finds, including the address trckable sees for a request.
  3. Leave out your own visits with ?trckable=ignore.
  4. Connect your payment provider, so revenue comes from the provider's own events and not from the browser. See revenue attribution.
  5. Read the limits above before you compare numbers with another tool. Tools count different things.

Questions#

Is trckable perfectly accurate?
No tool is, and we do not claim it. The suite shows that what reaches the server is counted exactly once, in the situations it tests. The limits above are real, and they apply to the whole category.
How is this different from other analytics tools?
We have not tested other tools, and we make no claim about how their counts compare with ours. Each comparison page lists what the other tool says about itself, with sources: see all comparisons.
Can I run the suite myself?
Yes. It is part of the open-source repository, under e2e/accuracy, and its scenarios run against a built server. The contributing guide has the commands.
What happens if a scenario fails?
The build fails and the change does not ship. A bug we fix also gets a scenario: it says what the visitor does and what the numbers should be.
Where do the numbers on this page come from?
From CI. The scenario, browser, run and comparison counts are written by the suite itself after each run, and this page is rebuilt from them.

Keep reading#

Get started