Verify your analytics installation

Check that the Privatus Analytics tracker is installed and hits are arriving, with the automatic check, the Live page or your browser's network tab.

# Verify your analytics installation

> Check that the Privatus Analytics tracker is installed and hits are arriving, with the automatic check, the Live page or your browser's network tab.

## Automatic check

Open **Site settings → Tracking**, find **Verify installation** and click
**Verify**. We fetch your homepage, or another page you enter. The page
must be on the site's domain, one of its additional domains or a
subdomain of them. The check reports:

- whether a `<script>` tag loading `/js/pa.js` is present,
- whether its `data-site` matches this site's id,
- whether a `Content-Security-Policy` response header blocks the script or
  its requests (see [CSP](/docs/tracker/csp)). A policy set in a `<meta>`
  tag is not checked,
- a `Referrer-Policy` response header of `no-referrer` or `same-origin`
  (see [referrer policy](/docs/troubleshooting/referrer-policy)).

It reads the HTML your server returns and doesn't run JavaScript, so a
snippet injected by a tag manager or added by client-side code isn't
found. Use the live check below for those. The number of checks you can
run in a short time is limited.

The check is also an [API operation](/docs/api) and an MCP tool
(`tracking_verify`), so you can run it from a deploy pipeline. It needs
the Owner, Admin or Editor role.

## Verified sites and public pages

When the check finds the script on a page of the **site's own domain**, or
a subdomain of it, the site is **verified**. We run the check for you when
a site's first event arrives and once a day after that, so most sites are
verified without a click. A page on an additional domain doesn't verify the
site, and neither does a domain anyone can publish under, such as
`github.io` or `vercel.app` on its own. Changing the site's domain means it
is checked again.

Pages anyone can open stay offline until the site is verified, because
they are open to spam and phishing on a domain nobody has proved is theirs:

- [testimonial walls, pages, forms and widgets](/docs/testimonials),
- [shared dashboards and wallboards](/docs/reports/sharing),
- [status pages](/docs/features/status-pages), which need a verified site
  in the workspace, and on a custom domain that site's own domain or a
  subdomain of it.

Over the [API](/docs/api) and MCP, walls, widgets, forms, shared links,
wallboard links and status pages carry `site_verified`, so you can tell
why a public address responds 404.

[Uptime checks](/docs/features/uptime) run only against a verified site's
domains too. You can set all of these up before then. Their pages say what
is waiting, with a link to the check. If your homepage can't be fetched
(a login wall or a bot challenge), [contact us](/contact) and we verify the
site by hand.

## Live check

The install page shown after you add a site checks for the first event
every 5 seconds and shows a success message as soon as one arrives. You
can also open the
[Live](/docs/dashboard/live) page and load your site in another tab: your
visit appears within a couple of seconds.

## Check it yourself

1. Open your site with the browser's developer tools on the **Network** tab.
2. Filter for `pa.js`: it should load with status 200.
3. Filter for `event`: you should see a `POST` to `/api/event` with status
   **202**. The request body is a small JSON object, for example:

```json
   {"s":"pa_7Q2K9XH3AB","t":"pageview","u":"https://example.com/pricing","l":"en-US","w":1440,"i":0}
   ```

A 202 means the hit was accepted for processing. It can still be dropped
afterwards (for example as a bot, or because the hostname isn't one of the
site's domains). The [troubleshooting guide](/docs/troubleshooting/no-data)
lists the reasons.

> **Tip:** On `localhost` the tracker doesn't send anything. Add
> `data-debug="true"` to log each hit to the console instead of sending
> it (on any hostname, so remove it afterwards). `data-allow-local="true"`
> sends hits from a local server, but the server keeps them only if the
> hostname is one of the site's domains, which plain `localhost` can't
> be. See [Debug mode](/docs/tracker/debug).

Vis som Markdown

Automatic check#

Open Site settings → Tracking, find Verify installation and click Verify. We fetch your homepage, or another page you enter. The page must be on the site's domain, one of its additional domains or a subdomain of them. The check reports:

whether a <script> tag loading /js/pa.js is present,
whether its data-site matches this site's id,
whether a Content-Security-Policy response header blocks the script or its requests (see CSP). A policy set in a <meta> tag is not checked,
a Referrer-Policy response header of no-referrer or same-origin (see referrer policy).

It reads the HTML your server returns and doesn't run JavaScript, so a snippet injected by a tag manager or added by client-side code isn't found. Use the live check below for those. The number of checks you can run in a short time is limited.

The check is also an API operation and an MCP tool (tracking_verify), so you can run it from a deploy pipeline. It needs the Owner, Admin or Editor role.

Verified sites and public pages#

When the check finds the script on a page of the site's own domain, or a subdomain of it, the site is verified. We run the check for you when a site's first event arrives and once a day after that, so most sites are verified without a click. A page on an additional domain doesn't verify the site, and neither does a domain anyone can publish under, such as github.io or vercel.app on its own. Changing the site's domain means it is checked again.

Pages anyone can open stay offline until the site is verified, because they are open to spam and phishing on a domain nobody has proved is theirs:

testimonial walls, pages, forms and widgets,
shared dashboards and wallboards,
status pages, which need a verified site in the workspace, and on a custom domain that site's own domain or a subdomain of it.

Over the API and MCP, walls, widgets, forms, shared links, wallboard links and status pages carry site_verified, so you can tell why a public address responds 404.

Uptime checks run only against a verified site's domains too. You can set all of these up before then. Their pages say what is waiting, with a link to the check. If your homepage can't be fetched (a login wall or a bot challenge), contact us and we verify the site by hand.

Live check#

The install page shown after you add a site checks for the first event every 5 seconds and shows a success message as soon as one arrives. You can also open the Live page and load your site in another tab: your visit appears within a couple of seconds.

Check it yourself#

Open your site with the browser's developer tools on the Network tab.
Filter for pa.js: it should load with status 200.
Filter for event: you should see a POST to /api/event with status 202. The request body is a small JSON object, for example:

json

   {"s":"pa_7Q2K9XH3AB","t":"pageview","u":"https://example.com/pricing","l":"en-US","w":1440,"i":0}

A 202 means the hit was accepted for processing. It can still be dropped afterwards (for example as a bot, or because the hostname isn't one of the site's domains). The troubleshooting guide lists the reasons.

Tip: On localhost the tracker doesn't send anything. Add data-debug="true" to log each hit to the console instead of sending it (on any hostname, so remove it afterwards). data-allow-local="true" sends hits from a local server, but the server keeps them only if the hostname is one of the site's domains, which plain localhost can't be. See Debug mode.