User Journey Hashed Step Tracking (UJHST) 1.0 — Editor’s Draft (Hybrid Control-Plane Update)

User Journey Hashed Step Tracking (UJHST) defines a privacy-preserving mechanism for measuring a visitor’s in-session navigation path ("user journey") without cookies, local persistent identifiers, or device fingerprinting. UJHST relies on an ephemeral, client-held secret seed to compute a one-way hash chain across sequential events. Each transmitted event contains only the current hash, the previous hash, and a minimal payload. Servers stitch events into journeys by matching prev → curr edges without learning or inferring a stable user identifier.

This draft additionally specifies a Journey Catalog control plane. The catalog defines step keys and allowed transitions (edges). Clients emit human-readable step hints via namespaced x-* payload members; servers validate against the catalog while remaining agnostic to the client’s secret seed.

This is an Editor’s Draft and may change at any time. Feedback is welcome via the issue tracker.

Introduction

Traditional web analytics depend on cookies or fingerprinting to recognize visitors across page loads; these approaches raise privacy and regulatory concerns. UJHST provides a session-scoped alternative that avoids persistent identifiers while enabling ordered in-session path analysis for MPAs and SPAs. The hybrid control-plane model lets design and product stakeholders evolve a journey graph in parallel with implementation while the client independently computes the cryptographic chain.

Conformance

The key words MUST, MUST NOT, SHOULD, and MAY are to be interpreted as described in RFC 2119 and RFC 8174.

Conformance classes:

• Client Implementations MUST follow § Client Processing Model and § Privacy Requirements.
• Server Implementations MUST follow § Server Processing Model and § Privacy Requirements.
• Controllers of the Journey Catalog MUST follow § Journey Catalog.
• Analytics Processors (downstream) MUST follow § Privacy Requirements and § Interoperability.

Terminology

Client

User agent executing site JavaScript.

Server

First-party collection endpoint receiving UJHST events.

Session

Single, ephemeral browsing context (tab/window lifetime).

Seed (S)

Cryptographically random secret generated per session and retained only client-side.

Event

Minimal record describing a step in the journey.

Hash chain

Sequence where each event hash commits to its payload and the previous hash.

Journey Catalog

A versioned server-side registry of step keys and allowed edges (control plane).

Step key

Human-readable identifier for a journey step (e.g., onboarding.enter_email@v3).

Data Model

{
  "v": 1,
  "curr": "<hex-encoded hash>",
  "prev": "<hex-encoded hash or empty string>",
  "payload": {
    "path": "/example",
    "event": "view",
    "ts": 1734373200000,
    "ref": "https://example.org",
    "x-step": "onboarding.enter_email@v3",
    "x-journey": "onboarding",
    "x-catalog": "2025-08-04T12:00Z",
    "x-variant": "A"
  }
}

CANON(payload) || "|" || prev

Client Processing Model

1. On session start, generate a fresh seed S and derive an HMAC key. A session is the lifetime of a tab/window.
2. Step discovery (hybrid control-plane): determine step metadata using one or more of:
   • HTML meta tags (ujhst-step, ujhst-journey, ujhst-catalog, ujhst-variant),
   • server response headers (UJHST-Step, UJHST-Journey, UJHST-Catalog, UJHST-Variant),
   • application configuration (e.g., route table constants).
   Clients MUST NOT fetch the catalog; step keys are opaque tokens for the client.
3. For each step, construct and canonicalize payload, compute curr, transmit the event, and update prev ← curr.
4. Implementations MAY store prev in sessionStorage to bridge navigations; they MUST NOT write cookies, localStorage, IndexedDB, or other persistent state for UJHST.
5. Clients MUST suppress all UJHST transmission when a Do Not Track signal is enabled (see § User Preference Signaling).

Implementation note: Clients SHOULD emit event: "view" on route changes (SPA) and significant page loads (MPA), and event: "action:*" for key user actions.

Transport

{
  "v": 1,
  "events": [ { /* event */ }, { /* event */ } ]
}

User Preference Signaling

• Clients MUST suppress UJHST when navigator.doNotTrack === "1" or the UA signals a comparable setting.
• Clients MUST NOT transmit an explicit "DNT notice" event solely to announce Do Not Track status.
• Servers SHOULD also respect the HTTP DNT: 1 header to disable any server-side analytics logic.

Server Processing Model

Journey Catalog (Control Plane)

The Journey Catalog defines the semantic model of a journey independent of client hashing.

Structure

{
  "version": "2025-08-04T12:00Z",
  "steps": {
    "onboarding.enter_email@v3": {
      "name": "Enter Email",
      "allowNext": ["onboarding.verify_email@v2"]
    },
    "onboarding.verify_email@v2": {
      "name": "Verify Email",
      "allowNext": ["onboarding.welcome@v1"]
    },
    "onboarding.welcome@v1": {
      "name": "Welcome"
    }
  }
}

Requirements

• Controllers MUST maintain a version identifier and SHOULD publish signed snapshots via CI.
• Servers MAY load the catalog from code, config, or a service. Clients MUST NOT fetch or rely on the catalog directly.
• If catalog validation is enforced, clients MUST include x-step and SHOULD include x-catalog.

Interoperability and OpenTelemetry Mapping

Privacy Requirements

1. No persistent identifiers. Clients MUST NOT use cookies, localStorage, IndexedDB, or other persistent state. Session bridging MAY use sessionStorage.
2. Seed confidentiality. The session seed S MUST remain client-confidential. Servers MUST NOT derive, request, or compute event hashes on behalf of the client.
3. Data minimization. ts SHOULD be rounded; ref MUST be origin-only; paths MUST NOT encode PII; values of x-* MUST NOT contain PII.
4. Transparency and control. Deployments MUST disclose UJHST usage and SHOULD honor opt-out mechanisms, including Do Not Track.
5. Retention & purpose limitation. Servers SHOULD define short retention for raw edges and favor aggregates. Data MUST be used solely for anonymous journey analytics and UX improvement.

Security Considerations

• Collision resistance. HMAC-SHA-256 provides strong second-preimage resistance; chain rewrites are infeasible without the seed.
• Integrity and trust. Servers cannot verify client honesty; UJHST is observational. Implement anomaly detection and rate limiting.
• Replay. Treat curr as unique; ignore duplicates.
• Transport. Use HTTPS/WSS; enforce modern TLS; set CSP to reduce script injection risk.
• Control plane separation. The Journey Catalog defines semantics but MUST NOT introduce identifiers that enable cross-session re-identification.