Is this really a problem crying out for a solution? The justification felt a bit forced to me. My only experience is integrating with Mixpanel from Scala. I wrote the following in an evening:<p><a href="https://gist.github.com/4598180.git" rel="nofollow">https://gist.github.com/4598180.git</a><p>Seriously, it wasn't a big deal. Maybe I'm spoiled by using Scala/Play -- the web client is asynchronous so the analytics calls aren't blocking the controller.<p>I'm far more annoyed that I get very little useful analysis from my analytics. That is, to me, a much more interesting and useful problem to solve.
There are probably some value-adds you can do here, besides convenience for developers. For example, you could save your users money by doing some creative aggregation of data points (assuming these services charge by volume) before sending them off. Or you can try to detect low-value data points and let your users filter them out (like hits from bots). Or you can do sampling so that only 1 out of every x data points goes through. Yeah, in-house developers could code this up too, and it might completely kill the value of the analytics service by not sending all data, but who has the time to investigate these types of things?<p>Also, since switching analytics providers becomes very easy for your users, you can try to leverage this fact and get a kickback from analytics providers that you help convert your users to. You could, theoretically, reduce the friction of moving to another provider to near zero (no development / integration cost, no data-lock in if your users let you store historic logs that you could replay to another provider, etc). That would result in much more competitive pricing from the analytics providers.<p>edit: yeah, these random thoughts mostly apply to the server side stuff. just throwing them out there.
I can completely relate to this, it might be anecdotal, (Java isn't as popular for web development these days as it used to be), but server side analytics using Mixpanel in Java for example was pretty hard from a non Android app,
I ended up building something myself to circumvent the issue (<a href="https://github.com/eranation/mixpanel-java" rel="nofollow">https://github.com/eranation/mixpanel-java</a>) but I have to give credit to mixpanel for responding to emails quickly, picking it up, creating their own Java API and kindly linking to mine and another mixpanel Scala based API from their support pages.
Still I wouldn't have had to even think doing it if I knew segment.io probably, nice job, will give it a go.
Impressive range of libraries provided and the documentation is quite good.<p>Seems a little strange that the benefits are touted of using the libraries over setting up a dedicated queue service when the libraries rely on in memory queues. While the loss of the tracking data, should these queues fail, may not be worth the hassle of maintaining the dedicated infrastructure, there is a critical difference between the two approaches. These libraries are much more likely to impact application (or the servers the applications are running on) performance then queuing a message on another server.
From a random "Show HN" a few weeks ago to what seems like a polished company that's been around for years, I just wanted to say you guys are absolutely killing it (and making a joke of all the dev power that probably went into Google's own inferior Tag Manager).
Awesome stuff guys! We're very excited about adding SnowPlow support into analytics.js - expect a pull request soon :-)<p>Does adding support for SnowPlow into analytics.js get us "server-side support" for free, or is there anything else we have to do too?
Very glad you guys are doing this. I love Mixpanel but maintaining analytics calls via JS was a royal pain. This way, we can use your apis to do all the tracking and their front-end for all the slicing. Perfect!
I don't really need or want to use multiple analytics services, at the moment. I currently use frontend analytics with mixpanel to track funnels and whatnot. What is the benefit to instrumenting backend code over frontend?
It seems so strange to read these issues about blocking IO and the complicated ways to 'resolve' them (introduce an AMQP broker? really?) when you're used to asynchronicity.<p>I'm used to writing in Twisted. Okay, so I fire up something, and I get a deferred. I'm not waiting for it to complete before I can do other things. None of this queuing nonsense.<p>At the same time, I've heard tons of people complain about how async-everywhere complicates everything. Either they don't know what they're talking about, or it just complicates everything else (or the truth is somewhere in the middle).
Segment.io guys, an aside from your blog post, which was actually quite good... Both your site and your blog are almost unusable on an iPhone. I know a lot of people (like me!) like browsing HN and blogs on their phone, and fixing layout CSS isn't too big of a project, so just a little heads up.