Data Processing & Privacy

Flaggr processes feature-management data to provide flag evaluation, rollout safety, and observability workflows. This page describes the hosted service at flaggr.dev. Self-hosting is available on request, and a self-hosted deployment processes data in your own infrastructure.

Data Processing Model

• Customer configuration data: flags, services, projects, targeting rules.
• Evaluation context data: attributes provided at evaluation time.
• Telemetry data: evaluation events and operational metrics, and what the SDK's telemetry plugin sends (evaluation summaries, Web Vitals and errors).
• Browser analytics data: page views, Web Vitals and conversions, plus clicks, errors and scroll depth where enabled, from pages that load the analytics script, with the flag values those pages publish.
• Mobile app events: the events your apps send to the mobile ingest.
• Console analytics: how members use the Flaggr console (admin events), for the admin funnel and adoption cohorts.
• Access data: authentication, authorization, and audit records.

Where Data Is Stored and Processed

Privacy Commitments

• Data is used to operate and improve the feature-management platform.
• Access is limited to authorized personnel and systems.
• Tenant isolation boundaries are enforced at API and storage layers.
• Browser analytics (ingest.flaggr.dev) never stores or logs visitors' IP addresses. From the address the ingest keeps only the country and a daily keyed hash of the address (or its IPv6 /64), used to cap any one sender's influence on rollout metrics. See Browser Analytics.
• Before storage, analytics ingest scrubs every URL it keeps (page URLs, paths, referrers, link targets, error sources and resource URLs). It drops fragments, so a hash-routed app's paths (/#/dashboard) are stored without their route. It replaces with redacted user information, a path segment that is a JWT, any query or path parameter value that holds an email address or a JWT, and the value of any query or path parameter whose name looks like a credential: names containing token, secret, passw, signature, apikey, jwt, bearer, sessionid, saml, nonce, ticket, csrf or email, among others, or that has a word such as code, key, auth, state, session, sid, otp or pin (auth_code, sessionKey). Common names like code, state and key are on that list, so their values are redacted even when they hold no secret. mailto:, tel:, sms: and callto: links keep only their scheme. In page titles, click text and error messages and stacks, http(s) URLs are scrubbed the same way and email addresses redacted. Custom event properties and flag values from the browser script are stored as sent, and so are tokens and email addresses that are a plain path segment of those URLs (/reset/<token>, /unsubscribe/jane@example.com) and a token inside a URL nested in a parameter (a sign-in page's next). The Analytics API Reference has the full list of names.
• SDK telemetry, mobile app events and the console's own analytics are scrubbed the same way, and further: path segments that hold an email address or a JWT, and JWTs in text, are redacted too, and a URL nested in a parameter (such as a sign-in page's next) is scrubbed as well. Every string property of a mobile or console event is scrubbed, and a user ID that holds an email address or a JWT is stored as null.
• Privacy and retention behavior is documented and versioned.

Data Subject and Customer Requests

• Access and deletion requests are handled through support workflows; the Privacy Policy says how to make one.
• Customers may request export of project configuration data.

Related

• Privacy Policy
• Data Retention
• Security & Trust