Visitor identity

What each label means

Same browser means events share a random, site-specific browser identifier. It does not prove a person: devices may be shared, cookies can be cleared, and browsers can restrict storage. Visits still restart after 30 minutes of inactivity. Analytics unique visitors remain browser counts; identity links enrich CRM history without rewriting those totals.

Verified customer means your authenticated backend supplied the same stable customer ID. Manually linked means your team reviewed and connected the records. Matching submitted email or phone details are suggestions only. Zowar never matches people by IP address, device fingerprint, or similar names.

Open a lead or contact → Details → Visitor identity to review suggestions or enter another record’s number. Review both records and provide the evidence before linking. You can remove incorrect links; the audit history remains and the enquiries stay separate.

Receive leads without visitor accounts

A normal form submission is enough. Zowar receives the enquiry and attaches available browser history without asking the visitor to create an account or enter a verification code. Keep your website’s existing form experience.

Returning to the same website with the same browser identifier connects recorded visits. Another browser or device normally has a separate identifier. Matching submitted emails or phone numbers can help your team review related enquiries; they do not automatically prove that both browsers belong to one person.

Phone, WhatsApp, and email-link clicks record an attempt to contact the business. The destination is the business’s contact detail, not the visitor’s identity.

Connect an authenticated customer

This is optional. Websites without customer accounts can use browser history and manual review. For a signed-in customer, await window.PulseReady, then obtain the browser identifier from Pulse.identify().session_id. Send it to your own authenticated backend. That backend must derive the customer ID from the signed-in session, never from a caller-supplied customer ID.

Your backend calls the endpoint below using a tenant write API key and a fixed server-side site ID. Keep the API key on the server. Use a unique, stable database ID, not an email address, a shared placeholder, or a boolean.

POST https://YOUR_ZOWAR_HOST/api/identity/proof?site_id=YOUR_SITE_ID
Authorization: Bearer YOUR_SERVER_API_KEY
Content-Type: application/json

{"customer_id":"your-authenticated-customer-id","session_id":"browser-id-from-Pulse"}

Return only the token to that customer’s browser, then call Pulse.identifyCustomer(token). The proof expires after five minutes and is restricted to this site and browser. Matching proofs link browser histories; they do not combine lead records. Check for a rejected promise.

// After your backend authenticates the current customer:
await window.Pulse.identifyCustomer(token);

// On logout or BEFORE switching to another customer:
window.Pulse.reset();
// Request a fresh proof with the new Pulse.identify().session_id.

Reset on every logout and account switch, including other tabs. A link connects that browser’s stored history, so shared devices require careful session handling. Conflicting customer IDs are rejected. Removed links cannot be restored by replaying a proof; reset the browser before obtaining a new proof.

Reliable form delivery

The tracker assigns event IDs, batches interactions, and retries network errors, HTTP 429, and server errors with a bounded delay. The collector deduplicates retries. Pending anonymous events may stay in tab session storage for up to six hours, capped at 100 requests; form values and identity proofs stay in memory. Delivery is best effort and blockers can still prevent it.

Generate one submission_id for each logical form submission and retain it when retrying the same answers. Use a new ID if the answers change. The tracker retries automatically with the same ID. If your backend already accepts the form, send the same payload and submission_id from there for confirmation:

// Browser: keep submissionId until this attempt finishes.
const submissionId = crypto.randomUUID();
await window.Pulse.submitLead({
  submission_id: submissionId,
  name, email, phone, message, form: "contact"
});

// Your server, AFTER your existing form handler succeeds:
// POST /api/leads/confirmed?site_id=YOUR_SITE_ID
// Authorization: Bearer YOUR_SERVER_API_KEY
// JSON: same submitted fields + submission_id + site_key
// Include the browser context if available; do not invent it.

The public submission and server confirmation return the same lead ID. Reusing an ID for different answers returns 409. Keep the website’s normal form delivery working even when Zowar is unavailable; use your backend queue for longer-lived retries. Server confirmation verifies acceptance by your integration, not ownership of the submitted contact details.

Consent and storage

<script defer src="https://YOUR_ZOWAR_HOST/t.js"
  data-site="YOUR_SITE_KEY" data-consent="required"></script>

// Once Pulse is loaded, connect these to your consent manager:
window.Pulse.setConsent(true);  // starts tracking
window.Pulse.setConsent(false); // stops tracking and clears tracker state
window.Pulse.diagnostics();    // storage mode, pending requests, delivery counts

When consent is required, no events or form drafts are sent before consent. Revocation stops future collection; it does not erase previously accepted server records. A site-specific opt-out preference is kept. Persistent IDs use browser cryptographic randomness and first-party cookies; blocked cookies use a document-lifetime ID. Cleared identifiers are not restored from another storage location. Existing legacy IDs migrate once.

The browser cookie defaults to 30 days and renews when an existing identifier is used on a page load. Set data-identity-days to a whole number from 1 to 365 to choose another retention interval; invalid values use 30. On supported secure origins, a short Web Lock serializes initialization across tabs. Await window.PulseReady before reading an identifier immediately after loading the script; queued action methods wait automatically. Browsers without Web Locks use ordinary initialization and may still race during simultaneous first loads. Browser restrictions may shorten retention. No visit means no renewal. Clearing cookies, private browsing, another browser, or another device can create a newly observed visitor.

Optional same-origin collection

If your website already has a server proxy, set data-collector-path="/zowar" on the tracker. Requests then use /zowar/api/collect and the corresponding public endpoints on your website. Forward only /api/collect, /api/collect/batch, /api/leads, /api/form-drafts, /api/identity/link to the matching Zowar API paths. Preserve the body, content type, and website Origin; strip website cookies and authorization headers. Never expose authenticated Zowar API routes through a public proxy.

This is a delivery option, not an HttpOnly-cookie integration or a way to identify devices. It keeps the same browser cookie and consent rules. The tracker script still needs permission to load. Proxied events deliberately omit location and edge bot scores because those signals would describe your proxy server instead of the visitor. Standard direct collection keeps the existing trusted-edge behavior.

Traffic quality is separate

Known crawler user agents are excluded and counted by reason under Analytics → Audience → Collection quality. Other traffic is Unknown unless a trusted edge supplies evidence. This does not guarantee all bots are detected. Requests blocked before reaching Zowar cannot be counted.

Self-hosted operators can enable TRUST_BOT_HEADERS only behind an edge that strips and overwrites x-zowar-bot-score and x-zowar-verified-bot and prevents direct origin access. Scores 1–29 are excluded, 30–99 are labelled Likely human. Cloudflare bot scores require a suitable plan; Zowar does not fabricate them. This setting is off by default. Country collection is configured separately.

Verify your integration

On a separate test site, check two tabs, returning visits, cookie deletion, blocked storage, consent refusal and revocation, failed requests, duplicate submissions, SPA navigation, logout, and account switching. Use two browsers signed into the same test customer to verify separate visits appear in one CRM history. Try an expired proof and a different customer; both must fail. Remove a link and confirm those browser histories separate again.