|
Its not that there are a lot of analytics products out there, its that most places have a lot of analytics implementations. One of them could do the job, and probably do it well, yet we keep adding more of them. Lets break down why. 1. Product person A, adds your product into the stack and pushes RIGHT UP to the limit you have set.
2. Product person B needs "some new slice of data" but guess what... your 12k annual cost is way more than they want to or need to spend out of their P/L, and their data is going to push the organization over the cap, so they look at a new product. 1. Product person A adds in your product to whatever portion of the platform they are responsible for. it lives in a vacuum there.
2. Product person B comes along and lacks awareness or training on how to use your tool. They can implement another tool, get free training and not have to involved them selves with product person A. 1. Product person A adds your product into the stack, the engineers who implement it find issue with your API/documentation/support.
2. Product person B wants to add your product into the mix, and the ENGINEERS say "were not doing that again find another vendor". All of the above situations create "fragmented" insights. As an example one of my employers used Mixpanel for mobile analytics. They were happy with "real time sales numbers" but the reality of "were not shipping a sub set of those orders" is where the rubber meets the road. Not only does fragmentation make it hard to get real insight but it makes it hard to troubleshoot things as well. You want my data, take it, but take ALL of it. Don't just take the events I want to send you, take the logs, take it from mobile and web, take it from the backend systems, take it from my shippers. Take more than JSON over http, let me open up a socket and give you the fire hose, give me librarys in Go, java, php, python, C*. Give me a set of logging tools that gets you that data quickly. Give engineers a way to send you more context than just the user (process, session, transaction, response time). Give me a way to tell YOU what data to keep "hot" and what data to archive... Just take all the data. If you have it all in one place, your going to make the engineers life easy, the first time some product person runs up and says "conversions are up on our new launch" and wants to take credit for the UI changes, and I can lay a graph of response times over it and say, "well it might be cause the server is faster, and people aren't walking away" your going to not only have my business but everyone else I can convince to adopt your product. |