Tracked
Articles

Attribution identity

First-party visitor identity and cookie-loss recovery

First-party identity can reconnect eligible same-device events without turning an anonymous campaign visitor into a known person.

First-party visitor identity gives campaign events a stable anonymous visitor reference on the same device. It helps connect impressions, clicks, and conversions when a session changes or a first-party token needs privacy-preserving recovery.

Tracked supports same-device visitor identity and cookie-loss recovery. Anonymous recovery can reuse a workspace-scoped visitor profile when browser evidence meets the matching rules; it does not identify a person or connect devices.

Visitor, session, and person are different concepts

A tracking system often needs more than one identifier.

  • A session ID can represent one tab or visit window.
  • A visitor ID can connect eligible sessions for the same anonymous browser profile.
  • A person or customer ID can represent a known individual supplied by an authorized business system.

These identifiers answer different questions. Reusing a visitor ID across two tabs does not prove who the person is. Matching a returning browser does not prove that another device belongs to the same person.

Tracked keeps the current profile anonymous and workspace-scoped. That lets reports connect campaign activity without presenting an anonymous browser as a named customer.

Why first-party identity matters for campaigns

Affiliate and performance journeys rarely happen in one request.

A visitor may:

  1. arrive from an ad;
  2. view a hosted landing page;
  3. open an offer in another tab;
  4. return later;
  5. trigger a server-side conversion.

If every step is grouped only by a short-lived request or tab, the report becomes fragmented. A durable visitor reference can help the system connect eligible events while preserving the separate session history.

That produces a more useful journey without pretending that every gap can be filled.

How same-device recovery works conceptually

The browser first tries to reuse its first-party visitor token. If the expected token is unavailable, a server-side identity service can evaluate approved, bounded signals and return an existing anonymous profile only when the evidence satisfies the matching contract.

The important design constraints are:

  • workspace isolation;
  • versioned matching rules;
  • explicit confidence;
  • bounded retention;
  • no raw signal values crossing the durable identity boundary;
  • no claim that cookies travel across unrelated domains;
  • no automatic promotion from anonymous visitor to known person.

Recovery is not a license to join every event that looks similar. Ambiguous evidence should remain unmatched.

What Tracked stores

Tracked’s identity contract separates the durable visitor from the per-tab session.

The visitor profile includes a workspace-scoped anonymous ID, creation and last-seen timestamps, and a retention boundary. A session has its own ID and points to the visitor when the relationship is known.

Events can carry:

  • workspace ID;
  • visitor ID;
  • session ID;
  • click ID;
  • campaign ID;
  • identity match method;
  • identity confidence.

Reports can then count or group by the stable visitor reference when it exists and fall back conservatively when it does not.

What privacy-preserving means here

Privacy-preserving identity is a set of limits, not a slogan.

For the current Tracked workflow, it means:

  • the profile is anonymous;
  • matching is scoped to one workspace;
  • raw fingerprint components are not stored as the durable match record;
  • keyed digests cross the matching boundary instead;
  • retention is explicit;
  • consent remains part of the event contract;
  • traffic-quality reports do not expose raw person-level data.

These limits reduce misuse and make the attribution claim easier to explain accurately.

What this does not prove

Anonymous recovery does not prove cross-device identity

An exact browser-signal match can recover a workspace-scoped anonymous profile when the stored visitor token is missing. It does not prove that two devices belong to one person or create a cross-device join.

Cross-device attribution needs a separate, authorized identity source and policy. Treat it as a distinct product direction, not as a result of anonymous visitor recovery.

It does not make tracking cookieless

First-party cookies and browser storage remain useful parts of the current workflow. Recovery can handle some loss; it does not make storage restrictions disappear.

It does not identify a customer

An anonymous visitor ID is not an email address, account ID, or verified person. Known identity requires a separate, authorized source and policy.

It does not merge every ambiguous journey

When more than one visitor could match, the safe result is no automatic merge. Attribution should expose uncertainty rather than manufacture continuity.

How to evaluate an identity report

Ask these questions before acting on a journey:

  1. Is the event joined by a first-party visitor token or a recovery method?
  2. What confidence applies to the match?
  3. Is the identity anonymous or known?
  4. Did the conversion carry the original click reference directly?
  5. Are any events present only through a fallback session grouping?
  6. Does the report distinguish unmatched events?

The best attribution view makes those answers available instead of hiding them behind one “unique user” number.

Where Tracked is today

Status: Same-device visitor identity and anonymous recovery are shipped. Cross-device attribution remains an in-development product direction.

Tracked connects the anonymous visitor, tab sessions, campaign click, landing-page route, offer click, and conversion inside the campaign journey. The same workspace also contains the hosted page and route configuration, so a buyer can move from the attribution record back to the experience that produced it.

Check the match method and confidence before interpreting a recovered visitor reference, and verify the click ID separately when attributing an ad click.

The practical rule

Use first-party visitor identity to connect eligible same-device campaign events. Keep sessions distinct, preserve uncertainty, and do not label anonymous recovery as cross-device attribution.

Frequently asked questions

Is a first-party visitor ID the same as a customer ID?

No. It is an anonymous workspace-scoped reference used to organize eligible campaign events. It does not become an email address, account record, or verified person unless a separate authorized identity system provides that relationship.

Does visitor recovery make tracking cookieless?

No. First-party browser storage remains part of the current workflow. Recovery can reconnect some eligible same-device events after token loss, but it does not make browser restrictions or consent requirements disappear.

Does same-device recovery count as cross-device attribution?

No. Same-device recovery and cross-device attribution have different evidence requirements. Anonymous browser recovery does not connect two devices or identify a person; Tracked's separate cross-device work remains in development.

Start free and inspect campaign journeys.