Frequently Asked Questions

Edition 3.1.1

Quick answers organized by category. Each answer links to the specification section that owns the full contract.

Evidence and legal status. Volatile browser and legal claims below carry their verification date and follow the bound evidence ledgers; claims without dated support are omitted rather than approximated. Decisions only the data controller can make are marked [CONTROLLER]; points needing counsel review in the deployment jurisdiction are marked [COUNSEL]. Nothing here is a compliance determination.

Identity

What happens if ALL cookies are disabled?

Without a readable cookie, the system cannot tell who the visitor is. The only way back to a previous identity is recovery: the browser may hold a paired recovery credential (uiaf_recovery) in localStorage or sessionStorage. The credential is opaque, meaning the value itself reveals nothing and only the server can verify it, and the server checks it before re-issuing anything. Recovery runs only when two more conditions hold: the base persistence predicate (consent resolved, analytics allowed, documented purpose) and the deployment’s explicit continuity recovery policy. Script storage never becomes the authority, and the browser never mints or accepts a persistent UID. Otherwise, permitted events proceed with uid: null, or the deployment may run an explicitly nonpersistent ephemeral mode, which cannot claim persistent-identity-profile conformance. Identity Management carries the full path.

What about private/incognito mode?

Private-mode storage is session-scoped and wiped when the private session ends; normal-profile storage is inaccessible. In Chromium browsers, incognito localStorage is one store shared across the incognito session’s tabs, cleared when the last private window closes; Safari Private Browsing isolates tabs from each other. Only Chrome Incognito is documented to block third-party cookies by default; other private modes follow the browser’s global settings (verified 2026-07-19). Browser Landscape has the dated per-browser table.

Can I use the same UID across subdomains?

Yes. If your server scopes the cookie to your main domain (the Domain attribute, for example .example.com), the browser sends it on shop.example.com, blog.example.com, and every other subdomain, so the same UID follows the visitor. Browser storage like localStorage does not share anything across subdomains: each subdomain has its own isolated store, and it only assists the separately authorized recovery path there (see Identity Management).

What if localStorage is full?

The system keeps working without it. The UID’s authority is the server-set cookie. Script storage holds only the mirror and the paired recovery credential, and the pair is written atomically: on any storage failure (for example QuotaExceededError) both writes roll back, the failure is logged for monitoring, and operation continues without script-storage recovery. The system is designed to function with any subset of storage mechanisms available, per Identity Management.

Should I use HttpOnly cookies?

No. UIAF needs JavaScript in the browser to read the uiaf_uid cookie: for identity resolution, for keeping the storage mirror in sync, and for single-page-app navigation. An HttpOnly cookie is invisible to JavaScript, so those reads would fail. This is a deliberate trade-off, not a claim that script readability is safe. The UID is a random identifier that grants no account access, so it is less sensitive than a login token. XSS can still steal it, and the security model rests on server-only minting, the endpoint route contracts, and purge rules rather than cookie invisibility. Identity Management and Endpoint Schema carry the full reasoning.

How long does the UID last?

Server-set first-party cookies are generally more resilient than script-set storage, but they are not immune and no browser guarantees 400 days. RFC 6265bis recommends a 400-day upper bound; no official WebKit source guarantees Safari honors it, and Firefox enforcement is unconfirmed (verified 2026-07-19). Without server-set cookies: WebKit purges script-writable storage, including JavaScript-set cookies, after seven days without user interaction (WebKit commit a2db53cd97, 2022-06-08), and applies a 24-hour cookie window when navigation comes from a classified domain and the landing URL carries any query string or fragment (ITP 2.2). Named click IDs are examples of link decoration, not WebKit’s predicate. Brave caps first-party cookies at 6 months whether set via JavaScript or HTTP (until Brave v1.83, JavaScript-set cookies were capped at 7 days). The dated details live in Browser Landscape.

Attribution

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

last_touch updates when a touch is accepted; first_touch is write-once. count counts accepted touch records under the boundary and deduplication contract, not visits and not page loads: a reliable external-navigation boundary always accepts a touch, while fallback fingerprint/window deduplication may honestly collapse two indistinguishable arrivals inside the window. The boundary rules are in Attribution Capture.

What if the gclid has expired?

Capture click IDs only when the applicable purpose and permission authorize it (effective ad_storage: allowed), recording captured_at and expires_at per the storage contract. Client-side retention is bounded by the controller-configured ceiling: expired values are removed from live stores, and are omitted during pre-freeze payload assembly only. If any click-ID occurrence in a frozen retry entry has expired, required or optional, wherever carried, the entire entry is terminally dropped, never edited; any independently permitted sanitized emission is a new logical event with a new event_id. Downstream, Google publishes no gclid expiry or rejection mechanic. Google Ads offline import supports click-to-conversion cycles up to 90 days for standard Data Manager sources (14 days for some database sources; vendor policy, verified 2026-07-19). The import lookback is a platform ingestion rule, not a client-retention promise. Attribution Capture defines the retention contract.

How do I handle direct visits?

You don’t do anything. A direct visit asserts no allowlisted attribution signal and no cross-site provenance, so no reliable touch boundary is established and no new touch is minted: last_touch stays as the previously accepted touch. This prevents direct visits from overwriting valid campaign attribution (Attribution Capture).

Should I capture ALL URL parameters?

No. Only allowlisted inputs are captured: the standard UTM set, registered click-ID keys, and explicitly configured custom parameters under their registered bounds. Unknown query parameters may contain PII, session tokens, or search text with no attribution value. The allowlist bounds the data and prevents accidental capture (Attribution Capture).

Can I track before consent in the EU?

While consent is pending (default T3), the core sends no data-plane event. It uses only server-injected current-request context in current-document memory (the closed three-key allowlist or null), with no UIAF cookie, localStorage, or sessionStorage write. ePrivacy Art 5(3) regulates storage of, and access to, information in terminal equipment regardless of content; EDPB Guidelines 2/2023 v2.0 (7 Oct 2024) describe that scope but expressly do not decide the exemptions (para 4). A server receiving its own request is analytically distinct from terminal storage and access, but that is NOT a legal safe harbor: user-specific link decoration is within Art 5(3) scope; request content beyond the URL, including cookie headers, is separately within scope; and URL caching and access mechanisms may be too. All remaining GDPR and ePrivacy questions, national-law variations, and lawful-basis choices are controller and counsel decisions [CONTROLLER]/[COUNSEL]. Any pre-resolution transmission exists only in the default-off restricted-measurement profile, with its own documented lawful basis, minimization, aggregation, retention, schema, and conformance rules. UIAF does not prescribe Art 6(1)(f) or any other basis. The full treatment is Consent Integration.

What about legitimate interest for analytics?

Legitimate interest cannot substitute for ePrivacy consent for the act of device storage: ePrivacy is lex specialis. The ‘strictly necessary’ exemption is the Directive’s own text; EDPB Guidelines 2/2023 expressly decline to interpret the exemptions (para 4). The restrictive reading for analytics comes from national guidance such as DSK OH Digitale Dienste v1.2 (Nov 2024). Consent Integration has the sourced version.

What is GPC and do I need to honor it?

Global Privacy Control (GPC) is a browser signal that opts the user out of sale, sharing, and targeted advertising. In a growing set of US states that opt-out is binding. It is not, by default, an opt-out of first-party analytics. The binding list is maintained as dated site-policy configuration: a gpc_binding_jurisdictions record carrying the jurisdiction list and a last_reviewed date, under a quarterly review cadence. It is never prose and never a code constant, and gpc.applicable is derived from that current, dated configuration. When GPC is detected and applicable, the overlay forces exactly the three ad-purpose permissions (ad_storage, ad_user_data, ad_personalization) to denied; it does not by itself alter analytics_storage. That non-strict default is a documented controller choice, not a protocol-level legal determination. Where counsel reads a binding jurisdiction’s opt-out as also covering first-party analytics that feeds ad targeting, the dated gpc_strict option extends the overlay to force analytics_storage: denied for applicable requests as well. Both keys are site-policy configuration only: they add no wire field and never alter the data-plane consent-object shape. A generic ‘accept all’ click does not override the signal. Enforcement is real: Sephora, CA OAG settlement, $1.2M, 24 Aug 2022 (primary). California imposes additional signal-processing and display duties under its regulations [COUNSEL]. The binding-configuration contract is UIAF-07-CONSENT-014 in Consent Integration.

What is Google Consent Mode Advanced vs Basic?

Advanced mode sends cookieless requests to Google when consent is denied; with Basic mode, nothing is sent until the user answers the banner. Per Google’s documentation the Advanced-mode requests carry timestamp, user agent, referrer, consent state, a boolean for ad-click information, and a per-page-load random number, and by default the full page URL including ad-click identifiers, unless ads_data_redaction: true is set. Recommended: Advanced mode with ads_data_redaction=true, plus privacy-notice disclosure of denied-state transmissions to Google. Cookieless pings still carry IP-at-transport, user agent, referrer, consent state, and, unless redacted, the full page URL including click identifiers. Cookieless means no device storage and no client_id, not non-identifying. Art 6(1)(f) may be named only conditionally: if the controller proposes it, the controller documents and adopts an LIA. UIAF does not select, prescribe, or guarantee any basis. Never enable url_passthrough for EEA users who denied consent; where the controller’s assessment or jurisdiction does not support this, use Basic mode. Google-tag requests are not UIAF data-plane events and never relax the pending/default-T3 no-send rule. (Denied-state transmissions go to Google, a third party; Google’s terms place basis and disclosure on the advertiser.) Google Ads conversion-modeling eligibility (official verbatim): ‘a daily ad click threshold of 700 ad clicks over a 7 day period, per country and domain grouping’ (vendor policy, changeable). GA4 behavioral modeling has eligibility thresholds documented by Google. The UIAF-side gates are in Consent Integration.

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

Revocation is a control-plane workflow, never a payload event. The browser purges the affected storage on its own predicate: on analytics-permission loss the atomic uiaf_uid/uiaf_recovery pair and the attribution record are deleted; on effective ad_storage loss click-ID members are stripped; queued retry entries whose immutable required permissions are no longer satisfied are dropped whole, never redacted or resent. The dormant (all-denied) transition sends nothing; consent-state changes reach the endpoint only as fields on the next independently authorized session payload. There is no revocation, tombstone, or consent-update event in the data plane. The mechanics are split between Consent Integration (transitions) and Data Handling (purge).

What are the three event types?

Exactly session, conversion, and identify. session is automatic: it fires when the canonical dirty projection (identity, attribution, consent state) changes or an unconsumed current-document create/recovery one-shot trigger is pending, and its own authorization holds. It does not fire on every page view. A trigger authorizes only an automatic session (never a conversion or identify) and never survives navigation, so a session can legitimately carry a projection byte-identical to the baseline, for example same-tab recovery back to the same UID. conversion is explicit, fired by application code at business outcomes, carrying a required conversion_name and a required-key conversion_id (whose value may be null). identify is explicit, fired at authentication moments, carrying an evidence array of normalized, hashed identifiers with verification metadata. All other event names of earlier drafts are retired and fail validation. The shapes are defined in Endpoint Schema.

When should I fire a conversion event vs. an identify event?

conversion records a business outcome (purchase, signup completion, lead submission), named by conversion_name (lowercase snake, 1–64 ASCII bytes) with conversion_id as a required key whose value is null or a bounded visible-ASCII string. It is never an email or other identifier; prohibited-content rules apply at producer, endpoint, and shared validator. identify records evidence that the user’s identity became known (login, signup, verified checkout), as 1–8 evidence objects of typed, profile-normalized, hashed digests with verification state; raw identifiers never appear. A checkout can legitimately fire both — Endpoint Schema for the payload shapes, Identity Resolution for the evidence rules.

Browser

Safari keeps losing my users after 7 days?

JavaScript-set cookies and other script-writable storage are purged by WebKit after seven days without user interaction. That is a purge condition, not a fixed expiry cap (WebKit commit a2db53cd97, 2022-06-08). Server-set Set-Cookie responses from a first-party server are generally more resilient. WebKit’s IP-cloaking heuristic compares address-family prefixes (fewer than 16 common IPv4 prefix bits, or 64 IPv6, is treated as cross-party), but server-set cookies are not immune, and no official WebKit source guarantees 400 days (verified 2026-07-19). The full Safari picture is in Browser Landscape.

Brave blocks everything?

Brave caps the lifetime of first-party cookies at 6 months, whether set via JavaScript or HTTP (until Brave v1.83, JavaScript-set cookies were capped at 7 days) (verified 2026-07-19). The dated rows are in Browser Landscape.

Do ad blockers block UIAF?

Native integration removes domain-reputation blocking: no filter list targets your domain. But lists also carry generic path and filename rules. Avoid tracker-shaped paths and script names (for example /api/collect, /collect?, /analytics*, /gtm.js, /gtag/js); the spec’s own example path /api/collect currently matches an EasyPrivacy rule for XHR and beacon requests. Verify path shapes against the current EasyPrivacy list at release time. Server-side forwarding is not subject to client-side extension blocking, and it is never described as ‘unblockable’ or ‘guaranteed’ (verified 2026-07-19). The evidence is in Browser Landscape.

What about Chrome Privacy Sandbox?

Google retired most Privacy Sandbox ad APIs, including Topics, Protected Audience, and Attribution Reporting, on 2025-10-17, retaining CHIPS, FedCM, and Private State Tokens. Third-party cookies remain enabled by default with no standalone prompt (vendor policy, 2024-07-22 and 2025-04-22). Details and sources: Browser Landscape.

Integration

Can I use GTM instead of native integration?

GTM can handle client-side logic, but a JavaScript cookie set via GTM is subject to WebKit’s seven-day no-interaction purge. For generally more resilient cookie persistence, use a first-party server-set Set-Cookie (native integration). Browsers may still shorten or remove it, and no 400-day outcome is guaranteed (RFC 6265bis recommends a 400-day upper bound; verified 2026-07-19). GTM can supplement native integration for event triggering and payload delivery, as Identity Management describes.

Can I add custom fields to the payload?

Only through event_data.extensions, the sole generic extension point: at most 16 dotted namespaced keys (for example "acme.segment": "b2b"), the uiaf. namespace reserved and prohibited, bounded values, and a 4,096-canonical-byte ceiling. The top-level envelope and the fixed sub-objects (identity, consent, _meta, touchpoint, evidence) are closed (additionalProperties: false): there is no top-level custom or extensions and no extra key inside _meta, which is required but closed to its four members. The registered maps (click_ids, touchpoint custom, event_data.extensions) are open within their own key-pattern and bound rules. An extension key whose local segment equals a registered click key is rejected; attribution parameters belong in touchpoint.custom. Extensions may not carry raw identifiers, credentials, tokens, consent strings, or special-category data (Endpoint Schema).

What about Shopify?

Shopify’s hosted storefront limits direct access to response headers from theme code, so the Set-Cookie integration point is an app proxy or custom app endpoint that participates in the request lifecycle. The client-side responsibilities (mirror sync, session allocation, payload delivery) follow the spec unchanged. Translate the pseudocode patterns in the Implementation Guide to the platform’s server surface.

Is there a WordPress plugin?

Not from UIAF. This is a specification, not a product. A developer would build a plugin following it: a PHP hook early in the request lifecycle reads the request, applies the consent gate, sets the Set-Cookie header before output, and injects escaped server context; client-side code handles the mirror, session allocation, and delivery per the spec. The Implementation Guide covers the server-rendered pattern, including the must-use-plugin ordering rule.

Data

Is a random UUID personal data?

Yes, for the operator. A UIAF UID is an online identifier under GDPR Art 4(1) and Recital 30, designed to re-identify the same browser across sessions. Breyer (C-582/14, ECLI:EU:C:2016:779) concerned dynamic IP addresses: background only, not the operative hook. EDPS v SRB (C-413/23 P, 4 Sep 2025, ECLI:EU:C:2025:645) confirms classification is relative to each holder’s means: the UID remains personal data for the website operator, while a recipient’s status depends on its own re-identification means. Data Handling carries the classification table.

Do I need a DPIA?

A DPIA is commonly indicated for EU deployments: UIAF involves cross-session monitoring, large-scale processing of identifiers, and dataset combination, which are factors under GDPR Art 35(3). Whether it is required is a controller determination for the concrete deployment [CONTROLLER]. Consult your DPO or counsel; Data Handling lists the screening factors.

Are UTM parameters personal data?

UTM is a parameter name, not a GDPR classification. Campaign-level UTM values are not automatically personal data; classification is contextual. User-specific URL values, and UTM values combined with a UID, session ID, click ID, timestamp, or other linkable data, or transmitted or retained beyond the transient request context, may be personal data and then require the deployment-selected documented lawful basis [CONTROLLER]/[COUNSEL]. The default pending core retains only the closed three-key context in current-document memory, performs no terminal write, and sends no event; every excluded field stays excluded. Restricted-profile exceptions require their own controller/counsel-selected basis and controls. The rules are in Attribution Capture and Consent Integration.