Iterant is in early access. These docs describe the product as it works today.
Iterant Docs

Tracking setup

How Iterant measures your published site: what's installed for you, what you connect, and how to confirm signals are flowing.

Iterant serves your pages, so it injects the measurement runtime into the HTML as it serves them. There is no tag to install, no script to maintain, and nothing to forget on a new page.

You set up what sits around it: the connections to other analytics tools, and, if your site sits behind your own reverse proxy, the rules that let that proxy forward the traffic Iterant needs.

Prerequisites

What Iterant installs

Every HTML page Iterant serves gets a small first-party runtime inlined into the <head>. It is a few kilobytes and makes no network request when it loads.

It reports back to a path on your own origin, so blockers don't treat it as a cross-site tracker and it adds no DNS lookup to your page load.

The runtime measures:

  • Page views and page exits, with engaged time.
  • Scroll depth, and which sections entered the viewport and for how long.
  • Clicks, including clicks on things that aren't interactive and rapid repeated clicking.
  • Form interaction: started, submitted, abandoned, and which field was last touched.
  • Web vitals samples (LCP, CLS, INP) and JavaScript errors.

Iterant also counts visits server-side, from the request itself. Ad blockers don't affect that count, which is why traffic numbers and behavioural numbers won't agree. See Visitors and leads.

Identity

The runtime holds a session id in sessionStorage and nothing else. No cookie, no localStorage, no persistent identifier, no cross-site profile. The id rotates after 30 minutes of inactivity and is gone when the tab closes.

Forms

Iterant wires the forms it builds for capture. It rewrites a form authored with a data-iterant-form key as it serves the page: the form gets a POST action pointing at a forms endpoint on your own origin, plus the hidden fields the capture path needs.

Two consequences:

  • Submissions work without JavaScript. Iterant accepts a plain browser POST and returns the visitor to the page they came from, so a failed script load costs you no leads.
  • A form key must be registered. Iterant records keys when you save a page carrying the form. It does not know a form pasted into your site from elsewhere, and it rejects those submissions.

Submissions land on Visitors → Leads.

Custom events

To count something Iterant doesn't measure on its own, tag the element with a data-iterant-event name:

<button data-iterant-event="pricing_toggle">Annual</button>

The name then becomes available as the Event key for a Custom event conversion. See Conversions.

If your site is behind your own proxy

When Iterant pages are served from your domain through a reverse proxy you control, that proxy has to forward the measurement traffic too. The usual failure is a CDN configured to allow only GET and HEAD, which drops every form submission without an error.

Two checks in the deployment wizard confirm this end to end. Open Settings → Domains, choose your domain, then Configure deployment and go to the setup step:

  • Reachability: "Whether your live pages resolve on your own domain. Checked automatically after each publish." It probes one real published page per path prefix and confirms the response came from Iterant, so a catch-all page on your site that answers 200 still reads as unreachable.
  • Forms: "Whether a form submission reaches us through your proxy. Run this before relying on lead capture." It sends a synthetic submission through your real proxy and confirms the record arrived. A proxy that answers 200 without forwarding still reads as a failure.

When the forms check fails, the wizard prints the fix for your specific provider. The general shape: your proxy must forward POST (and its OPTIONS preflight) to /_iterant/forms/*, with the request body intact.

Connecting other analytics tools

Connect other tracking and analytics services to your published pages under Settings → Tracking.

Data connections

These are read connections: Iterant reads your data to inform what it builds. They do not change your site.

  • Search Console Property: grant a service account restricted access, then paste your property. Full walkthrough: Setting up Google Search Console.
  • GA4 Property: add the shown service account email as a Viewer in GA4 → Admin → Property Access Management, then paste your numeric GA4 Property ID (GA4 → Admin → Property Settings). Iterant verifies access when you save, and rejects a property whose web stream doesn't point at this brand's domain. Full walkthrough: Setting up Google Analytics.

Tag IDs

The same page stores IDs for tags you want on your pages:

FieldFormatWhere to find it
Google AnalyticsG-XXXXXXXXXXMeasurement ID from Google Analytics 4
Meta PixelnumericPixel ID from Meta Business Suite
Google Tag ManagerGTM-XXXXXXXContainer ID from Google Tag Manager
Amplitudealphanumeric API keyAPI Key from Amplitude project settings

Each field validates its format on save and can be cleared with the Clear button. Saving any of them queues an update of your live site, and the page tells you where that update is: Redeploy queued, Redeploying published site, Live site updated, or Redeploy failed.

Google Analytics (the G-… measurement ID) and GA4 Property are different things: the first is a tag for your pages, the second is the read connection Iterant uses to pull engagement data back.

Lead delivery

The Lead Webhook card on the same page POSTs each new lead to your CRM. See Visitors and leads.

Confirming it works

Publish the site, then open a page on its live URL in a normal browser tab.

Scroll it, click something, and if there's a form, submit it.

Go to Visitors → Events and set the window to 24h.

Your visit appears as a session card with the events in order. If you submitted a form, the same visit shows a Lead badge and the submission appears under Leads.

Troubleshooting

Next

Visitors and leads: what the signals look like once they're flowing.

Last updated on

On this page