DataSag guides · Updated 27 October 2026

Verify DataSag analytics on your website

A script tag alone does not confirm that analytics works. Verify the published document, the request to DataSag and the matching visit in the correct project.

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.

Verify DataSag analytics: step by step

Open the published website in a normal browser window with the Network panel recording. Use a browser profile where you can control extensions and your consent choice.
Filter network requests for tracker.js. Confirm it returns JavaScript successfully and that the rendered script has the project's data-datasag-key attribute. The example YOUR_PUBLIC_KEY must be replaced.
Filter for /api/track and reload once. Inspect a request with eventName null or absent. Its projectKey and path should match the chosen project and the page you opened.
Open that DataSag project, choose a date range containing today and inspect the matching path. Use the configured report timezone when checking dates.
Navigate to a second path, then use Back. Compare pageview requests with the route changes rather than counting every request as a pageview.

document.querySelectorAll('script[data-datasag-key]').length
// Expected: 1

document.querySelector('script[data-datasag-key]')?.getAttribute('data-datasag-key')
// Expected: your project's public key

typeof window.datasag?.track
// Expected after the script runs: 'function'

What a successful check looks like

One rendered tracker installation, a successful request for the intended page and a corresponding entry in the intended project. Scroll and engagement requests are separate event types.

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

A successful tracker.js download only proves that a file loaded. It does not validate the project key, consent state or tracking endpoint. Test a real published path before declaring setup complete.