Consent & State Model

1. Philosophy: Consent-Agnostic Enforcement

The Qaxal sGTM Platform acts as a neutral infrastructure layer.

• It does NOT: Automatically block requests based on IAB TCF strings or detailed consent purposes.
• It DOES: Rely on the client (browser) to only send requests when appropriate consent has been captured by the client's CMP (Consent Management Platform).

If a request reaches the platform, it is processed. The platform assumes the client has authorization to act.

2. State Storage

State is minimized and isolated to fundamental tracking needs.

State Type	Storage Location	Lifetime	Purpose
Session Identity (_sid)	First-Party Cookie	Session (30m)	Correlate events within a visit.
User Identity (FPID)	First-Party Cookie	395 Days (Max)	Stable user identification (Cookie Keeper).
Restoration State	Cloudflare KV (Implicit)	Config TTL	Backup of cookie values (if Restoration enabled).
Fingerprint	Supabase loader_sessions	Session	Detection of bot/prevention status.

3. Cookie Keeper Module

The Cookie Keeper is the primary state persistence mechanism, designed to mitigate Safari ITP (Intelligent Tracking Prevention) and Firefox ETP limits.

3.1 The Problem

Browsers limit client-side (JavaScript-set) cookies to 7 days or even 24 hours. This breaks attribution for sales cycles longer than a week.

3.2 The Solution

The Router Worker acts as a server-side proxy.

1. Intercept: Inspects upstream responses (from sGTM).
2. Detect: identifies known analytics cookies (_ga, _fbp, FPID).
3. Extend: Rewrites the Set-Cookie header with a Server-Side scope.
   • Max-Age: Set to 31,536,000 seconds (1 year / 395 days).
   • HttpOnly: Optional (configurable).
   • Secure: Always true.
   • SameSite: Lax.

3.3 Authorization

Cookie extension is gated by the cookie_restoration entitlement in the runtime config. If this module is disabled (or the plan does not support it), cookies remain untouched with their original browser-imposed lifetimes.

4. Bootstrapping State (/boot)

When the Loader Script initializes:

1. It sends a POST /boot request.
2. The Worker checks for an existing FPID cookie.
3. If cookie_restoration is active:
   • The Loader initiates a Restoration Sequence (calling /r via proxy).
   • Sever-side storage (KV) is checked for backup values.
   • Cookies are restored before the GTM container is injected.
4. The Client Script writes these values back to the document, effectively "resurrecting" the user identity.