DataSag guides · Updated 27 October 2026
Verify DataSag analytics on Jekyll
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. This guide applies to Jekyll.
Start with the Jekyll installation
Find the layout chain used by your Jekyll pages and posts. Add the deferred script once to the shared head template or its include. Keep the existing Liquid content and include structure, build the site and deploy the generated output. A theme-provided layout can require a local override rather than editing a gem.
Front matter selects layouts, and a page can bypass the shared default layout. Check standalone pages, posts and archive templates. Updating a source layout does not update a hosted site until the build and publication step completes.
Use the public project key from the DataSag project you are inspecting. A test on a preview domain does not confirm that the production domain has the same code or settings.
Verify DataSag analytics in Jekyll
- Trace the front matter layout selected by a post and a standalone page. Confirm their layout inheritance reaches the shared head containing DataSag. Preserve content variables and theme includes while adding the single external script.
- Build with the same configuration and base URL used for publication. Inspect the generated post and page HTML, then open those public URLs. The required data-datasag-key must be attached to the actual emitted script element.
- Visit an archive or custom landing page that may use another layout. Confirm whether it should be tracked and whether it inherits the installation. A working homepage alone does not establish coverage for documents with different front matter.
The selected layout chain produces one keyed tracker in the intended post, page and archive output.
Complete the collection checks
- 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 public path you tested, the browser state, the approximate time and the observed request. Check one direct page load and one later navigation so the result covers more than the homepage.
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.
Installation snippet for Jekyll
The shared installation belongs in the head of the shared _layouts/default.html or its head include. Use this as the installation reference while checking the procedure above.
<script defer src="https://www.datasag.com/tracker.js" data-datasag-key="YOUR_PUBLIC_KEY"></script>Related Jekyll guides
References
Official Jekyll documentation covers the integration point. For DataSag data handling, read the privacy policy. Use support if a request fails after these checks.