Split

Overview

Split is a feature flagging, experimentation, and feature management platform used by engineering and product teams to control feature rollouts independently from code deployments. The platform enables gradual rollouts (releasing a feature to 1% of users, then 10%, then 100%), A/B and multivariate experiments (measuring whether a new feature improves conversion, engagement, or other metrics), and kill switches (instantly disabling a feature in production without a deployment).

Split is used by teams that practice continuous delivery and want to decouple code deployment from feature activation. It is competing in the same space as LaunchDarkly, Optimizely Full Stack, and Flagsmith.

What This Script Does

The Split Browser SDK evaluates feature flags and tracks experiment metrics in the visitor's browser:

Feature flag evaluation: On initialization, the Split SDK fetches the current flag configuration for the visitor from Split's edge API (sdk.split.io). The SDK evaluates targeting rules — which user segments, percentage rollouts, or individual user overrides apply — and returns the treatment assignment (e.g., "on", "off", "variant_a", "variant_b") for each flag. This evaluation determines which features the visitor sees.

User identity and targeting: Split evaluates flags against a "key" — typically a user ID for authenticated users or an anonymous identifier for logged-out visitors. For anonymous visitors, the SDK may generate a UUID stored in localStorage or a cookie to maintain consistent treatment assignment across sessions. This prevents the same visitor from seeing different feature variants on different page loads, which would create a poor user experience.

Impression tracking: Each time a feature flag is evaluated, Split records an "impression" — the fact that user X was shown treatment Y at timestamp Z. Impressions are batched and sent to Split's data plane for experiment analysis. These impressions are the raw data from which Split calculates statistical significance for experiments.

Event tracking: The SDK supports custom event tracking (client.track('eventType')) that records conversion events attributed to specific feature flag treatments. These events feed into Split's experiment metrics dashboards, enabling teams to see whether a feature change increased conversions, reduced errors, or improved engagement.

Real-time streaming: Split can operate in streaming mode, opening a persistent connection to Split's streaming infrastructure to receive flag configuration updates in real time without polling.

Consent & Compliance

Split has a mixed consent profile that depends on implementation:

• Feature flag evaluation for functional consistency (no consent required): The core flag evaluation function — ensuring a user consistently sees the same version of a feature across sessions — can be considered strictly necessary for delivering a coherent user experience. A session or local storage identifier used solely to maintain consistent treatment assignment is a functional mechanism, not a tracking cookie in the marketing sense.
• Experiment tracking and analytics (consent required): The impression tracking and custom event tracking components — which record user behavior attributed to feature treatments for analytics and optimization purposes — constitute analytics data collection. Under GDPR, this requires a lawful basis; under ePrivacy, cookies or storage used for analytics require consent. These components should be gated behind analytics consent.
• GDPR: Where Split stores an anonymous identifier in a cookie or localStorage for cross-session consistency, the strictly necessary exemption may apply for the flag evaluation function. For experiment analytics, legitimate interests requires a balancing test; explicit consent is safer.
• CCPA: Experiment performance data (behavioral events tied to user identifiers) constitutes personal information. This is processed by Split as a service provider.

Should You Block This Without Consent?

Conditional. Pure feature flag evaluation for consistent UI behavior can typically run without consent. Experiment tracking, analytics event collection, and behavioral measurement should be blocked until analytics consent is obtained. If Split's functional and analytics capabilities cannot be separated in your configuration, treat it as analytics and require consent.