FAQs & Q&As

Quick answers to some of the most commonly-sought questions about Split.

What's Split?

Split builds on feature flags to create the platform for controlled rollouts, so any team can target customers and release or revert new features without a deployment—or touching code.

What are feature flags?

Feature flags, also known as feature toggles or feature switches, are just if-else statements that developers ‘wrap’ their features in, allowing them to be controlled post-deployment. At the most basic level, a feature flag gives an engineer the ability to deploy a feature in an ‘off’ state, so that it’s invisible to all traffic until it’s switched to on, or similarly, the ability to kill any feature by turning it off.

To learn more about feature flags, try our article Understanding Feature Flags or Using Feature Flags in our documentation.

Who's using feature flags?

Robust feature-flagging operations are at the core of some of today’s biggest tech companies, most notably Facebook, LinkedIn, and Netflix. Simply put, it’s a best-practice for how feature development should be done.

Who's using Split?

Split is used by forward-thinking teams large and small. Visit our Customers section to hear directly from companies like WePay, Main Street Hub, Segment and Hellosign.

If you’d like to speak with one of our customers directly, drop us a line at hello@split.io and we’d be happy to make an introduction.

What does it take to install Split?

Installing the Split SDK is incredibly easy; it’s a basically copy-and-paste. Visit our installation documentation to see how it works in the language of your app.

How can I use Split to create targeted releases?

Split lets you group your users into segments that can then be targeted with releases. The attributes that make up these segments are up to you, and can be drawn directly from your database or, in the case of a percentage rollout, chosen at random. Learn more about creating segments in our segments documentation.

What are Split's security practices?

As a service that helps you release features directly to your users, we take security seriously. Our Security and Availability Overview addresses many of these issues in more detail, but briefly, Split addresses security through:

  • Application authentication: Two-factor authentication and Google-verified sign-in are available to all customers.
  • Encryption: we default communications over SSL, store keys and secrets using Amazon’s KMS, and login tokens are salted.
  • Internal security controls: we peer-review and staging-test production code changes, all access to REST API endpoints require an access key, we do not capture any identifiable information on your customers, and all internal systems are gated by two-factor authentication.
  • Infrastructure security: we limit access to production servers, use a global CDN to limit DDOS exposure, maintain daily datastore backups, and utilize separate development and production environments.
  • External audits: Split undergoes a yearly penetration audit from Gotham Digital Science, which includes owasp-10 certification.

Does Split see my user’s data?

By default, Split does not see any user-identifiable data. Split does log anonymized impression data for each user experiencing a feature, giving you insight into how many times your feature was seen by your users.

What is a 'feature' in Split?

A feature is basically any bit of code, front-end or back-end, that you can wrap in an if-else statement (the Split feature flag). Features can be as big or small as you’d like them to be, from an entirely new version of the app, to a single backend service connection, to a button on a web page.

What's a 'controlled rollout'?

A controlled rollout is the process of targeting feature releases to subsets of your userbase. Developers do this for a few reasons:

  • Risk mitigation: Slowly releasing a new code to only a small amount of traffic lets developers thoroughly test new technologies before they can impact everyone.
  • Feature segregation: Extremely targeted feature flagging can deliver different experiences to different audiences, like VIP customers or a beta list.
  • QAing in Production: Turning features on only for employees allows QA teams to see them in-production, just like the customer would.

What environments can I use Split in?

Any and all environments. Split has no cap on the number of environments teams can work in, and features live across environments to ensure consistency. User permissions can also be managed across environments, letting anyone control features on staging but only admins manage production, for instance.

How many environments can I use Split in?

Any and all environments. Split has no cap on the number of environments teams can work in, and features live across environments to ensure consistency. User permissions can also be managed across environments, letting anyone control features on staging but only admins manage production, for instance.

How fast is delivering features with Split?

Short answer: on the order of microseconds.

Longer answer: Split lives post-deployment, in your app. You install our SDK at the app layer, then just wrap any feature you’d like to control in the Split feature flag. When a new user visits your service, the calculation made to show them the feature (or not) is done in real-time, in the app, without needing to ‘phone home’ to Split to make the decision. This typically takes a few microseconds to execute.

How fast is can a feature be killed in Split?

Short answer: on the order of seconds.

Longer answer: When you initiate a kill in Split (or any rollout plan change) your change is sent from Split’s cloud UI, on to our globally distributed CDN (Fastly), downloaded completely into your app, then executed as soon as all the instructions are received. For a common SaaS app hosted in a typical cloud infrastructure like AWS, this usually happens within 30 seconds.

What's a 'call'?

A 'call' is just our term for anytime Split makes a decision on what feature to show. We log all of these to give you in-app insight into how your audience is engaging with your features, giving you insight into the success of your rollout.

Where does Split fit in my continuous delivery workflow?

Split lives post-deployment, in your app, and Split users control feature releases after their code has been deployed. From the continuous delivery perspective that means developers can freely commit new work to ‘master’ with the feature safely set to an ‘off’ state, then, once the code has been pushed to production, turn it on only for internal employees to test, demo and QA. When a feature is ready to be released to the public it can be done slowly, and more importantly from a CD standpoint, independently of any other feature in the app. This fundamental decoupling of code pushes from feature releases is an essential part of fulfilling the promise of CI/CD—anyone can contribute at anytime, and all code can go live at anytime without breaking things.

Why should we work with the Split team?

We’re drawn from top-tier tech companies. We’ve experienced the problems inherent in the ‘old way’ of doing releases first hand, and we’ve successfully built controlled rollout platforms internally at companies like LinkedIn and Salesforce. It was our experiences there that drew us to create Split as a service that anyone can use.

We’re dedicated to our customers, providing in-app chat support, and are happy to connect you to existing Split users for reference. We’re also backed by Accel partners, and based in the heart of Silicon Valley.

What happens to my app if Split goes down?

Split lives post-deployment, within your app. Only release planning is based in the cloud, so if that connection is ever severed - whether that’s Split going down, your app losing connection to the internet, or something else - your app will continue to serve the last known set of release instructions.

To mitigate against downtime, Split is connected to a globally distributed CDN—Fastly. How well do we work with Fastly? We wrote the open source Java API wrapper they currently recommend using.

Does Split work with any existing tools?

We want to help teams deliver the best code as fast as possible. To help with that, we’ve built integrations into the following services:

We’re always working to further our integrations portfolio. If you’d like to connect your service to Split, drop us a line at hello@split.io.

How can I connect Split with a service you don’t currently provide an integration for?

In addition to our named integrations, Split provides a webhooks integration that can connect to many different services. View our integrations documentation, or contact our support team to get a hand.

If you’re looking to connect Split’s changelog and event data to an analytics platform, our Segment integration can get Split data to most analytic services or databases.

Is Split open source?

As a service, no. Split is a paid, commercial, subscription service. Our SDKs are open source, allowing anyone to kick the tires and see how we decide how features are shown.

What languages does Split support?

Split currently works with Java, JavaScript, .Net, Node.js, PHP, Python, Ruby, and Ruby on Rails.

We’re always working on new languages. Contact us at hello@split.io if you’d like to participate in a beta.

Who can use Split?

Split was built with teams in mind. Once your feature is connected to Split, anyone on your team is capable of controlling its rollout. Releasing and killing a feature only take a couple of clicks, and editing even complex rollout plans is simple and intuitive. Because Split works across environments, you can let teammates experiment on staging or development servers before creating production rollout plans. Split’s integration also bring release status and alerts into the apps everyone on your team is using, like JIRA or Slack.

Does Split have an API?

Yep. You can use our admin API to push data to Split, get data out of Split or build custom integrations. You can read more in our API documentation.

Does Split work for permanent features as well as experiments?

Split isn’t just for trying out experimental features and QAing in production, though it’s great at both of those. You can use Split to permanently control the targeting of features you’d like to subtly serve to different audiences. For example, giving users of different pricing tiers or geographies the feature set that’s most appropriate for them. Or you can simply use Split to give every new feature introduced a quick and easy on/off switch, letting all of your engineers contribute to production without worrying something will go live, and your QA team the ability to turn off anything that could fail in the future.

What kind of data does Split provide?

When you control your rollouts with Split you get two new, distinct data sources. First, Split provides an audit log of every roll out event that is controlled in Split, with metadata that includes the timestamp, feature name, description, the person who made the change, and a link back to Split. Second, it provides an impression log of every user who saw the feature. Together, you can use these two data sources to correlate outages or service degradations with release events, and understand who experienced the failure on your site.

How can I get started with Split?

Split has a free 30 day trial, and we’re happy to help with the getting started process as much or as little as you’d like. Sign up to get started, and begin reading the documentation to dig into installing Split in your code.