What the pixel fires, what it stores, and what it never collects.
If you're deciding whether to install the nod. pixel, or explaining it to someone who has to approve it, the question underneath is usually: what does this thing actually do to my site and my visitors' data? This article answers that in plain terms.
The pixel sends a small number of event types. Nothing more.
Page views. On every page load it fires one page_view immediately. On a single-page app (SPA), it also watches for real navigation — when the URL path or query actually changes, not just a hash or a no-op update — and fires a fresh page_view for that virtual page. Clicking through a collection filter or a quick-view modal that changes the URL counts as a page view; a hash change or a re-render that leaves the URL alone does not.
Cumulative active-engagement checkpoints. The pixel measures active reading time only while the page is visible and the browser window is focused. It checkpoints every 30 active seconds and flushes on blur, tab hide, page exit, and SPA navigation. Every checkpoint for a page carries a cumulative total under one page_view_id; retries and lifecycle flushes therefore use the maximum, not a sum. Wall-clock session duration remains available as a diagnostic, but active time is the V3 engagement input.
Purchases and leads. Your site (or your own script) calls window.nod('track', 'Purchase', { value: 99, currency: 'EUR', order_id: 'YOUR-ORDER-ID' }) or the equivalent 'Lead' event. Always include order_id on a purchase — it's what makes the event idempotent, so a visitor reloading the thank-you page doesn't get counted twice. Purchase and lead events go through the same path whether you send them as 'Purchase'/'Lead' or lowercase — matching is case-insensitive.
Explicit intent milestones, if you choose to send them. V3 recognizes newsletter_subscribed, account_created, lead_created, demo_requested, quote_requested, add_to_cart, and checkout_started. Unknown custom events stay ordinary telemetry and never become intent evidence automatically.
The same envelope carries bounded scroll depth and interaction counts as diagnostics. There is no session replay, DOM recording, or click map.
Before analytics consent is granted, the pixel is dormant. It creates no visitor or session id, reads no landing parameters for later replay, writes no nod. cookie/localStorage state, and sends no event. Shopify storefronts use the Customer Privacy API. Other storefronts set an initial window.__nodConsent value or call:
window.nod('consent', {
analytics: true,
marketing: false,
sale_of_data: false,
});
Analytics and marketing permission are separate. Analytics consent permits first-party nod. measurement. Marketing and sale-of-data permission control provider sharing and matching fields. Withdrawing analytics consent stops collection and clears the client-side nod. identity state without sending a final attribution beacon.
The pixel keeps a small amount of state on the visitor's device so it can recognize the same visitor across pages and stitch a session together. Everything is first-party — same domain as your site, no third-party storage.
The observable horizon can be configured from 1 to 365 days. Browser identity and retained observed Journey use the same horizon. Raw server events get only a bounded correction buffer beyond it and that buffer never expands the Journey or attribution window.
None of these keys carries raw PII. The visitor id is a random, anonymous identifier, not a name, email, or account id.
About Safari. Safari's Intelligent Tracking Prevention (ITP) caps script-set cookies at 7 days, which would normally mean losing the visitor id on longer gaps between visits. nod. mirrors the visitor id into localStorage as well as the cookie, and reads whichever one is still there — localStorage first, falling back to the cookie, minting a new id only if both are gone. That's why the pixel writes to both: it's the recovery path for Safari's 7-day cookie ceiling, not just redundancy. Be honest with yourself about the tradeoff, though — if a Safari visitor clears site data entirely, or comes back after long enough that both are gone, that visit starts a new anonymous identity.
A session ends after 30 minutes of inactivity or when a new external source-bearing landing arrives. That includes a new click id, nod. campaign tag, acquisition UTM, or external referrer. Internal SPA navigation stays in the same session. A new session gets one source-bearing observed touch; page views, custom events, milestones, and engagement retries inside it do not manufacture extra clicks.
email_hash directly. Lead and declared-form helpers can also hash an email locally before sending. The server never receives the raw address.This is a narrower footprint than a typical third-party ad pixel, by design.
The entire script is wrapped so it can't throw an error onto your page. If a beacon fails to send — blocked, rate-limited, network hiccup — it fails silently and your visitor never sees a difference. The one exception worth knowing: if you've set a domain allowlist and misconfigure it, events will silently stop arriving with no visible error, which is a support case, not a broken page.
The pixel loads with async, so it never blocks page rendering. It's the same script for every workspace; only the pixel id in the tag tells it which workspace to report to.