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?
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.