Verify a website analytics installation before launch

Check the snippet and its placement

Copy the snippet from the DataSag project for the website you are publishing. The public tracking key belongs in data-datasag-key. It is different from a login credential, a Supabase secret, or a provider API key. Keep those secrets out of the public website.

Place the script once in the shared document or site-wide code area. Do not also place it in a reusable page section or component that mounts repeatedly. On a code-based website, inspect both the shared layout and any tag manager. On a hosted builder, inspect both site-wide and page-specific custom code.

Use the published page source to check the script address and key. A snippet saved in an editor does not prove the published site contains it. Replace example values with your own project key before the release.

<script defer src="https://www.datasag.com/tracker.js" data-datasag-key="YOUR_PUBLIC_PROJECT_KEY"></script>

Verify delivery without inventing traffic

Open the production website in a browser you control. Use Developer Tools and filter Network for tracker.js. Confirm that the script request succeeds. Then filter for api/track and inspect the destination, request payload, and response.

The tracker can use sendBeacon or a fetch request, with a fallback request if delivery fails. A downloaded script with rejected event requests is not a working install. Check browser errors, content security policy, project-key mismatch, and endpoint access before changing reporting filters.

For a controlled test, record the URL, time, browser, and intended action. Check the matching DataSag project rather than another similarly named project. Keep your test visits out of any claim about customer adoption or campaign performance.

Test the page types people actually use

Open the homepage, a content page, and a meaningful destination such as pricing or signup. Confirm that each page has the snippet. Then follow internal links and use browser back and forward navigation.

The DataSag tracker observes pushState, replaceState, and popstate navigation. It starts a new page when the pathname changes. A query-only or hash-only change does not create a separate pageview in that implementation. Choose test expectations that match those rules.

A page can generate several tracking requests for legitimate reasons. Scroll milestones, click heatmaps, custom events, and engagement updates are different from pageviews. Inspect eventName and pageview identifiers before you diagnose duplicate pageviews from raw request count.

Verify custom actions after success

If you use custom events, fire the event when the application confirms the outcome. A signup event belongs after successful signup, rather than every click on the submit button. A checkout click is not proof of a completed payment.

Wait until the tracker is available before calling its browser API. Keep event names stable and avoid personal data in event properties. Test success and failure paths so retries, validation errors, or repeated listeners do not inflate the action count. Report availability depends on the applicable plan.

// Call after the application confirms the signup succeeded.
window.datasag?.track("signup", { source: "website" });

Check campaign and referral evidence

Create a test landing address with a controlled utm_source, utm_medium, and utm_campaign. Open that address from the intended entry point and inspect the tracking payload. Confirm the values survive redirects and are present on arrival.

Keep campaign naming consistent across links. Test the final destination, because a redirect or link-shortening setup can drop query parameters. Do not attach campaign labels to every internal link, which can confuse the source story you want to inspect.

Referrer availability depends on the browser and source. An empty referrer is not proof that the installation failed. AI referral reports need recognizable source evidence, while a custom campaign test tells you only that those controlled campaign values were recorded.

Verify your privacy and exclusion choices

The current tracker uses session storage and supports optional persistent visitor storage. Review those behaviors for your site rather than assuming that a cookie-free snippet has no storage or consent implications. Apply the privacy and consent choices required for your implementation.

If you exclude your own browser using the DataSag ignore option, document that choice before testing. An excluded browser should not become your proof that tracking is broken. Also test with the production security policy and typical browser protections rather than relying only on a development environment.

Keep a release record

Write down the production URL, project, snippet location, tested paths, expected actions, and observed results. Repeat the relevant checks when you change the framework layout, publishing system, consent configuration, or custom event handlers.

A passing record says what you checked and what you saw. It does not promise every visitor will be measurable. That narrower record makes the reports more useful because later changes have a concrete installation baseline.

Sources

• MDN reference for document.referrer

Continue with a practical guide

• LLMEO for website owners: what to improve and measure
• AI citations and AI referral traffic measure different things
• Connect Google Search Console to DataSag
• Use DataSag Domain health to prioritize technical SEO fixes
• Build an AI visibility prompt test you can repeat

Install analytics on your platform or explore DataSag search and AI visibility.