Amiato (YC W12) Launches To Bring Big Data A/B Testing With SQL To All(techcrunch.com)
techcrunch.com
Amiato (YC W12) Launches To Bring Big Data A/B Testing With SQL To All
http://techcrunch.com/2013/03/15/backed-with-2m-ycs-amiato-launches-to-bring-big-data-ab-testing-with-sql-to-all/
1 comments
AB Testing involves (1) changing or deploying a new feature, (2) many times measuring new properties linked with the feature, and then (3) analyzing the resulting user behavior. We help in the analysis process because most tools fall short here.
For example, supposed you add more weapons to promote more battles in an online game to keep players engaged. Say, in addition, you start collecting measurements about how long battles take. Suddenly, after introducing the feature, the opposite happens: players leave.
Most off-the-shelf AB tools will only tell you whether feature A or feature B worked (the "what"), but not the "why." It could be that battles are taking longer, so players lose interest without finishing. Or, more battles cause players to die/lose more, so they leave.
We let you ask questions in SQL that will resolve this and find out why. So, you can fix the problem, rather than be left in the dark. You might introduce a feature to shorten battles, or find a way so players don't die so often.
Sophisticated online gaming companies invest in complicated data infrastructure and experts to let you ask those questions (Hadoop, data warehouses, etc.). But, they end up spending days massaging the data --- e.g. to load the new property "time spent in battle" -- before you can ask deep questions. In this case, you may get your answer, but its too late -- you've already lost your players.
We give you direct access to all your event data (including new properties) immediately through SQL. You can ask the deep questions and resolve "why" right away. You're not guessing in the dark as to what to do next.
AB testing is about optimizing the user experience, and we help with the analysis to make better improvements.
For example, supposed you add more weapons to promote more battles in an online game to keep players engaged. Say, in addition, you start collecting measurements about how long battles take. Suddenly, after introducing the feature, the opposite happens: players leave.
Most off-the-shelf AB tools will only tell you whether feature A or feature B worked (the "what"), but not the "why." It could be that battles are taking longer, so players lose interest without finishing. Or, more battles cause players to die/lose more, so they leave.
We let you ask questions in SQL that will resolve this and find out why. So, you can fix the problem, rather than be left in the dark. You might introduce a feature to shorten battles, or find a way so players don't die so often.
Sophisticated online gaming companies invest in complicated data infrastructure and experts to let you ask those questions (Hadoop, data warehouses, etc.). But, they end up spending days massaging the data --- e.g. to load the new property "time spent in battle" -- before you can ask deep questions. In this case, you may get your answer, but its too late -- you've already lost your players.
We give you direct access to all your event data (including new properties) immediately through SQL. You can ask the deep questions and resolve "why" right away. You're not guessing in the dark as to what to do next.
AB testing is about optimizing the user experience, and we help with the analysis to make better improvements.
The "how it works" link says that they get read/write access to the data on s3, they massage/process the data, and allow queries on it. But I'm confused how this helps in A/B testing.