Skip to content
UIAF

Introduction

🏗️ Why Native Identity Management

Section titled “🏗️ Why Native Identity Management”

External tracking scripts are second-class citizens on the web. They load late (after the DOM, after render-blocking resources), they run in a context that ad blockers and privacy extensions can intercept, and they cannot set server-side cookies. A script injected via Google Tag Manager or loaded from a third-party domain faces three structural disadvantages:

  1. Execution priority. External scripts load after the initial HTML response. By the time they run, the user may have already navigated away, submitted a form, or triggered the event you needed to capture. Native code runs as part of the first HTTP response — the server sets the identity cookie before the browser even parses the HTML.

  2. Block risk. Ad blockers maintain filter lists that target known tracking domains and script patterns. A gtag.js loaded from googletagmanager.com is trivially blocked. Code that is part of your application — setting a first-party cookie from your own server — is indistinguishable from your login session cookie.

  3. Cookie control. JavaScript-set cookies are subject to browser restrictions that server-set cookies are not. Safari ITP caps JavaScript cookies to 7 days (24 hours if the referrer is a known tracker). A cookie set via the Set-Cookie HTTP header from your own domain has no such restriction.

Native means the identity system is part of the website application. It runs in the same process, on the same server, with the same privileges as the rest of your code. The first HTTP response sets the cookie. The server-side route handler captures UTM parameters. The identity resolution logic lives in your codebase, not in a tag template.

UIAF is the plumbing, not the faucet. It manages identity (who is this user?), captures attribution (how did they get here?), and sends structured data to an endpoint. It does not decide what to measure, does not define events, and does not render analytics dashboards. The analytics platform (GA4, Adobe, etc.) is the faucet. UIAF makes sure the water gets there.

📋 What This Spec Is and Isn’t

Section titled “📋 What This Spec Is and Isn’t”

This specification IS:

  • An implementation specification with concepts (why), requirements (what), mock code (how it might look), diagrams, edge cases, and FAQ sections
  • Platform-agnostic — the same spec applies whether you build on WordPress/PHP, Next.js, Django, Rails, or a static site with serverless functions
  • A reference for developers, technical stakeholders, and privacy reviewers

This specification IS NOT:

  • A library, SDK, or installable package — there is no npm install uiaf
  • Framework-specific — the mock code uses pseudocode that resembles JavaScript but is explicitly not runnable
  • A consent management platform — it reads consent signals, it does not collect them
  • A tracking system — it does not record pageviews, clicks, or user behavior

The developer’s job is to translate this spec into their platform. The pseudocode illustrates intent. The diagrams show data flow. The test scenarios define expected outcomes. The implementation is yours.

📖 How to Read This Spec

Section titled “📖 How to Read This Spec”

The spec is structured in two phases: full capability, then consent overlay.

Sections 02-06: Full Technical Capability

These sections describe the system operating without consent constraints — maximum persistence, full attribution capture, complete identity resolution. This is the baseline. Read these first to understand everything the system is capable of.

  • 02 — Identity: How user identifiers are generated, persisted, and recovered
  • 03 — Attribution: Which marketing parameters are captured and how attribution models work
  • 04 — Endpoint Schema: The structured payload format sent to the receiving endpoint
  • 05 — Identity Resolution: Cross-device linking, cross-domain transfer, authentication binding
  • 06 — Browser Resilience: How different browsers restrict storage and what the system does about it

Section 07: Consent Overlay

Section 07 takes the full capability from 02-06 and degrades it based on consent state. It defines tiers (from maximum capability to fully dormant) and specifies exactly what gets stored, sent, or suppressed at each tier. This is not a separate system — it is the same system with constraints applied.

Sections 08-09: Security and Integration

  • 08 — Security: Data minimization, PII hashing, cookie security attributes, endpoint authentication
  • 09 — Integration Patterns: CMP integration (Cookiebot, OneTrust, custom), Google Consent Mode mapping, endpoint routing to downstream platforms

Each section follows a consistent structure:

  • Goal statement (one sentence: what this section accomplishes)
  • Concepts (why this matters)
  • Specification (what the system must do)
  • Mock code (pseudocode illustrating key logic)
  • Diagrams (data flow, decision trees)
  • Edge cases (what happens when things go wrong)
  • FAQ (common questions and direct answers)

⚙️ Core Architecture

Section titled “⚙️ Core Architecture”

The division of responsibility is clear:

  • The website does identity resolution, attribution capture, and payload delivery. This is what UIAF specifies.
  • The endpoint (typically server-side GTM) receives the structured payload, validates it, enriches it if needed, and forwards it to downstream platforms. The endpoint’s behavior is outside this spec, but the payload format (section 04) is designed to give it everything it needs.

The website sends data. The endpoint routes data. The platforms consume data.

🚫 What UIAF Does NOT Do

Section titled “🚫 What UIAF Does NOT Do”