Split Reviews

I have used Split to perform AB tests, controlled releases, and measure business outcomes. While my focus has been on analytics and the decision-making side, I have also used this platform for administrative purposes and worked closely with teams that use Split to evaluate experiments, assess the impacts of new features, and refine strategies.

My primary use case for Split has been experimentation and feature validation, where I used it to run AB tests and controlled rollouts to measure the impacts of new features, such as recommendation strategies and decisioning approaches, before wider deployment. From an analytics perspective, I have used Split to compare treatment and control groups separately, track business metrics, and determine whether a change delivered meaningful improvements in customer engagement or drove conversions and other business outcomes. Split helped us make data-driven decisions while minimizing risks associated with large-scale releases.

My main use case involved conversion projects, and another benefit was the enabled collaboration between business analytics and engineering teams. There was significant collaboration as all teams worked from the same experimentation framework and aligned on success metrics prior to implementing changes. Split facilitated a culture of data-driven decision-making, allowing us to validate our ideas and providing measurable outcomes for decisions. This increased stakeholder confidence and helped prioritize various initiatives, demonstrating the business impact it delivered in my use case.

Using Split for experimentation and feature validation noticeably improved outcomes. Before using Split, experimentation was too manual, relying heavily on custom implementations and separate processes for deployment and testing, which slowed down our experiments and increased manual effort. With Split, feature rollout and experimentation became streamlined, allowing us to control exposure to new features through feature flags. We could easily create treatment and control groups and adjust rollout percentages based on performance, leading to a structured approach to evaluating experiments and connecting results to business metrics. One of the biggest advantages was reducing risk, as we could validate performance with a smaller audience before scaling to a wider user base, improving our speed and confidence in the release process.

The best features that Split offers include data-driven decision-making, feature flagging, controlled rollouts, and experimentation capabilities. I would highlight feature flagging, as it allowed our team to separate deployment from release, thereby reducing risk and granting us greater control over how and when new functionalities are exposed to users. The experimentation capabilities, especially the ability to create treatment and control groups and measure the impact of changes against clearly defined business metrics, helped us make informed decisions. Finally, I appreciated the visibility around feature releases, which improved transparency and collaboration between teams.

I feel that overall my experience with Split has been positive regarding necessary improvements, particularly around user experience and enhancements to the user interface, especially for larger teams. As experimentation programs grow, users must navigate many feature flags and different environments, so making discovery, organization, and lifecycle management more intuitive would be beneficial. While Split integrates well with many tools, additional connectivity with analytics and BI reporting platforms could provide a more seamless experience for organizations.

There are areas where Split can be improved, particularly around advanced reporting and visualization capabilities. While the platform manages experiments and feature rollouts effectively, having more robust, out-of-the-box reporting options would allow business stakeholders to interpret results without relying on external tools. Additionally, as organizations grow, managing and overseeing feature flags becomes more challenging, so enhancing governance capabilities would be beneficial.

In terms of user experience and integrations, I think the platform could enhance those areas as well. Users often need to navigate through a large number of feature flags as experimentation programs scale, so improvements to the user interface that simplify discovery, organization, and lifecycle management would be valuable, especially for larger teams. While Split integrates effectively with many tools, increasing connectivity with analytics and BI reporting could help organizations enhance their operations.

I have been using Split for around two years, with my primary exposure being through experimentation and feature rollout initiatives.

I find Split to be quite stable and a reliable platform, having not experienced major outages or significant downtimes that affected our experimentation activities. Occasional maintenance or issues are typical for any enterprise platform, though they have not disrupted our day-to-day work.

Split is capable of handling growing workloads and numerous experiments as our team expands. It supports the increase in the number of experiments and feature flags without becoming a bottleneck, which is one reason we opted for a more structured experimentation platform like Split. Overall, I find the platform to be highly scalable and well-suited for growing experimentation programs.

I have reached out to customer support several times, primarily regarding experimentation and analytics rather than platform administration. Based on those interactions, I found the support to be generally responsive and helpful, resolving most issues in a reasonable timeframe. However, I believe there remains an opportunity to enhance overall support experience, particularly in onboarding guidance and best practice recommendations.

Before Split, we typically managed experimentation and rollout activities manually, relying on a combination of internal tools and coordination across different teams. I did not migrate from a competing platform to Split; rather, I transitioned from a manual process to a more scalable experimentation framework with Split.

Although I was not involved in calculating formal ROI after implementing Split, I have observed benefits in productivity and efficiency. One noticeable outcome is the reduction in the time required to launch, manage, and validate experiments, with the experimentation cycle becoming approximately 20 to 30 percent faster. It did not reduce the number of employees needed, but it enabled the teams to use their time more effectively, and Split's ability to validate changes with smaller groups before broader rollouts helped reduce risk.

My advice for others considering Split is to begin with a clear strategy rather than just focusing on the technology. Split is a strong platform, but organizations gain the most value from it when they have well-defined objectives and success metrics, along with processes for evaluating results. I also recommend establishing governance around feature flags and experimentation early on to manage scalability as adoption grows. Overall, Split is an excellent recommendation for organizations looking to build a data-driven culture and integrate experimentation into decision-making. I would rate my overall experience with Split an 8 out of 10.

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.

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.

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.

I have been using Split for about two years now.

Split is stable.

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.

We haven't encountered any significant issues with customer support, but we did have one or two minor issues, and they were pretty reachable.

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.

My main use case for Split is feature flags. For example, if we have a new feature that we want to roll out for a particular region of users, such as enabling a particular feature for European users but not for Asian users, we use Split to enable it for the users in Europe and turn it off for the users in Asia. With a single release, we are able to do this because we use the Split dashboard for enabling and disabling it. This streamlines the process, allowing us to use a single Split feature flag instead of multiple if-else statements, turning it on and off depending on different regions.

Another use case for Split that I had at Eventbrite involves using it along with Statsig for gaining marketing insights. We had separate feature flags enabled for different sets of users, such as set A, set B, and set C, checking how users react to different types of UI changes. This way, we were able to gain insights about which UI performs the best among the three and roll out that UI. Split and Statsig provided valuable insights and analytics about our changes.

I have been using Split for the last three years, mostly for my personal projects, and at Eventbrite, we also use it for the event dashboard and multiple other features. Every time we have to break the features into different groups or want to turn on or off the feature flags based on different groups, we use feature flags using Split.

The UI analytics is definitely one of the best features of Split. By running experiments on two different sets of users, we can determine which UI or feature is working best or gaining more traction. We segregate the UI feature into different segments under feature flags, enabling us to analyze how well each feature is performing, helping us plan major releases based on these analytics. Split has positively impacted my organization by improving both developer experience and customer experience. Before Split, we used if-else clauses to display different UIs for customers from different regions, which resulted in a complex structure. After Split, we avoid extensive if-else statements and instead use a single feature flag for rendering the UI, improving the developer experience by saving time and maintaining cleaner code. For customer experience, if a rolled-out feature encounters issues, we can simply turn off the feature flag in the dashboard, allowing our application to remain stable instead of causing issues that affect our company's reputation. One of the best features that Split offers is feature flags. We specifically use feature flags for rolling out features regionally, which makes it essential for our use cases.

Currently, I have not found any significant improvements needed for Split, though the dashboard could be more interactive. Initially, I had difficulty finding analytics and understanding setup. This learning curve is something the documentation could improve, particularly regarding analytics setup.

Regarding improvements, while I believe there are cheaper options available, I think Split is an organization-level software, so I will not comment extensively on pricing. For integrations, I felt that the documentation for analytics integration was not as well-documented. It would be beneficial for users if Split focused on improving analytics-related documentation and creating a more interactive analytics dashboard.

I have already mentioned the necessary improvements concerning analytics, and I do not have anything else to add on that front.

I have been using Split for the last three years.

Split is stable in my experience.

Split's scalability is good. I have not encountered any issues with scaling up or down.

I have not interacted with customer support, but I have had brief interactions with some Split employees on LinkedIn, and they were good.

I do not have information on whether we previously used a different solution because we began using Split from the start of our work with feature flags.

I believe it is pretty easy to set up Split and integrate it into our application, which is a React application. The documentation is streamlined online, and there are many tutorials available on how to use Split, so it is pretty easy.

I am not sure if we purchased Split through the AWS Marketplace, as this was managed at the organizational level.

The time saved per feature is a significant metric for us. On both developer and customer sides, we are saving around three to six hours per feature or more than one week of development work per quarter if we consider releasing three to four features.

I was not involved in the pricing aspects of Split, but I have read that there are cheaper options available. I have not been involved in the setup cost or licensing matters, but I can say that the setup process is easy, as indicated by the documentation, and licensing has been fine as we have used it across teams.

I have not evaluated other options for using Split, as a senior engineer provided information about it, and we adopted it without researching alternatives.

My advice for others considering Split is to start using it and go through the documentation while setting up feature flags. Setting up analytics correctly is vital since you will be able to understand how your features are performing effectively. Design your features to benefit from this analytics approach. I believe Split is a good product overall. I would rate this review an eight out of ten.

The main objective of our project was to have a dynamic config with Split without doing a deployment. Split helped us by allowing us to call the Split APIs and fetch the configs on the fly.

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.

The UI of split.io can be improved.

I have used it while I was working on a project for approximately two or three months.

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.