Privacy and visitor identity

Anonymous sessions are the default. Persistent identity needs explicit consent.

No persistent visitor ID by default

The tracker uses a new session identity for a fresh page session. It stores no persistent visitor ID in aggregate mode. Identity-based returning visitors require consent-gated attribution.

Cookieless does not automatically mean anonymous or exempt from consent. Joining a visit to a Stripe payment can identify a customer. Establish your lawful basis, explain the link and collect valid consent before enabling attribution. A consent flag is your integration’s assertion, not proof of consent.

Do Not Track and Global Privacy Control are respected by default. URL query parameters and hash fragments are excluded by default; common sensitive values remain redacted when those fields are enabled.

Known bot filtering

The public browser collector excludes recognized crawler, monitoring, preview and headless user agents before storing activity or counting it against your event allowance. This signature-based filter applies to every plan. It cannot detect every bot: missing, unknown or spoofed browser user agents can still be collected, and false positives are possible.

This does not rewrite historical reports, verify a crawler’s identity or block it from your website. Authenticated server events and signed payment updates follow their own validation. Verified AI crawler observations remain separate from human analytics. No IP fingerprint or retained raw user agent is added by this filter.

Provided names and profile images

After your visitor grants attribution consent, you may deliberately provide their display name and approved HTTPS profile image. These appear in Users and on the chart at their actual session start. Anonymous visitors receive no inferred names or photographs.

// Reapply the visitor’s current consent decision first.
window.zijra?.("consent", { granted: true });
window.zijra?.("identify", {
  userId: "YOUR_STABLE_APPLICATION_USER_ID",
  name: "Provided display name"
});
// Optional avatarUrl must use an approved profile-image host.

Use a stable application user ID or consented visitor UUID, never an email address. Reapply consent on each visit. GitHub and Google profile-image hosts are supported by default; additional trusted hosts require server configuration. Dashboard images use an authenticated proxy. Public reports and aggregate permissions exclude profiles; an explicit private visitor permission is required in the v2 API and MCP.

Logout and account switching

After a successful application logout, call reset once to clear the current profile and start fresh visitor and session IDs. Reset preserves the current consent decision and previously collected history. Before identifying a different account, reset first so its name, image and properties cannot inherit the previous account’s profile. Sign-in itself does not grant analytics consent.

// Run after logout succeeds, or before switching accounts.
window.zijra?.("reset");

// A withdrawn consent decision uses the separate erasure flow.
window.zijra?.("consent", { granted: false });

These are separate lifecycle actions: connect reset to logout and consent withdrawal to your consent controls. Reset also clears identity on an excluded page without collecting that page. Do not reset on every render or page navigation.

Withdrawal stops identified tracking and clears local identity immediately. Erasure retries transient failures up to four times within the current page, using the captured old identity only in memory, with a final attempt after pending sends settle. It does not retain that identity for another visit. A true command return confirms the local consent change; closing the page or a sustained outage can prevent server erasure delivery.

Once server erasure is accepted, old visitor identifiers remain blocked by a site-scoped hashed suppression marker until the website is deleted. The marker is pseudonymous data. A new consent decision starts a fresh identity; it must not restore the withdrawn history. Financial references and earlier daily totals can remain. Remove or update old visitor metadata in your own backend and Stripe integration too.

Forward the current consent context

Backend identification must use the current session and consent epoch from the browser. Forward these only after valid consent and through your authenticated application flow. Do not reuse a withdrawn epoch or invent one on the server. Epochs generated automatically by the tracker are local to that website origin; cross-origin applications must explicitly coordinate the current consent context.

// After consent and the tracker’s first accepted batch:
const sessionId = window.zijra?.getSessionId?.();
const consentEpoch = window.zijra?.getConsentEpoch?.();
const context = {
  sessionId,
  consent: true,
  ...(consentEpoch ? { consentEpoch } : {}),
};
// Send context to your authenticated backend. The backend supplies
// the stable application userId to the identify endpoint.
// For Stripe metadata, use the current resolved visitor UUID instead:
const visitorId = window.zijra?.getVisitorId?.();

Omit the optional epoch for a legacy session when the getter returns null; do not send null as the field value. An omitted epoch preserves the same already-identified user’s current visitor ID. New consent-scoped sessions and changes to an existing application user require the current epoch; otherwise the API returns CONSENT_EPOCH_REQUIRED. Use the visitor ID returned by successful identification rather than calculating your own.

Your collection boundaries

Website settings save the domain, excluded paths, localhost permission and collection status. Pause collection at any time. Reinstall the updated snippet after changing client privacy preferences.

Collection does not infer a visitor’s religion. Unknown location stays unknown.