Frequently Asked Questions

Quick answers organized by category. Each answer assumes familiarity with the UIAF spec (sections 02-08). Cross-references point to the relevant spec section for deeper context.

🔑 Identity

What happens if ALL cookies are disabled?

Fall back to sessionStorage for session-only identity. If sessionStorage is also blocked (some enterprise policies, certain private browsing configurations), no identity is possible. The system should detect this and skip identity resolution entirely rather than erroring. See 02-identity-management.md, Persistence Hierarchy.

What about private/incognito mode?

All storage is ephemeral. Cookies, localStorage, and sessionStorage are cleared when the window closes. Session-only identity is the maximum capability — every window close produces a new user. There is no workaround; this is by browser design. See 05-browser-landscape.md, Private/Incognito Mode.

Can I use the same UID across subdomains?

Yes, if you set the cookie Domain attribute to .example.com. This makes the cookie available on shop.example.com, blog.example.com, etc. However, localStorage is NOT shared across subdomains — each subdomain has its own localStorage instance. The server-set cookie is the primary cross-subdomain identity mechanism. See 02-identity-management.md, Subdomain Navigation.

What if localStorage is full?

Gracefully degrade. The UID lives in the cookie — localStorage is a backup recovery mechanism. Catch the QuotaExceededError, log it for monitoring, and continue. The system is designed to function with any subset of storage mechanisms available. See 02-identity-management.md, Storage Synchronization.

Should I use HttpOnly cookies?

No. UIAF needs JavaScript access to the cookie for localStorage sync, SPA navigation, and client-side recovery. HttpOnly prevents all of these. The UID is a random identifier with no inherent access-granting value, which limits the impact of XSS exposure. If your architecture sets the UID server-side on every request and you do not need client-side recovery, HttpOnly is the more secure choice — but you lose the multi-mechanism recovery that is UIAF’s primary resilience feature. See 02-identity-management.md, Why HttpOnly is False.

How long does the UID last?

Up to 400 days with server-set cookies (the browser-enforced maximum per RFC 6265bis). The expiry is refreshed on every visit, so a user who returns within 400 days maintains their identity indefinitely. Without server-set cookies: 7 days on Safari and Brave (JavaScript cookie cap). Safari further reduces this to 24 hours if the referrer is a classified tracker and the URL contains known click identifiers. See 05-browser-landscape.md, Storage Persistence Matrix.

📍 Attribution

What if a user arrives from two campaigns in one session?

last_touch updates to the most recent campaign. first_touch is never overwritten — it is write-once, set on the first attribution-carrying visit ever. The count field increments with each attribution-carrying visit. See 03-attribution-capture.md, Attribution Model.

What if the gclid has expired?

Still capture it. Include the capture timestamp so downstream systems can compute whether the click ID is within its validity window (90 days for gclid). UIAF does not enforce expiration at capture time — let the receiving endpoint or ad platform decide. See 03-attribution-capture.md, Click ID Handling rule 4.

How do I handle direct visits?

No attribution parameters, no meaningful referrer = direct visit. Do not update attribution data. last_touch stays as the previous campaign. This prevents direct visits from overwriting valid campaign attribution. See 03-attribution-capture.md, When Attribution Updates.

Should I capture ALL URL parameters?

No. Only capture allowlisted parameters: standard UTMs, known click IDs (gclid, fbclid, msclkid, etc.), and your configured custom parameters. Unknown query parameters may contain PII, session tokens, or search queries with no attribution value. The allowlist bounds the data and prevents accidental PII capture. See 03-attribution-capture.md, Custom Parameters.

What about AI-generated traffic (ChatGPT, Perplexity)?

Classify by referrer domain. chatgpt.com, perplexity.ai, claude.ai, gemini.google.com, and copilot.microsoft.com map to a new ai medium category. This classification happens in the referrer classification hierarchy when UTM parameters are absent. See 03-attribution-capture.md, Referrer Classification.

Can I track before consent in the EU?

Not with device storage (cookies, localStorage, sessionStorage). ePrivacy Art 5(3) prohibits storing or accessing information on the user’s terminal equipment without consent. However, you CAN read HTTP headers server-side (Referer header, UTM parameters from the URL) without triggering Art 5(3) — reading a server’s own HTTP request is not device storage. This is what Tier 3 enables: server-side UTM and referrer capture without writing anything to the browser. See 07-consent-integration.md, Tier 3.

What about legitimate interest for analytics?

Cannot override the ePrivacy consent requirement for cookies. ePrivacy is lex specialis — it takes precedence over GDPR’s legitimate interest basis for the specific act of device storage. Every EU DPA that has ruled on this confirms: cookies and localStorage for analytics require consent. The only exemption is “strictly necessary” storage for a service explicitly requested by the user. See 07-consent-integration.md, FAQ.

What is GPC and do I need to honor it?

Global Privacy Control (navigator.globalPrivacyControl) is a browser-level signal indicating the user opts out of the sale or sharing of personal data. It is legally binding in California (CCPA/CPRA), Colorado, Connecticut, Texas, and Oregon. In these jurisdictions, you must treat GPC as an opt-out — minimum Tier 2 (no ad data) or Tier 4 (fully dormant) depending on interpretation. Check GPC before CMP state, as GPC can override a consent dialog. See 07-consent-integration.md, GPC section.

What's the difference between Google Consent Mode Advanced and Basic?

Advanced mode sends cookieless pings to Google when consent is denied. These pings contain timestamp, page URL, referrer, consent state, and user agent — but no cookies, no client_id, no user identifiers. Google uses them to model conversions for unconsented traffic. Basic mode sends nothing when denied. Recommend Advanced: the pings are non-identifying and recover analytical value from the 50-70% of traffic that denies consent. Requires minimum thresholds (~1,000 events/day for GA4) before modeling activates. See 07-consent-integration.md, Advanced vs. Basic Mode.

If a user revokes consent mid-session, what do I do?

Immediately delete all UIAF cookies (server and client), localStorage keys (uiaf_uid, uiaf_attribution), and sessionStorage keys (uiaf_uid, uiaf_session_id, uiaf_attribution). Send a final consent_update event with the new consent tier and then stop all UIAF processing. If the downgrade is partial (T1 to T2), remove only click IDs from storage and continue with reduced capability. See 07-consent-integration.md, Consent Change Handling.

🌐 Browser

Safari keeps losing my users after 7 days?

Your cookies are being set via JavaScript (document.cookie). Safari ITP caps all JavaScript-set first-party cookies at 7 days. Switch to server-set cookies (Set-Cookie HTTP response header from a same-IP first-party server) to get the full 400-day lifetime. This requires native platform integration — a middleware, route handler, or edge function that sets the cookie on the initial HTTP response. This is the primary reason UIAF recommends native integration over tag-based approaches. See 05-browser-landscape.md, Safari ITP.

Brave blocks everything?

Not everything. Brave caps JS cookies at 7 days and HTTP server-set cookies at 180 days. Third-party cookies are blocked. But first-party server-set cookies still work with a 180-day lifetime, and localStorage is persistent (no time-based purge like Safari). No browser completely blocks first-party server-set cookies. See 05-browser-landscape.md, Brave Shields.

Do ad blockers block UIAF?

Not if UIAF is native to your application. Ad blockers (uBlock Origin, AdBlock Plus, Privacy Badger) target known third-party tracking domains and scripts via filter lists (EasyList, EasyPrivacy). Your own application code running on your own domain, sending data to your own first-party endpoint, is indistinguishable from any other API call and is not on any filter list. External scripts like gtag.js and fbevents.js ARE on filter lists. See 05-browser-landscape.md, Why Native Integration Avoids Extension Blocking.

What about Chrome Privacy Sandbox?

Retired October 2025. Topics API, Protected Audience (PAAPI), and Attribution Reporting API were all retired. Third-party cookies remain fully functional in Chrome with no opt-in prompt. Chrome is currently the most permissive major browser for tracking and storage — no built-in ad blocker, no fingerprinting protection, no first-party storage restrictions beyond the 400-day cookie cap. See 05-browser-landscape.md, Chrome.

🔧 Integration

Can I use GTM instead of native integration?

GTM can handle client-side logic (reading UTMs, setting cookies via JavaScript, sending endpoint payloads). But you lose server-side cookie setting, which is the primary ITP resilience mechanism. A JavaScript cookie set via GTM is subject to Safari’s 7-day cap. For maximum persistence, native integration (server middleware or edge function setting Set-Cookie headers) is recommended. GTM can supplement native integration for event triggering and payload delivery. See 02-identity-management.md, Persistence Hierarchy.

What about Shopify?

Shopify’s Liquid templates allow limited server-side logic. You can set cookies in the HTTP response via Shopify’s app proxy or custom app endpoints. For full control over the Set-Cookie header on the initial page response, use a Shopify Functions or a custom app that intercepts the request lifecycle. The constraint is that Shopify’s hosted storefront limits direct access to response headers from theme code.

Is there a WordPress plugin?

Not from UIAF — this is a specification, not a product. A developer would build a plugin following this spec. The natural integration point is WordPress’s init action hook, where a PHP function reads the request URL and headers, sets the Set-Cookie header, and captures attribution server-side before any output is sent. The client-side JavaScript handles localStorage sync, session management, and endpoint delivery.

🔒 Data

Is a random UUID personal data?

Yes, under GDPR. The Breyer ruling (CJEU C-582/14) established that identifiers designed to re-identify users meet the “reasonable means” test for personal data (Article 4(1)). A UIAF UID is explicitly designed to persist across sessions and re-identify the same browser — it meets this threshold. Recital 30 further confirms that “online identifiers” are personal data when used for profiling or identification purposes.

Do I need a DPIA?

Likely yes for EU implementations. UIAF involves systematic monitoring of individuals (identity tracking across sessions), processing of personal data at scale (UIDs, click IDs, hashed PII via identity linking), and the combination of datasets (attribution + identity). These factors trigger DPIA requirements under GDPR Article 35(3). Consult your DPO for a formal assessment.

Are UTM parameters personal data?

No. UTM parameters describe campaigns (utm_source=google, utm_medium=cpc, utm_campaign=spring_sale), not users. They contain no user-specific information. No DPA has classified UTM values as personal data under GDPR. They are safe to capture and store at all consent tiers where analytics processing is permitted, including server-side capture at Tier 3. See 03-attribution-capture.md, Standard UTM Parameters.