DataSag guides · Updated 27 October 2026

Track custom events on Jekyll

Use data-datasag-goal for a click goal, or call window.datasag.track after a completed action. Choose a stable event name and distinguish a click from a successful conversion. 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.

Track custom events in Jekyll

  1. Put data-datasag-goal on a link or button in the layout, include or raw HTML content you control. Inspect the generated element because Markdown processors or theme helpers may transform the original source markup.
  2. For a completed form event, call the API from browser JavaScript after the form service confirms acceptance. Keep that logic separate from Liquid templates that generate the page; a successful Jekyll build is not a visitor conversion.
  3. Build and test a post and a standalone page containing the interaction. Verify an accepted and rejected form attempt where applicable. A link to an external signup page should use a click-intent name unless success is independently observable.

The generated element or browser success handler records the defined event without confusing build-time rendering with visitor actions.

Complete the collection checks

  1. Write the event definition first. For example, signup_click means a visitor pressed a signup link, while signup_completed means your application confirmed account creation.
  2. For click intent, add data-datasag-goal to the element. The tracker delegates clicks, so you do not also need a JavaScript handler for the same goal.
  3. For a completed action, call the JavaScript API in the success handler. Wait for the tracker to be available. An optional guard avoids a crash but intentionally drops the event if the tracker has not loaded.
  4. Send only the context needed for the report, such as a form or plan name. Do not include email addresses, passwords, payment details or freeform form contents.
  5. Complete one successful and one failed attempt. Inspect /api/track for the exact eventName and properties. Only the successful attempt should emit a completed-action event.
  6. Check the event report available to your plan. Collection and access to reports are separate; review current plan details before depending on a particular report.
<!-- Click intent: use this OR your own click handler -->
<a href="/signup" data-datasag-goal="signup_click">Create account</a>

// JavaScript: inside the confirmed-success handler
window.datasag?.track('signup_completed', { form: 'main_signup' });

For click intent, add data-datasag-goal to generated links or buttons in a layout or supported raw HTML. A confirmed form submission requires browser code that receives success from the form service; Liquid rendering cannot observe that outcome.

What a successful check looks like

A controlled successful action produces one event with the agreed name. A validation failure does not emit a success event. Network evidence matches the report definition.

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 goal attribute on a submit button measures clicks, including attempts that fail. Do not report those clicks as completed signups or purchases.

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

Full Jekyll setup guide · Search and AI visibility

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.