

Alternatives for mobile app analytics - rogerbinns

Does anyone have good suggestions for mobile application analytics (Android and iOS)?  The product I am working on is a library that gets integrated into existing applications.  As such our usage of analytics must coexist with separate unrelated analytics use in the app.<p>Google Analytics works well and the reporting interface is fairly easy to navigate and find out the information you want.  Some parts of the interface are bizarre though.  They have two problems.  On Android the library only supports one tracker instance and reporting so we can't report our events at the same time as the rest of the app reports its events.  The second is that for numerical values (custom variables) the only thing they report is the average value which is spectacularly useless.  I need to see the distribution of values.  Talking to their support would appear to require forking out $150,000 a year before they will take the call.<p>I've also tried Mixpanel but had numerous issues with their Android library and server side.  It has no builtin reports so you have to compose queries yourself, and even simple slicing and dicing data is a pain.  I've had to write code to import all our data locally and then do analysis there to get reports like the pre-existing ones in Google Analytics.  (I've been unable to get any issue addressed by their support.)<p>There is a conflict of interest with Flurry (in particular all the stuff they do other than analytics).<p>A solution hosted by someone else is preferable rather than self hosting due to the expected ramp up in volume of traffic.  Searches turn up numerous analytics providers, but they all have web sites as their primary focus using a chunk of Javascript as the library.  While there isn't that much difference in the events generated from a mobile app compared to a web site, there is a need for a robust Android and iOS library and for additional values to be tacked onto events, plus being able to use those values in reports and analysis.  We also need to be able to partition data so that third parties can look at a subset of it that belongs to their app.
======
bsuthoff
I work at Localytics (www.localytics.com) and suggest you give us a try -- and
we already work with other app libraries like yours.

Our solution is built for apps analytics, our SDKs are open source (go
directly to the SDK: <http://www.localytics.com/docs/>), there's no
advertising conflict of interest, and there are both free and upgraded plans
available depending on your needs. More details and a full demo are available
on our website.

~~~
rogerbinns
The Android library looks good. One of your competitors doesn't include a
license (which technically means every customer is violating copyright law) or
a way of determining the version (so it isn't possible to tell if the copy of
the library is out of date).

It is only mentioned at the bottom of the FAQ, but being able to grant viewing
permissions for specific apps is important to us.

Is there any specific reason why you require creating yet another user account
with yet another username and yet another password? I'd much rather be able to
use my existing Google credentials.

------
friendstock
What about Apsalar? But.. I've only used Flurry...

Just curious -- what's the conflict of interest?

~~~
rogerbinns
I'll have a look into Apsalar - thanks for the suggestion. (They also do my
pet peeve of requiring you to sign up with yet another account and yet another
password to see any useful information. Why do so many sites insist on this
nonsense if all a developer wants to see is what the API looks like?)

The conflict of interest in those cases is that in addition to analytics they
provide "monetization" (basically adverts). If the app is using a different ad
network then we would be giving a competitor ad network detailed analytics
about the app and its usage.

------
sunnynagra
You can try out TestFlight.

~~~
rogerbinns
They only do iOS. We also need Android. I also don't need the vast majority of
their functionality, which would bloat our resulting library size. There is
also a conflict of interest with their corporate overlords (Burstly).

Thanks for the suggestion.

