A/B Testing EU Alternative 2026: Optimizely and LaunchDarkly Under GDPR — Feature Flag and Experimentation Tools That Keep Data in Europe

Post #939 in the sota.io EU Cyber Compliance Series | EU-ANALYTICS-SERIE Post #6 (Final)

A/B testing and feature flag platforms sit at an unusual intersection of GDPR risk categories. They are not passive analytics tools that record what happened after the fact. They are active decision-making systems that evaluate who a user is — their location, device, user ID, account tier, or behavioural segment — and return different application experiences based on that evaluation. Every flag evaluation is a data processing act. Every experiment assignment is a profiling decision. The combination of real-time personalisation, user segmentation, and behavioural outcome tracking places these platforms firmly within GDPR's scope for profiling under Article 22 and its obligations around automated individual decision-making.

For EU product teams using Optimizely or LaunchDarkly, the question is not only where data is stored. It is what US authorities can compel these companies to disclose under the CLOUD Act, and whether the EU-US Data Privacy Framework's protections are adequate for systems that evaluate user identity in real time on every page load.

Optimizely: New York Headquarters, Delaware Incorporation, CLOUD Act Jurisdiction

Corporate Structure and Jurisdictional Exposure

Optimizely, Inc. was originally founded in San Francisco in 2010. In 2017, Episerver — a Swedish software company — acquired Optimizely's brand, product, and customer base. Episerver rebranded as Optimizely in 2021, relocating its corporate identity to New York while retaining Delaware incorporation for the US operating entity.

The Swedish heritage of the Episerver parent company is frequently cited by sales teams as evidence of European roots. This framing obscures the legal reality: Optimizely, Inc. — the entity that holds the contractual relationship for most enterprise customers — is a Delaware corporation domiciled in the United States. It is a "US person" under 18 U.S.C. § 2713, the provision that gives the CLOUD Act its extraterritorial reach.

Under the CLOUD Act, US law enforcement agencies can compel Optimizely, Inc. to produce data stored anywhere in the world, including data held in EU-region infrastructure, without requiring an EU court order and without necessarily notifying the data subjects whose information is accessed. The EU-US Data Privacy Framework addresses some commercial privacy obligations but does not limit CLOUD Act compelled disclosure.

What Data Optimizely Processes

Optimizely's Web Experimentation and Feature Experimentation products process:

• User identifiers: pseudonymous visitor IDs, authenticated user IDs, device fingerprints
• Segmentation attributes: location (country, region, city derived from IP), device type, browser, referrer, custom attributes your application sends
• Experiment assignment events: which variation a user received, when they were bucketed, which feature flag state they saw
• Conversion events: clicks, form submissions, purchases, custom goal completions tied to the user identifier
• Session and behavioural context: page URL, time of visit, session depth, custom event properties

Under GDPR Article 4(1), any information that can be linked to an identified or identifiable natural person constitutes personal data. Pseudonymous visitor IDs are personal data if the controller holds any key that could re-identify the individual — which your application database almost certainly does. The IP-derived location data is personal data under EDPB guidance. Custom attributes your application sends (user tier, account age, language preference) are personal data if they relate to an identifiable person.

Optimizely's Data Processing Agreement designates EU Standard Contractual Clauses as the transfer mechanism for data processed outside the EEA. The DPA acknowledges data flows to the United States. The SCCs do not override or limit the CLOUD Act.

Profiling and Article 22 GDPR

When Optimizely assigns a user to a variation — showing them a different price point, a different checkout flow, or a different headline — it is making an automated processing decision based on that user's personal attributes. If the variation affects something that has a significant effect on the individual (pricing, access to features, terms of service presentation), GDPR Article 22 requires that the automated decision be disclosed, that the individual have the right to contest it, and that a human review be available.

Most Optimizely users do not structure their experimentation programmes to satisfy Article 22. The typical implementation treats variation assignment as a technical detail rather than a profiling disclosure obligation. DPAs across the EU have not yet taken widespread enforcement action specifically targeting A/B testing platforms, but the legal exposure exists wherever experiments affect legally significant outcomes.

LaunchDarkly: Oakland, California, CLOUD Act Jurisdiction, Feature Flags as Personal Data Processing

LaunchDarkly's Jurisdictional Position

LaunchDarkly, Inc. is a Delaware corporation headquartered in Oakland, California. It raised venture capital funding, remains privately held, and is subject to the full scope of US surveillance law. As a US person under the CLOUD Act and a significant electronic communications service provider, LaunchDarkly can receive compelled production orders from US law enforcement for data relating to any user, regardless of where that data is stored.

LaunchDarkly markets heavily to enterprise customers and has invested in enterprise compliance features including SOC 2 Type II certification and GDPR Data Processing Addenda. These certifications address commercial data handling practices. They do not limit or modify the company's obligations under US law when served with a CLOUD Act order.

Feature Flags as Real-Time Profiling Infrastructure

LaunchDarkly's architecture is built around a key insight: every feature flag evaluation requires sending user context to the LaunchDarkly SDK or relay proxy. The SDK uses that context — user key, email, country, custom attributes — to determine which variation the user receives. In LaunchDarkly's streaming delivery model, the user context is sent at SDK initialisation and updated as context changes.

This architecture means LaunchDarkly is not receiving aggregated analytics after the fact. It is receiving individual user attributes in real time, on every page load or application bootstrap, to determine what that specific user can see and do.

From a GDPR perspective, this is profiling under Article 4(4): automated processing of personal data to evaluate or predict aspects of natural persons. The profile attributes flowing into LaunchDarkly flag evaluations — user tier, geographic region, account age, beta participant status — are personal data the moment they can be linked to an identifiable individual.

LaunchDarkly's Data Retention and Experimentation Module

LaunchDarkly's experimentation module extends beyond simple flag assignments. It tracks which users saw which variation and records conversion events — clicks, purchases, metric completions — attributed to each user's experimental context. This creates a data set that is substantively similar to what a behavioural analytics platform collects: a per-user record of interactions linked to experimental conditions.

The experimentation data is retained in LaunchDarkly's servers, processed under US jurisdiction, and covered by the CLOUD Act. For EU teams using LaunchDarkly Experimentation to test pricing changes, checkout flows, or feature access, every user data point collected is accessible to US authorities through compelled disclosure.

VWO: Indian Company, But US-Adjacent Data Infrastructure

VWO (Visual Website Optimizer) is operated by Wingify Software Pvt. Ltd., incorporated in India. Wingify is not a US company and is not directly subject to the CLOUD Act. However, VWO's infrastructure and sub-processing relationships involve US cloud providers.

The GDPR exposure for VWO comes from a different direction than Optimizely and LaunchDarkly. The primary question is whether Wingify's international data transfer mechanisms — SCCs, GDPR DPA — adequately protect EU user data when routed through US-based cloud infrastructure. VWO does not offer EU-dedicated infrastructure where data never leaves the EEA. The implicit reliance on US cloud for processing creates the same structural vulnerability as direct US company processing: data accessible to US authorities through the infrastructure providers.

VWO is a less severe GDPR risk than Optimizely or LaunchDarkly if data is stored in European AWS or Azure regions without US entity involvement, but this configuration is not guaranteed by default and requires validation of the complete sub-processor chain.

EU-Native A/B Testing and Feature Flag Alternatives

AB Tasty — French Company, GDPR-Native

AB Tasty was founded in Paris in 2013 and remains headquartered in France. It is not a US company. Its corporate structure does not subject it to the CLOUD Act. EU user data processed by AB Tasty stays within a legal framework governed by EU data protection law rather than US surveillance law.

AB Tasty provides:

• Web experimentation: A/B tests, multivariate tests, split URL tests
• Feature flags: Progressive rollouts, targeted feature releases
• Personalisation: Audience segmentation, dynamic content variation
• Session replay: Integrated behavioural context (separate module)

Data is stored in EU data centres. AB Tasty's DPA is structured around EU Standard Contractual Clauses for any cross-border transfers (primarily for sub-processors). There are no transfers to the United States in the core data pipeline.

Pricing is enterprise-oriented and quote-based. AB Tasty does not publish self-serve pricing. For EU teams that require a demonstrably GDPR-compliant experimentation platform with similar enterprise feature breadth to Optimizely, AB Tasty is the closest direct comparison.

Kameleoon — French Company, EU Data Residency

Kameleoon was founded in 2012 in Grenoble, France. Like AB Tasty, it is a French company with EU data residency and no CLOUD Act exposure. Kameleoon has built specifically toward enterprise GDPR compliance as a differentiator.

Kameleoon's product covers:

• A/B and multivariate testing: Statistical significance reporting, Bayesian testing engine option
• AI-powered personalisation: Real-time audience classification for dynamic experiences
• Feature flags and progressive delivery: Server-side and client-side flag evaluation
• Full stack experimentation: Backend and API-level experiments

Kameleoon's server-side feature flag implementation is architecturally important for GDPR. In server-side mode, flag evaluation happens on your infrastructure. The user attributes used for segmentation never leave your environment; only the variation assignment result is returned. This eliminates the data transfer exposure that exists in client-side SDK implementations that send user context to third-party servers.

Kameleoon is used by several large French and European enterprises and has GDPR advisory built into its implementation documentation.

GrowthBook — Open Source, Self-Hosted, Full Control

GrowthBook is an open-source A/B testing and feature flag platform operated by Growth Book, Inc., a US company headquartered in San Francisco. In its cloud form, GrowthBook has the same CLOUD Act exposure as Optimizely and LaunchDarkly.

The distinction is self-hosting. GrowthBook's source code is available under an open-source license. EU teams can deploy GrowthBook on their own infrastructure — on EU-region cloud providers or on-premises — and process all experimentation data without sending any information to GrowthBook, Inc.'s servers. In a self-hosted deployment, GrowthBook becomes a software tool rather than a data processor.

GrowthBook's architecture in self-hosted mode:

• Your application queries your GrowthBook instance for flag values
• User attributes used for segmentation stay within your infrastructure
• Experiment results and metric calculations run in your data warehouse (BigQuery EU, Snowflake EU, Redshift EU)
• No data flows to GrowthBook, Inc. at any point

This makes GrowthBook a viable EU-compliant option for engineering teams with the capacity to operate self-hosted infrastructure. It is not appropriate for teams that require a managed SaaS with contractual SLA guarantees from the vendor.

GrowthBook is free to self-host. The commercial cloud offering — which does involve GrowthBook, Inc. data processing — starts at a lower price point than Optimizely or Kameleoon.

Unleash — Norwegian Company, Open Source Feature Flags

Unleash is an open-source feature flag platform operated by Unleash AB, headquartered in Oslo, Norway. Norway is part of the European Economic Area and subject to GDPR. Unleash is not a US company and does not have CLOUD Act exposure.

Unleash provides:

• Feature flags: Full feature toggle management with activation strategies
• Gradual rollouts: Percentage-based and user-ID-based progressive delivery
• Context-based targeting: IP, user ID, custom context fields
• Metrics: Basic flag usage tracking
• Enterprise edition: Advanced strategies, SSO, enterprise audit log

Unleash is available as open-source self-hosted (Apache 2.0 license), as a managed EEA cloud offering, or as an on-premises enterprise deployment. The managed cloud offering processes data in EEA infrastructure.

Unleash focuses on feature flag management and gradual rollout rather than full A/B testing with statistical experimentation. Teams that need experiment analysis with significance testing should pair Unleash with a separate analytics or data warehouse layer (PostHog EU Cloud, Plausible, or their own warehouse) rather than expecting Unleash to provide it natively.

Flagsmith — UK Company, Open Source

Flagsmith is operated by Bullet Train Ltd., a UK company (UK is post-Brexit GDPR, not EEA, but the UK GDPR applies and UK-EU data flows operate under the UK adequacy decision). Flagsmith is open-source (BSD licence) and can be fully self-hosted.

Flagsmith covers feature flags, remote configuration, and multivariate flags. It does not provide A/B testing with statistical significance out of the box. Self-hosted Flagsmith on EU infrastructure eliminates the cross-border transfer concern entirely.

The Server-Side vs Client-Side Architecture Decision

The GDPR exposure of A/B testing and feature flag tools depends significantly on whether your implementation is client-side or server-side.

Client-side implementation: A JavaScript SDK loads in the user's browser. The SDK sends user context attributes to the platform's servers to determine which variation to serve. This means: (1) a third party receives individual user data on every page load; (2) consent may be required under the ePrivacy Directive for the cookie or storage the SDK uses; (3) the platform's CLOUD Act exposure directly affects EU user data.

Server-side implementation: Your backend queries the feature flag platform (or a self-hosted proxy) before rendering a response. User attributes are resolved server-side. In some architectures — particularly with local evaluation SDKs — flag values are computed using a locally cached ruleset without any network call per request. User attributes never leave your infrastructure.

For GDPR compliance, server-side implementations are architecturally superior. They limit data exposure to the minimum necessary for flag evaluation. EU-native platforms (Kameleoon, AB Tasty, Unleash) support server-side SDKs. GrowthBook's self-hosted deployment supports local flag evaluation entirely.

ePrivacy Directive: Consent Before the Flag Fires

Before any A/B testing or feature flag SDK initialises on a user's device, the ePrivacy Directive may require that you obtain valid consent for the storage or reading of information on that device. This applies to:

• Cookies used to maintain variation assignment consistency across sessions
• Local storage used by the SDK to persist user identifiers
• Any fingerprinting technique used to generate stable pseudonymous identifiers

GDPR Article 6 lawful bases are insufficient for ePrivacy Directive purposes. The ePD requires affirmative consent for non-essential storage, and feature flag consistency identifiers are non-essential. Legitimate interests cannot substitute for ePD consent.

The practical implication: your A/B testing SDK should not initialise — and should not request variation assignments — until the user has provided valid ePrivacy consent. Running experiments on visitors who have not consented to non-essential cookies creates compliance exposure independent of the GDPR transfer analysis.

EU-native platforms (AB Tasty, Kameleoon) have built GDPR consent integration into their SDKs. They support deferred initialisation pending consent and consent-state-aware experiment activation. US platforms with EU DPAs but no EU legal team typically treat consent integration as a customer implementation responsibility.

DPIA Requirement for Large-Scale Experimentation

GDPR Article 35 requires a Data Protection Impact Assessment before processing that is "likely to result in a high risk to the rights and freedoms of natural persons." The criteria in Article 35(3) and WP248 (EDPB Guidelines on DPIA) include:

• Systematic monitoring: Continuous tracking of user behaviour across sessions
• Large-scale processing: Experimentation programs covering significant proportions of your user base
• Profiling: Automated evaluation of personal attributes to assign treatment conditions
• Innovative technology: Novel combinations of tracking, personalisation, and outcome measurement

A/B testing programmes at scale can satisfy multiple DPIA criteria simultaneously. If your experimentation program covers more than a small fraction of your user base, tracks behaviour across multiple interactions, and uses personal attributes for targeting, a DPIA is likely required.

The DPIA must document: the processing purpose, the necessity and proportionality of the processing, the risks to data subject rights, and the mitigating measures. For US-platform experimentation, the DPIA must address the international transfer risk and the absence of CLOUD Act limitation in the EU-US DPF.

Migration Path: Moving from Optimizely or LaunchDarkly to EU Alternatives

Assessment Phase

Before migrating, audit your current implementation:

1. Which Optimizely or LaunchDarkly features do you actively use? (Flags only? Experiments? Personalisation? Rollouts?)
2. What user attributes flow into the SDK? Document the full attribute set.
3. How many active experiments run concurrently?
4. Do you rely on the platform's statistical engine for significance testing, or do you export raw data?
5. What is your infrastructure capability for self-hosted tooling?

Decision Matrix

Data Portability

Optimizely and LaunchDarkly both allow data export. Experiment results, flag configurations, and targeting rules can typically be exported in JSON or CSV format. Flag migration requires rewriting SDK initialisation calls and updating any environment-specific configuration. Experiment histories in US platforms are historical data and do not need to be migrated unless you require continuity in statistical analysis.

For teams running continuous experimentation, plan for a parallel-run period where both platforms are active during the transition to validate consistency in flag evaluation logic.

EU-ANALYTICS-SERIE Summary: What EU Teams Use Instead

This post completes the six-part EU-ANALYTICS-SERIE examining GDPR and CLOUD Act exposure across the analytics stack:

The pattern across all six categories is consistent: US-incorporated analytics and experimentation platforms are subject to the CLOUD Act regardless of where they store data, what SCCs they sign, or what EU-US Data Privacy Framework certifications they hold. EU-native alternatives — incorporated in France, Norway, Denmark, Czech Republic, Estonia — operate under EU law. Self-hosted open-source tools eliminate the third-party data transfer question entirely.

For EU SaaS teams navigating GDPR compliance in 2026, the analytics and experimentation stack is one of the clearest areas where the choice of tool directly determines the compliance risk profile. The alternatives exist, are production-ready, and are used by European enterprises at scale.

What sota.io Gives You

sota.io is a European PaaS — infrastructure hosted in the EU, operated by a European entity, subject to European data protection law. If you are migrating from a US analytics stack and need infrastructure that matches the data residency guarantees of EU-native analytics tools, start here. No CLOUD Act exposure. No cross-Atlantic data transfers in your hosting layer.

This post is part of the EU-ANALYTICS-SERIE on sota.io. The series covers GDPR and CLOUD Act exposure across the analytics stack: Google Analytics, Mixpanel, Segment, Amplitude, Hotjar/Clarity, and this post on A/B Testing tools.