DataSag guides · Updated 27 October 2026

Fix DataSag analytics not working on your website

Find the first missing step in the delivery chain: published HTML, executing tracker, tracking request, successful response and project report. Changing several settings at once makes the failure harder to identify.

Before you start

Install the DataSag script once on the pages you intend to measure. Use the public key from the project you are inspecting. Publish your change, then test the public domain rather than relying on an editor preview.

Account credentials, database credentials and provider API keys do not belong in the tracking snippet. Keep existing consent controls in place. Report availability depends on your current plan and provider connections.

Fix DataSag analytics not working: step by step

Confirm the change reached the public domain. Inspect the live HTML and clear only caches that serve the old document. A saved editor change may still need publishing.
Check that tracker.js exists in the Network panel and that the script contains the public key from the same DataSag project you are viewing.
Check whether your test browser is excluded with datasag_ignore. Restore inclusion with ?datasag_ignore=false only if this browser should count. Respect any consent controls configured on your site.
Inspect the browser Console for Content Security Policy or script errors. Check /api/track request responses: 400 indicates invalid input, 404 can indicate an unknown project key, and a server failure needs investigation rather than repeated snippet changes.
Try a controlled browser profile to identify an extension block. Do not bypass a visitor's privacy preferences. Then check the project's selected date range, path and domain.
Collect the affected public URL, approximate time, request status and installation location for support. Omit account credentials and visitor data from screenshots.

typeof window.datasag?.track
// If undefined, first investigate whether the script executed.

new URL(location.href).searchParams.get('datasag_ignore')
// Also check for a previously saved browser exclusion.

What a successful check looks like

The first failed boundary is identified and corrected, and a new controlled visit reaches the right project. The browser Console and Network panel provide the evidence.

Record the tested URL, date, browser state and observed request. Repeat on a nested page to check the shared installation. Keep the evidence so you can distinguish a later regression from a report-filter change.

Common mistake

Do not replace the public project key with a Supabase, Stripe or provider secret. The browser snippet uses only the project's public tracking key.