Troubleshooting

The most common issues and how to fix them.

No data is showing up

Work through these in order:

Confirm the snippet is on the page

Open your site, view source, and search for sa.js. If it's not there, the snippet didn't get added. Revisit the install guide for your platform.

Check your Site ID

The data-site value must match your Site ID exactly. A wrong or missing data-site means the script does nothing.

Look in the Live view

Open your site in one tab and the dashboard's Live view in another. You should appear within a few seconds. If you do, tracking works. The main reports update on their own shortly after.

In DevTools → Network, a working install shows sa.js loading and a POST to /api/flake answering 204.

Rule out a privacy signal (Do Not Track / GPC)

Snow honors Global Privacy Control and Do Not Track by default. When your browser sends one, sa.js loads normally and then sends nothing: no request, no console error. The install is fine; it is deliberately opting out.

The browser you test with is likely to send one. Brave and DuckDuckGo send GPC by default, and Firefox sends it in every private window (and in normal windows once "Tell websites not to sell or share my data" is on). Ask sa.js in the browser console:

window.sa?.status
// "tracking"     it is sending: check the Network tab
// "gpc", "dnt"   this browser sends GPC or Do Not Track
// "optout"       sa.optout() was called in this browser
// undefined      sa.js didn't run: check the console

A private window will not rule this out: in Firefox it is what turns GPC on. Test in a normal window of a browser you haven't hardened, or on your phone.

If another analytics tool on the same page is still recording those visits, that's expected, because most don't honor these signals. You can match that behaviour with data-honor-dnt="false", but that means ignoring a signal the visitor explicitly sent. See Privacy.

Rule out an ad-blocker

Many ad-blockers block analytics requests. Try a Chrome Incognito window, where extensions are off by default, or your phone. If data appears there but not normally, set up the ad-blocker bypass to recover blocked visitors. Already have a proxy? Make sure it doesn't end in /api/collect.

Ad-blocking and a privacy signal look identical in the dashboard, but differ in DevTools → Network: a blocked request appears and fails, while a privacy signal means no request is made at all.

Rule out a filtered test visit

Snow keeps automated traffic out of your reports, so visits from headless browsers, cloud servers and many VPNs never show. Neither do visits that match one of your exclusion rules, such as your own IP address. Visits from localhost or a domain that isn't added to the site are dropped. Their requests still answer 204, so test with a real visit to your live domain, ideally from your phone on mobile data.

I don't show up as a new visitor

In cookieless mode, the default, a visitor is a daily hash of your site, their IP address and their browser. A private or incognito window on the same device and network is therefore the same visitor until the ID rotates at midnight UTC: it adds page views, not a visitor. To see a new visitor appear, use another device on another network, such as your phone on mobile data.

In attribution mode a private window starts without cookies, so it does count as a new visitor.

"Failed to fetch" or events aren't sending

This is almost always about where events are sent. Check that:

  • Your collector URL is correct in the snippet's src (and data-api-url if you use a proxy).
  • The URL includes https:// and points to your actual Snow collector.
  • If you proxy events, the proxied path is reachable and forwards to /api/flake.

My proxy still misses ad-blocked visitors

Older proxy setups send events to a path ending in /api/collect, such as /sa/api/collect or a data-api-url of https://api.snowanalytics.app/api/collect. Ad-blockers block that path. EasyPrivacy, the list that uBlock Origin, Brave Shields, AdGuard and most other blockers turn on by default, blocks every request to a URL ending in /api/collect, on your own domain or ours. Proxying it changes nothing.

Move to /api/flake:

Update your proxy

Wherever your proxy forwards <your prefix>/api/collect, forward <your prefix>/api/flake to https://api.snowanalytics.app/api/flake instead. Keep the same headers. Settings → Proxy generates the updated config for your platform, and the per-platform guides show it in full.

Update data-api-url in your snippet

Change the end of the data-api-url value from /api/collect to /api/flake, for example /sa/api/flake, or https://api.snowanalytics.app/api/flake in Simple mode.

Check it in DevTools

Reload with your ad-blocker on. In Network, the request to /api/flake should succeed where the one to /api/collect was blocked.

/api/collect keeps working for visitors without an ad-blocker, so nothing breaks while you switch. The standard snippet (with no data-api-url) moves to /api/flake on its own.

A Content Security Policy (CSP) is blocking Snow

If your site sets a Content-Security-Policy, allow Snow's collector:

  • script-src: allow the domain that serves sa.js (your collector, or your own domain when proxying).
  • connect-src: allow the domain events are sent to (same collector or proxy).
Content-Security-Policy: script-src 'self' https://api.snowanalytics.app; connect-src 'self' https://api.snowanalytics.app;

Add these to the policy you already send rather than adding a second one: the browser enforces every policy it receives, so a second one cannot loosen the first.

With a Full mode proxy, 'self' covers both. In Simple mode events still go to https://api.snowanalytics.app, so keep it in connect-src.

Locations all show "Unknown" or one city

  • All "Unknown": the location database may not be configured on your Snow instance. This is a hosting-side setting. Whoever runs your Snow can enable it.
  • Everyone in one city: that's the classic proxy bug: events flow through your server and the visitor's real IP isn't forwarded, so everyone geolocates to your server. Forward the visitor IP as described in Forwarding the visitor IP.

Custom events aren't appearing

  • Confirm the event actually fires: add a quick console.log next to your sa.track() call, or click the element with the data-sa-event attribute and watch the Live view.
  • Check the event name for typos. Events are grouped by exact name.
  • Events sent from a server need the Events API and a valid API key, not sa.track().

Duplicate or missing payments

  • Revenue syncs from Stripe in real time and is reconciled periodically, so a briefly missing payment usually appears within a few minutes. See How revenue stays up to date.
  • If a conversion isn't tied to a visit, the visitor wasn't linked to the Stripe customer. Set up revenue attribution.

Still stuck?

Email us at [email protected] with what you tried and what you saw.

On this page

TroubleshootingNo data is showing upConfirm the snippet is on the pageCheck your Site IDLook in the Live viewRule out a privacy signal (Do Not Track / GPC)Rule out an ad-blockerRule out a filtered test visitI don't show up as a new visitor"Failed to fetch" or events aren't sendingMy proxy still misses ad-blocked visitorsUpdate your proxyUpdate data-api-url in your snippetCheck it in DevToolsA Content Security Policy (CSP) is blocking SnowLocations all show "Unknown" or one cityCustom events aren't appearingDuplicate or missing paymentsStill stuck?