Privacy built into the evidence model.
This notice explains the data Funl is designed to handle across its public website, browser analytics, trusted commercial outcomes and protected application.
Last updated 11 October 2026What Funl may process
Depending on the features a customer enables, Funl may process registered website domains, page paths, hostnames, referrer domains, campaign parameters, custom events, goals, funnel and journey evidence, optional revenue values and trusted commercial outcome events. If a customer explicitly enables heatmaps, Funl may also process sampled click coordinates, scroll-depth thresholds and page/viewport dimensions for query-stripped page paths. If the installed tracker explicitly enables real-user performance, Funl may process browser-reported LCP, INP, CLS, FCP and TTFB measurements for the current query-stripped page.
Browser analytics uses pseudonymous session and visit identifiers. Funl is designed not to persist raw IP addresses. Where enabled, trusted infrastructure headers may be used to derive bounded country and region information; city, coordinates and external IP enrichment are outside the current product design.
If client-environment enrichment is explicitly enabled, Funl may derive coarse browser family, operating-system family and device class from the request User-Agent. The raw User-Agent string is not stored by that capability.
Identity and protected access
Protected Funl access uses 1App as the shared identity authority. Funl separates authentication from application entitlement and is designed to fail closed when current Funl access cannot be verified.
The browser application session uses an opaque Funl session identifier. Provider access and refresh material, when the integration is enabled, remains server-side and encrypted rather than being exposed to browser storage.
Why the data is used
Funl uses the data it receives to provide commercial analytics, funnels, journeys, attribution, revenue context, segments, retention, evidence-based opportunity prioritisation, trusted outcome reporting and intervention measurement. The product deliberately distinguishes observed evidence from hypotheses and causal claims.
Data minimisation and collection controls
The browser tracker is designed to respect Do Not Track, reject configured ignored IP ranges before persistence and avoid storing raw query strings when only bounded acquisition parameters are required. Browser traffic and trusted backend outcomes retain separate provenance.
Heatmaps are separately gated and use sampled coordinate evidence only. The heatmap capability is designed not to record DOM text, form or input values, element selectors, screenshots or a session-replay stream, and it reuses the existing bounded Funl visit context rather than creating a separate durable heatmap identity.
Real-user performance collection is separately explicit in the tracker snippet through data-funl-performance="true". It uses browser Performance APIs and the normal Funl analytics transport; Funl does not add a synthetic monitoring provider or a separate performance identity for this capability.
Client-environment labels are server-derived technical context only. They reuse the existing pseudonymous analytics session and do not create a separate durable device identity or persist the raw User-Agent.
Service providers and connected systems
Funl relies on infrastructure and identity providers required to operate the service, including its hosting platform and 1App when protected access is enabled. Customer-authorised systems may send trusted server outcomes through scoped credentials. Those integrations remain subject to their own terms and privacy practices.
Retention and deletion
Retention depends on the data type, product configuration and any applicable customer agreement. Funl rotates pseudonymous browser identity on a monthly basis and uses bounded application-session lifetimes. Funl does not currently claim an automatic analytics-retention schedule.
Where the separately gated property data-controls capability is enabled, the authorised property creator can inspect a bounded property-data inventory, export that aggregate inventory and permanently delete the property through a strongly confirmed tenant-scoped action. Property-scoped analytics and configuration records are removed through the reviewed database cascade, while a minimal lifecycle audit of the deletion survives without retaining the deleted analytics content. This capability is not an undo queue or a raw event archive.
Your choices and requests
Privacy rights differ by jurisdiction. Customers and authorised users should use the support or contractual contact channel supplied with their Funl service for access, correction or deletion requests. Do not send sensitive incident, health or payment-card information through Funl analytics event fields.
Changes to this notice
We may update this notice as Funl capabilities, infrastructure or legal obligations change. Material changes should be reflected by an updated date on this page.