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:
| ID | Set by | Lifetime | Purpose |
|---|---|---|---|
| Anonymous ID | The SDK, automatically | First-party cookie, ~12 months by default (configurable) | Links a visitor's events together before they tell you who they are |
| User ID | You, via identify() | Stable for the life of the account | Links 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.
Consent Gating
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 (yoursetConsentcall, 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
- Events vs Properties — model your data correctly
- Build a Tracking Plan — decide what to track
- JS SDK reference — the full API
- Do Not Track and Cross-domain tracking