Localhost and development

Tracking is off on localhost and 127.0.0.1 by default, so your own development traffic does not enter your real numbers.

Turning it on for testing

<script
  defer
  data-website-id="ts_a1b2c3d4e5f6"
  data-domain="example.com"
  data-allow-localhost="true"
  src="https://truestat.io/js/t.js"
></script>

These events go into your real numbers and count against your monthly event limit. There is no separate development dataset. Turn it on to check the tag fires, then turn it off — or read the next section for a way to leave it on safely.

The better pattern: leave it on, exclude your machine

If you want tracking on in development permanently — to test custom events, for example — leave data-allow-localhost="true" in place and exclude yourself instead.

In your browser's console, on the origin you are testing:

localStorage.truestat_ignore = "true";

From then on the script does nothing on that origin, in that browser. To undo:

delete localStorage.truestat_ignore;

Two things to know:

• It is per origin and per browser. localhost:3000 and localhost:5173 are separate origins and each needs the flag. So does every browser and every profile you test in.

• Clearing site data clears the flag. If you clear storage while debugging something else, you have silently re-enabled yourself.

The flag is checked before anything else happens, so it costs nothing and it works even when the collector is unreachable.

Pages opened as files

A page opened with file:// is not tracked. Add data-allow-file-protocol="true" if you need it — but serving over HTTP, even python -m http.server, is a closer match to what your visitors will experience.

Excluding a whole staging site

If your staging site has its own hostname (staging.example.com), the cleanest answer is not to put the tag on it at all.

If it shares a build with production and you cannot conditionally omit the tag, exclude its paths or use a second TrueStat site for it. Note that a subdomain of your registered domain is allowed automatically, so staging.example.com traffic will land on your production dashboard unless you do something about it.

Excluding your own IP in production

Different problem, different tool. If your own visits to the live site are inflating your numbers, add your IP under the site's exclusions:

1. Site settings → Excluded IPs.

2. Add your address.

Your IP is hashed before it is stored — the raw address is never written. The hash is scoped to your site, so it means nothing anywhere else, and it survives the daily salt rotation so an exclusion you set today still applies tomorrow.

Excluded events are never stored and never count against your event limit. See Excluding your own visits.

Debugging what the script is doing

The script logs to the console when something is wrong — a rejected event name, an oversized parameter set. Those messages are on by default and are how you find out an event was dropped, because the server's response deliberately contains no field names.

To silence them in production:

data-disable-console="true"

Note that this attribute controls logging only. It does not affect what is tracked.