Getting Started

How Tracking & Identity Works

The mental model behind Logspot — anonymous IDs, user IDs, sessions, groups, and consent gating, and exactly what data leaves the browser.

This page explains how Logspot turns raw browser activity into people, sessions, and accounts — and exactly what data leaves the visitor's browser. It doubles as a transparency reference: there are no hidden identifiers and no fingerprinting.

The Core Identifiers

Every event Logspot records is tied to two IDs:

IDSet byLifetimePurpose
Anonymous IDThe SDK, automaticallyFirst-party cookie, ~12 months by default (configurable)Links a visitor's events together before they tell you who they are
User IDYou, via identify()Stable for the life of the accountLinks events to a known person across devices and sessions

When the script loads, the SDK calls ensureAnonymousId() — it reads the lgspt_anonymous_id first-party cookie, or generates a new random ID if there isn't one. No IP-based fingerprinting. No third-party cookies. You can read the current value with Logspot.getAnonymousId().

The ~12-month default lifetime is chosen to respect most privacy laws and regulations — well under the limits typical analytics tools push with 2-year cookies. You can shorten it with the SDK's cookieExpirationInSeconds option if you operate in regions that restrict the consent window further (some require as little as 6 months).

Anonymous → Identified

A visitor starts anonymous. Their pageviews and events all carry the anonymous ID. When they do something that tells you who they are — sign up, log in — you call:

Logspot.identify('user_123', { plan: 'pro' });

From that point the SDK attaches the user ID to every event. On the server, Logspot merges the anonymous history into the identified person, so the pre-signup activity isn't lost — the visitor who browsed your pricing page last week and the user who just upgraded are the same person.

identify() sends the anonymous ID alongside the new user ID (POST /identify), plus any traits you pass (e.g. plan, name). Traits describe the person; events describe what they did. See Events vs Properties for where each piece of data belongs.

On logout, call Logspot.reset() — it clears the user ID and super properties and rotates the anonymous ID so the next visitor on a shared device starts clean.

Secure Mode

If you don't want anyone to be able to claim an identity by guessing a user ID, you can verify identities server-side. Pass a short-lived token your backend signs:

Logspot.identify(
  'user_123',
  { plan: 'pro' },
  {
    identityVerification: { token: serverSignedToken },
  },
);

Unverified writes follow a "restrict, never expand" rule on the backend: consent denials and privacy signals always apply, but consent grants for a user ID require a valid token.

Sessions

You don't create or manage sessions in the SDK. Logspot derives them server-side from the stream of events — grouping a visitor's activity into sessions based on timing and inactivity. This keeps the client lightweight and means session logic can improve without an SDK upgrade.

Groups

People belong to accounts, teams, or workspaces. Logspot links a user to a group (a company, team, or workspace) through the Group API or a group_id on a raw track event, so you can roll product usage up from individual users to the company they belong to. That is essential for B2B analytics, where the buying unit is the account, not the seat.

Logspot is consent-aware end to end. Every event carries a consent snapshot, stamped by the SDK after your eventMapper runs so it can't be clobbered:

  • privacy_categories — the analytics / functional / marketing categories the visitor has (or hasn't) granted.
  • privacy_signals — browser signals like Global Privacy Control (GPC) and Do-Not-Sell.
  • consent_source — what set the current state (your setConsent call, a CMP, etc.).

You report consent state with setConsent() and read it back with getConsent():

Logspot.setConsent({ analytics: true, marketing: false });

How strictly events are held depends on your org's consent behavior:

  • notRequired (default) — events send immediately; the snapshot is recorded for the record.
  • express — events are queued in memory until the first consent snapshot exists, then flushed (or dropped if analytics was denied).

Browser Do-Not-Track is also respected: if a visitor sends a DNT header and you've enabled enableBrowserDNT, the SDK disables itself entirely. See Do Not Track.

What Actually Leaves the Browser

Each event is a single POST https://api.logspot.io/i with the public key in the x-logspot-pk header. The payload is the event name, the anonymous/user IDs, the page URL and referrer (campaign params stripped from the stored URL), screen size, language, hostname, your metadata, and the consent stamps above. There is no canvas fingerprinting, no battery/font enumeration, and field values are never read by autocapture — form and input capture record metadata only, and sensitive fields (passwords, OTP, credit-card autofill) are skipped.

Next Steps