Split: Feature Management and Experimentation
Feature flags have enabled safer progressive rollouts and support data‑driven experimentation
What is our primary use case?
My main use case for Split is feature flagging management and controlling feature releases in my project. We created feature flags for new application features and enabled them only for select users during testing. This allowed for granular rollout and A/B testing, and to quickly disable a feature if any production issue occurred. Split was integrated with our application and CI/CD pipelines, which helped us release features independently from development and reduce development risk.
I can provide a specific example of how I used Split for a feature rollout when I created and managed feature flags in Split for a customer-facing web application, configured user targeting rules, and performed a canary release. We released to 10% of users first, monitored the feature's performance and user impact, and rolled back the feature instantly if any issues were detected. The benefits were reduced production risk, faster releases, better testing and experimentation, and improved user experience through controlled rollouts.
I use Split for feature flagging management and controlling feature releases. I create and manage feature flags to enable new features for selected users, perform gradual rollouts, and conduct A/B testing. Split helps reduce development risk by allowing instant rollback for problematic features without code deployment, improving release reliability and user experience.
What is most valuable?
The best features Split offers in my experience include feature flagging with progressive rollout. It allowed our team to release new features gradually to select users, monitor performance, and quickly roll back changes without redeploying the application. This reduces production risk, improves release confidence, and supports A/B testing and experimentation for data-driven decisions.
The progressive rollout specifically helps my team during releases by reducing development risk, improving reliability, and enabling faster feature delivery. The team can safely roll out changes, conduct A/B testing, and roll back problematic features without downtime. This increased development agility, improved our use of experimentation, and helped us make data-driven production decisions.
Split has positively impacted my organization by reducing development risk, improving reliability, and enabling faster feature delivery. The team can safely roll out changes, perform A/B testing, and roll back problematic features without downtime. This increased development agility, improved user experimentation, and helped us make data-driven production decisions.
What needs improvement?
Split could be improved with a simpler onboarding experience, more intuitive UI navigation, and enhanced analytics for measuring feature impact. One challenge we encountered was managing a large number of feature flags across teams, which increased complexity and required regular cleanup. New team members also needed time to understand flag dependencies and rollout trends.
For a strong feature management platform, Split could be improved with a simpler onboarding experience, more intelligent user navigation, and enhanced analytics for management and impact.
Regarding Split's analytics capabilities, an area for improvement could be providing users with visual flagging of parameters and capabilities. Advanced, built-in dashboards for deeper feature performance and behavior analysis would allow users to more easily measure outcomes without relying on external analytics tools.
There are security issues that could be improved within Split.
For how long have I used the solution?
I have been using Split for six years.
What other advice do I have?
In my organization, Split is deployed in a public cloud environment. The application services were hosted on AWS. Split was integrated through the SDK and a cloud-based platform for feature flagging management. This setup allowed for the central management of feature releases, performing gradual rollouts, and monitoring feature performance across multiple environments without maintaining additional infrastructure.
My organization accessed Split through the AWS Marketplace since our application was hosted on AWS, which simplified vendor management and billing. The procurement and integration involved using Split's SDK and services for feature flagging, progressive rollouts, A/B testing, and controlling feature releases across development, staging, and production environments.
I would give advice to others looking into using Split by recommending it to organizations looking for safer, faster releases. Its feature flagging, progressive rollout, and experimentation capabilities reduce development risk and improve release confidence. Start with a clean feature flagging strategy, establish governance practices for managing flags, and regularly clean up unused flags to keep the environment organized and scalable. I would rate this product a 9 out of 10.
Which deployment model are you using for this solution?
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Dynamic configuration has simplified multi-environment rollout and now controls deployments on demand
What is our primary use case?
What is most valuable?
Working with dynamic configs is very good and was very easy because we have an environment where we can set up staging, prod, and dev. We can have multiple checks based on which field and which checks we want to apply to a particular config. All these options make us more flexible to change or update the config on a dynamic basis.
The dynamic config updates with Split work without requiring any deployment of the service or software. The APIs we used were very fast and we get the response within 10 milliseconds or so. It is very fast to use an API call for all the config fetching from Split.
Split offers multiple environments, and we have so many fields and checks which we can apply. We can specify countries and apply different checks such as if, else, not in, and in. This provides more flexibility in applying the config based on the checks.
We first try in a dev environment while working on a project. Then we do all the experiments with it and finalize it and move it to the staging environment. There we also do a final round of checks to ensure that all the configs we have defined are working as intended. Then finally we go to production, and there also if we want to have any changes, we can do it on the fly.
The environment feature allows us to approve from dev to staging and then finalize the same thing to prod. The multiple checks are really important features.
The environment feature and the workflow have become very smooth because for a small change in the config, we do not have to deploy the software again. We only have to go and change the config in Split. This gives us more flexibility and a dynamic way to handle and manage the prod config. For example, if I am launching something in India first and then want to launch it for other countries, I only have to go to Split and update the config.
What needs improvement?
The UI of split.io can be improved.
For how long have I used the solution?
I have used it while I was working on a project for approximately two or three months.
What other advice do I have?
Split is a great way to handle the config based on checks and in a dynamic way if you want to control your software without doing any deployment. Split can help you there. Split is a great way to dynamically handle config without requiring the deployment of the services or software. This is what I primarily associate with Split. I would rate this review a 9 out of 10.
Feature flags have transformed how our team releases safely, tests gradually, and rolls back instantly
What is our primary use case?
In my project, I have used Split for feature flagging, management, and control. Using it, we create feature flags for new application features and enable them only for selected users during testing, allowing for performance monitoring, gradual rollouts, A/B testing, and quickly disabling features if a production issue occurs. Split was integrated with our application and CI/CD pipelines, which helps release features independently from development and reduces development risk.
In my latest project, a customer-facing web application, we created management features and flagging in the Split configuration with user target rules so we can do a canary release. We released to 10% of users, monitored the feature performance and user impact, and rolled back the feature when issues were detected. This further reduced production risk, allowed for faster releasing, better testing, experimentation, and improved user experience through controlled rollouts.
A new dashboard feature was ready for production, but we wanted to minimize the risk. Using Split, we created a feature flag and enabled the feature for internal users only. After successful testing, we gradually rolled it out to 10%, 25%, and then 100% of users, monitoring performance and user feedback. When a minor issue was detected, we temporarily disabled the feature through Split without a deployment. The application fixed the issue and we resumed the rollout safely.
What is most valuable?
The best feature Split offers, in my experience, is the feature flagging with progressive rollout. It allowed our team to release new features gradually to select users, monitor performance, and quickly roll back changes without deploying the application. This reduces production risk, improves releasing confidence, and supports A/B testing and experimentation for data-driven decisions. Split has positively impacted our organization by reducing development risk, improving release reliability, and enabling faster feature delivery. Our team can safely roll out changes to specific user groups, perform A/B testing, and quickly roll back problematic features without downtime. This increased development agility and improved user experience helps us to make data-driven production decisions.
What needs improvement?
Split is a strong feature management platform, but it could improve with a simpler onboarding experience, more intuitive UI navigation, and enhanced analytics for measuring feature impact. One challenge we encountered was managing a large number of feature flags across environments, which increased complexity and required regular cleanup. New team members also needed time to understand flag dependencies and rollout strategies, which increased with complexity and required regular attention.
For how long have I used the solution?
I have been using Split for six years.
Which solution did I use previously and why did I switch?
Before using Split, releasing a new feature typically required a full deployment and coordination across the team, taking several days to complete and validate. With Split, we could deploy it independently and enable features through feature flags. This reduced release time by approximately 50 to 70%. For example, a feature that previously took three to five days to release and monitor could be rolled out safely on the same day.
What other advice do I have?
Feature flagging is for running, managing, or controlling feature releases. I have created management feature flagging to enable new features for selected users to monitor performance, and do gradual rollouts and A/B testing. Split helped to reduce development risk by allowing us to roll back problematic features without re-deployment, which improves release availability and user experience.
The features that are foremost are the feature flagging and progressive rollout capability. It makes my workflow smoother by allowing me to release features gradually, test changes with specific user groups while monitoring impact in real time, and instantly disable the feature if issues arise, all without requiring a new deployment.
I would recommend Split for the organization that wants safer and faster software releases. Its feature flagging, progressive rollout, and experimentation capabilities help to reduce development risk and improve release confidence. Start with a clear feature flag strategy, establish governance practices for managing flags regularly, clean up, and use flags to keep the environment organized and scalable. My overall rating for Split is 9 out of 10.
Which deployment model are you using for this solution?
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Feature flags have supported safer rollouts and now manage risk and governance for cloud releases
What is our primary use case?
My main use case for Split is for controlled feature releases and rollouts, especially when issues are detected. In addition, I use Split to manage releases for users, and marketing is involved in the process too. I am able to detect issues quickly and respond.
How has it helped my organization?
Split has helped us release features faster and with less risk. Feature flags allow us to separate deployments from releases, enabling gradual rollouts, quick rollbacks, and safer testing. This has reduced production issues, improved team collaboration, and increased confidence in delivering new features. The analytics and experimentation capabilities also support data-driven decisions and better user experiences.
What is most valuable?
The best features Split offers in my experience include the basic feature as well as the my expendence feature. I appreciate its integration with the progressive rollout functionality. Split has positively impacted my organization by reducing governance risk in roaming, raising deliveries.
What needs improvement?
I believe Split can improve by enhancing their onboarding experience and providing a more intuitive UI and analytics for measuring feature impact. One challenge I have encountered is managing a large number of features across the moment, which increases complexity prior to regular cleanup. New team members also need time to understand the feature lab.
For how long have I used the solution?
I have been using Split for about five years.
What other advice do I have?
The key reasons behind my high rating for Split include its development workflow and its ability to help me gain confidence and stability. I find that Split's governance and security are provided through strong governance and security during the rollout based on access for RBAC audit log approval workflow and environment level. This feature ensures that only authorized users can modify feature flags and releases, checking for AI-powered applications. The system can be used safely for monitoring and rigorous rollout. In future development, it maintains control, compliance, and operational transfer receipts. Regarding Split's AI capabilities, I find that poor release helps identify accuracy issues early. As a result, AI features are developed more confidently and with lower risk. My overall rating for this product is 9.5 out of 10.
Which deployment model are you using for this solution?
If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?
Experimentation has boosted conversion rates and guides faster, safer feature decisions
What is our primary use case?
The main use case for Split would be the experimentation and analytics part. For example, we have two different kinds of components or two different types of pages that we need to test to see which page performs better in terms of users clicking on it via a CTA button. We track them via Mixpanel, making Split an actual use case for determining which variant would be successful in terms of CVR increase.
Recently, we have used Split for an experiment that determined if the user can provide his PII details, such as first name, last name, DOB, etc. Variant A involves entering personal details, while variant B involves entering the employee name to check eligibility. We aimed to find out which would increase the CVR: entering personal details or entering employee details, and we ran this experiment using Split.
What is most valuable?
The best features Split offers include A/B experimentation itself, multivariant experiments, and a limit exposure feature that allows us to manipulate the traffic going through the split. We can decide to send only 10% of the traffic or 100%, depending on our limit exposure design. Additionally, we have a tracking mechanism and live trail monitoring, making these tools really good.
The limit exposure feature in Split decides if the experiment is healthy or not. For example, we enroll the experiment for 5% of users and check the experiment's healthiness from that. We verify if the on variant is working properly and if the off variant is functioning well to ensure that extra users are not affected if something goes wrong. That is the main feature of limit exposure.
I would say Split has impacted us a lot because we use it for gating new features while going into production, ensuring that those features are not rolled out prematurely. Overall, our organization is positive about using Split.
What needs improvement?
Split can definitely be improved by introducing something like a library, as we are currently making external API calls that contribute to latency and extra costs for our services. A library would have been better than relying on HTTP calls to improve the speed of Split.
I chose 8 out of 10 for Split because, firstly, it can definitely improve itself by removing the HTTP call and using a library, which would really help our team. Additionally, we tend to move towards other issues related to Split due to flickering issues, which we observed because of latency.
For how long have I used the solution?
I have been using Split for about two years now.
What do I think about the stability of the solution?
Split is stable.
What do I think about the scalability of the solution?
Split's scalability is quite good, as it can scale up easily, and the exposure is also fine with a nearly 50-50 ratio. So, it's scalable.
How are customer service and support?
We haven't encountered any significant issues with customer support, but we did have one or two minor issues, and they were pretty reachable.
What other advice do I have?
Split itself has many properties like attributes and split impressions, which are really good tools for Mixpanel tracking of the experimentation. I would suggest that this is a really good product for the use case of experimentation.
Split has increased some of our CVR; for example, in a recent pop-up model experiment, our conversion was around 15%. Drastically, once we started the experiment, the on-variant won by increasing the CVR up to 35%. This makes it a really good tool for determining which particular feature would deliver the expected CVR. It has also reduced the time it takes to determine such outcomes; in approximately two weeks, we decide whether a feature should be rolled out permanently or not. Moreover, it has minimized errors as well.
I would definitely suggest that others use Split for experimentation purposes, not just for gating features, as that is the only benefit we have experienced from using Split. I gave Split a rating of 8 out of 10.
Feature flags have transformed how we deliver experiments and release features with confidence
What is our primary use case?
Split has helped streamline our cloud-native application delivery by enabling safe feature rollouts and controlled releases through feature flags. The ability to separate deployment from release reduces risk, improves testing, and allows faster issue resolution. Its intuitive interface, targeting capabilities, and analytics have improved collaboration across teams and increased confidence in our release process.
How has it helped my organization?
Split helped us accelerate feature releases while reducing deployment risk. By using feature flags and controlled rollouts, we were able to test changes safely, minimize production issues, and respond quickly when problems arose. The platform improved release confidence, enhanced collaboration between teams, and reduced the operational effort required to manage software deployments.
What is most valuable?
Split's best features are feature flag management, controlled rollouts, audience targeting, experimentation, and analytics. Feature flags allow teams to release code safely without exposing features to all users immediately. Controlled rollouts reduce deployment risk, while targeting enables personalized user experiences. The experimentation and analytics capabilities provide valuable insights into feature performance and adoption, helping teams make data-driven decisions and deliver software with greater confidence.
What needs improvement?
Split is a strong feature management platform, but there are opportunities for improvement. Simpler onboarding with guided workflows and beginner-friendly documentation would help new users get started faster. More advanced analytics and reporting could provide deeper insights into feature adoption and experiment outcomes. Streamlining parts of the UI would improve usability at scale, while more flexible pricing and additional out-of-the-box integrations with CI/CD and monitoring tools would further enhance the platform's value.
For how long have I used the solution?
I have personally used Split for 12 months or more.
What do I think about the stability of the solution?
Split is stable.
What do I think about the scalability of the solution?
Split scales effectively across team applications and environments. It can support high-volume feature management, enterprise growth, while maintaining reliability, performance, and operational control.
How are customer service and support?
Customer support is responsive and helpful in addressing issues in a timely manner, and the team provides clear guidance for improving implementation and ongoing usage.
Which solution did I use previously and why did I switch?
Yes, we previously evaluated and used solutions such as LaunchDarkly and open-source feature flag tools. We switched to Split because of its strong combination of feature management, experimentation, governance, and analytics in a single platform. Split's controlled rollout capabilities, targeting features, and enterprise-grade controls provided better visibility and helped us manage releases more effectively while reducing deployment risk.
What's my experience with pricing, setup cost, and licensing?
I have used Split for setup, cost, licensing, and pricing.
Which other solutions did I evaluate?
Before choosing Split, I evaluated alternatives such as LaunchDarkly, Optimizely, Statsig, Harness feature flagging like Split, and ConfigCat, as well as Azure App Configuration. Split was attractive because of the combination of features, management, progressive delivery, experimentation, governance, and analytics in a single platform. Enterprise-grade control, auditing, and capability integration with the cloud environment made it a strong fit for managing and scaling software releases.
What other advice do I have?
Out of those features, I rely most on streamlined features such as management and improving release confidence, and support of a more agile development process. I would recommend Split to organizations looking to implement feature flagging and progressive delivery practices at scale.
Split positively impacts my organization as a well-structured organization focused on helping engineering and product teams deliver software more safely through features, platforms, and experimentation. The platform enables controlled feature rollout, reduces deployment risk, supports data-driven decision-making, and provides additional benefits.
Split demonstrates a strong focus on governance and security, which is critical in enterprise software delivery. The platform provides role-based access control, audit, approval workflow, and controls feature rollout, which helps organizations maintain compliance and reduce automation risk. From an artificial intelligence perspective, there is an opportunity to expand intelligent recommendations, anomaly detection, rollout automation, and prediction based on feature performance data. Drive analytics could help my team make faster, more informed release decisions.
Split delivers accurate, reliable feature management capabilities. The platform provides consistent feature flag evaluation, control, rollout, and operational visibility, helping teams deploy changes with greater confidence and reduced risk.
I advise others looking into using Split to start with a clear feature flag, integration, and governance model. Integrate Split into the development monitoring process to maximize the value of the platform. It is useful for teams seeking faster releasing, lower deployment risk, and better control over feature rollout. I rated this product as a 9 out of 10.