Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Is there a good alternative for Flurry ?
I use it because it is simple to integrate, but i'm not so happy with the webinterface. I miss the google-analitic-ness, but i dont want to use google.
So, what are your experiences with other analytics for iPhone ?
greets Simon
Edit:
http://www.localytics.com/ Nice GUI, good API
Simon, check out Localytics (I work there). Our service is real-time, our SDKs are open source, there are both free and paid service plans, and we just released a huge update to our web interface. You can access the demo (no registration required) here: https://dashboard.localytics.com/demo
--Brian
AskingPoint.com (I work there and am the founder).
Not free, now starts at 49$ (supports iOS and Android APPS)
Has the following capabilities:
Basic Analytics
Unlimited Named Custom Events with or without data.
Unlimited Timed Events with or without data.
In-App Msgs and Push Notifications
Monetization tools (Ads, Cross Promotion)
A Dashboard.
An embedded Ratings widget that is controlled from your account dashboard, uses your analytics and is translated into 30 languages.
Free Data Export (all data).
Fast and easy integration.
We have an App for viewing your data on the go, and our web interface does NOT use flash so you can alternatively view your dashboard on your iPad or iPhone in a browser... but use our app instead.
We don't and won't sell your data. We are free because we plan on eventually making our money from an opt-in service that we will charge third parties for the revenue from which we will share with the Apps that participated and helped generate it.
There is also HockeyApp. I am comparing Flurry and HockeyApp based solely on grokking their website propaganda, and my summary is that HockeyApp is more "fix-centric", whereas Flurry is more "sales-centric:" Dev & QA would benefit more from HockeyApp's great crash reporting features, and Product Management would benefit more from Flurry's crazy slice-and-dice analytics. Hopefully that helps guide you based on what you are trying to accomplish.
Update: I had a quick chat with the Crittercism dudes and wanted to add my findings. Their offering seems to fill the gap between fix-centric HockeyApp, and sales-centric Flurry. It uses the same underlying PLCrashReporter library to produce robust crash reports like HockeyApp does, and it seems to have more Flurry-like analytics than HockeyApp. Also, pricing ... Flurry is free (though they seem to monetize through advertising on their WWW interface). HockeyApp has pricing based on plans, starting with a $10/month plan. Crittercism prices based on # of active users of your app and you have to work with their sales folks to eek out an actual number.
Also update regarding support: HockeyApp's support is excellent; I've never waited more than 10 minutes to get a response back to my questions and the responses are succinct and accurate. Flurry, about 24 hr turnaround and a fairly unpersonalized and lifeless response that was mostly accurate. Crittercism has been quite fast to respond to my inquires; they have a "Chat Now!" button that put me through to the CTO, which was great for the technical questions I had.
Some key specifics and elaborations:
HockeyApp automatically symbolicates users' crashreports on their web
interface, and can group crashes by crashing API. Flurry does not;
it just shows you a bunch of raw crashes and you get to manually
symbolicate them one instruction at a time (using atos -- you can't
use symbolicatecrash because Flurry doesn't give you a proper
.crash report). Be aware that line numbers in HockeyApp can be off
by one or two lines.
The crash reports that Flurry shows you do not include other running
processes, whereas HockeyApp's do. In fact, it appears that Flurry
crash reports are truncated to 255 characters or so. They are anemic compared to HockeyApp.
For crashes you mark as fixed in HockeyApp's web UI, HockeyApp can
inform a user who subsequently experiences such a crash that the
issue has been fixed in a new version.
Flurry has very deep analytics prowess that HockeyApp cannot touch:
tracking usage stats, customer engagement, average session length,
geographic distribution of your app, user retention over time.
Flurry is free; HockeyApp (free up to 10 apps). Both
provide email support, but only HockeyApp provides a discussion
group. Both can record arbitrary messages (like a JSON response from
the server that caused your app to crash) but only HockeyApp
indicates that this message can be any length.
Alas, these are just a few random tidbits that appealed to my developer-nature and cause me to prefer HockeyApp. I wonder what would happen if I used both in my app!
If you have 7 minutes, HockeyApp has a video walkthrough that I found quite useful.
Cobub Razor is an open source free system like Flurry. And it opens both SDK and web side source codes.
Demo: http://demo.cobub.com/razor/en
GitHub: http://www.github.com/cobub/razor
Mixpanel, I have heard a lot of good thing about their product https://mixpanel.com/
Related
Is there any way to track iPhone app utilisation? I'd like to know every time a user has opened or interacted with my app. I don't want any other information about the user or their device. I don't even need to identify the user. I just want to monitor frequency of use and inactivity.
I thought of possibly creating a unique ID using time in seconds and then writing some code in viewWillAppear that sends an email containing the unique ID. But I don't even know if my App will be approved for sale in the AppStore with this function.
Any suggestions would be welcome - thanks you very much in advance for any effort spent on answering this question...
just use Flurry in you App
Flurry Analytics delivers powerful insight into how consumers interact with your mobile applications in real-time. Over 60,000 companies have chosen Flurry Analytics to use in more than 150,000 applications across iOS, Android, Blackberry, Windows Phone, JavaME and HTML5.
Flurry Analytics helps mobile application developers make better apps, deepen consumer engagement and improve monetization of their applications. The service is free, cross-platform, easy to integrate, able to handle data loads of any size application and frequently updated with new, advanced features.
You can use Google Analytics to track these figures.
https://developers.google.com/analytics/devguides/collection/ios/
I am building an app for a client that will have 30 days of content for free, thereafter you are required to buy a subscription via in app store purchases.
However, I have read that you will get rejected if you have trials.
Don’t set time limits on any of the functionality of your app, either
for run times or life times. Applications that only run for a set
number of minutes per session, or that expire altogether after some
period of time, don’t recruit customers so much as leave a bad taste
in their mouths.
Finally, they also say "your app will be returned to you by the App Review Team for modification if it is found to have time limits".
This seems odd because I know the Guardian and all major newspaper apps have limited functionality.
The Guardian app is free but you get limited functionality?
The Daily app is free, but you have to pay for daily subscriptions
and has limited functionality for the period of your subscription.
The Times app is free, but is a free trial (of sorts) (plenty of
complaints about it)
There are other examples which seem to differ from Apple's policies.
Lets say you have an app that is free, but then you have to pay for subscriptions to gain access; however according to the rules this is considered limited functionality -- yet there are lots of newspaper apps that do exactly that.
I'm confused.
Can someone clarify the situation? Can apps have trials?
Thanks
It is difficult to clarify the situation because unfortunately the guidelines are not necessarily set in stone. They can and do vary on an app and publisher basis.
In the case of The Times and The Daily, both apps are produced by News Corp. It is perhaps safe to say that News Corp has a good deal more influence with Apple than a one-man development shop producing an iPhone game. Apple would be loath to admit it, but there are clear cases of popular apps on the store that don't conform to the guidelines, where they have tacitly made an exception.
So what I would say to you is this: be sensible. Don't have an app that quits automatically when your trial runs out. Think about what would be acceptable to users. It's very much a case of nothing ventured, nothing gained. Take a risk, submit your app with your limited trial, and see what happens.
With the Guardian app, we had to deliver an app where you always got at least some fresh content if you were using the free version. Subscribing opens up more content to the user.
I think, you are mixing up "content" and "functionality".
You can deliver content items (i.e. an magazine issue) for free or user has to pay for it — so the first n issues, or all issues in a certain timeframe, can be free, while the others need to be paid. But if an user purchased an content item before, you have to re-deliver it for free.
You can sell functionalities (i.e a search in the magazine's archive) as-well. But you cannot give it to the user for free for a certain time and them make him pay.
So the general rule is: What ever the user got from you — you cannot take it back from them and make them purchase it again.
There are plenty of free apps which provide limited functionality. They don't provide time limits though (or at least they shouldn't). I'm guessing it won't be as clear cut as accept or reject for Apple, because I did encounter an app which closes itself after 10 minutes, opening a web page to purchase it (closing an app is also against the Apple Human Interface Guidelines, as an app should never terminate itself).
The guidelines mention this is only allowed for specific types of content:
11.9 Apps containing content or services that expire after a limited time will be rejected, except for specific approved content (e.g. films, television programs, music, books)
11.15 Apps may only use auto-renewing subscriptions for periodicals (newspapers, magazines), business Apps (enterprise, productivity, professional creative, cloud storage), and media Apps (video, audio, voice), or the App will be rejected
what are the advantages and disadvantages in using Flurry or Localytics?
I can't answer about iOS, but the Android libraries for Flurry had a very half-baked feel to them when I tried them out about 3 months ago. There's a lot less power in their stats reporting and drilling down through the data can be like pulling teeth.
Additionally, I was getting wildly inaccurate session counts in a small closed beta test of my app (1000 sessions reported in a few minutes from one device). When I contacted Flurry support, it took them nearly a week to get back to me and then all I got was a fairly useless stock response. That alone knocked them straight off my list of potential analytics providers.
I've used Localytics on Android for hundreds of thousands of total installs at this point and am quite happy. Android gets treated as a first-class citizen (rather than feeling like a bolt-on on Flurry or even Google Analytics), and they have a pretty nice looking UI with a lot of good drilldown controls.
Both services are free and both services provide the same basic functionality of providing app analytics (e.g. number of users, type of devices, how the users are interacting with the app, etc.).
I have used both services for Android, although I am currently using Localytics because the Localytics library is open source. The Flurry library is closed source. Open source has the advantage that you can modify the library, as well as see exactly what the library is collecting.
Using flurry in your app you can trace your app, Suppose you want to track that this button pressed how many times ,You can use flurry it shows that in this location this app is used and that button is pressed that number of times.
DISADVantage:- Flurry is very slow it gives you results in 14-15 hours.
ADVANTAGE:- it is free
OTHER :- in place of flurry you can use google analytics(free) and omniture(Paid but give result faster)
you have to register yourself in flurry.com
Both of them store the data in public area. Although the data is so-called privacy, but it's not on your own server.
Flurry is free but provides much less detailed information, and flurry also only accepts up to 10 parameters per event. Localytics makes it easy to sort your data in many ways. For example I can look at all my users for the past week, now I can view users per day, or per hour. Then I can split the data to show me which users that played in the last week started playing the game for the first time, and then I can view that chart scaled to 100%. I could then add a filter so that I'm only looking at data from the users that started on a specific date, or specific week, or even multiple specific dates/weeks/etc. There are only a few things that I'd like from the localytics website that they don't provide, like retention data for days 8-13, or 15-27, or past 28 days, but those things can all be done through SQL queries.
Basically, flurry is free, but basic compared to what you get from localytics. Localytics I believe is free up until 10k MAU (monthly active users). Using localytics over flurry has made a huge difference on the product I'm on, we have been able to make much better decisions based on data.
I finished building an app that allows beaming of photos, contacts and text clips over Wi-Fi
IPhone to IPhone and IPhone to desktop.
I want to decide on the feature set of the lite version of my IPhone app. I also want to come up with a pricing model. So the question is, which of these components should be free, and for which I should be charging for ?
For example, the lite version could have all features except the ability to interact with the desktop version - that is, it would work IPhone to IPhone, but not IPhone to desktop. The paid version would be able to beam to the desktop. In addition, the desktop version would be free, so you could share it with family and friends.
Alternatively, there would be a single free IPhone version and I would charge for the desktop app. The only thing here is that I would have to setup server side code for managing registration codes.
One reason to make your desktop app free and the iPhone app a paid product would be to take advantage of Apple's app store and their payment processing, hosting, etc. While I know 30% seems steep for what Apple provides, it is nice to have that part of the business be handled by someone else. For example, you will never have to deal with credit card processing or have to issue refunds - Apple does all that for you.
I like the mechanism that is more suited to viral distribution and giving people a good taste of all the features, before they are sort of convinced to go for the paid version. The marketing value of an app that can be freely tried out once one user recommends it to another, is invaluable. If someone recommends a product to me and I have to pay for it, then I probably would put off trying it till alter when I have learned more about it. However, if it is free, I can download and try it without feeling like I need to do more research prior. Once I like, and am hooked on it, then I will want locked functionality that I would have to pay to unlock.
I'd stay away from selling, payment processing, and reg code management, if your expertise is in coding - you'd make yourself more money writing more code than writing reg code management utilities...
Good luck.
I'm not sure charging for either is the best idea. If you keep both tools free, you get people trying (and liking) both apps. Viral distribution will ensure a decent user base. Once people use both tools, they're more likely to pay for the next part, which is the connector software.
I like your idea of three parts: a free iPhone app (Let people share photos on their iPhone), free PC app (There are hundreds of photo viewing apps, free... Don't try to charge for them, that way lies pain) and paid connection between 'em.
That way:
You get people using your iPhone app virally (To share with each other's phones & try out the application)
You get people using your PC app virally (Because the cost to try is nearly null)
The connection can be sold through Apple's iStore, so you don't need to do the money handling side
You could even make the connection component a subscription, but as an end user I hate that idea unless I get some additional functionality from it being a subscription (Like free hosting).
If you deploy an application through the iTunes app store, what usage information do you get from Apple? Do you only get the number of downloads/sales, and does this differ for free vs. paid apps? Do you get any information regarding how often it is used, crash logs, demographics info, etc? Is the only way to build hooks to your own server to track this information and would such an app even get approved?
I've seen articles such as this one that includes quotes like:
only about 20 percent of users return to use a free app the day after they first download it and by 30 days out, less than five percent are using the app.
Is that based on surveys, or is it data that comes from Apple? There doesn't appear to be much publicly available data except when Apple shows the top applications, but that is just based downloads or ratings, and nothing deeper.
Most of this information comes from companies like Pinch Media and Admob. They supply libraries you can include in you app which inform their servers of events in your app (specifically launch but also other events decided by you).
They use these events to provide aggregate information on iPhone apps. Several reports have been published recently referencing this data.
You only receive usage information if you somehow program the reporting of such information into your app.
Number of Downloads (Sales if a non-free app) and more recently crash logs are the only information you receive from Apple. you do not even receive personal information about WHO is was that bought your app, only that they did.
You won't get usage statistics from Apple, only download and sales statistics. The reporting is slightly different for free apps(as they won't show up in the financial report), but basically the same information is provided.
You can however track usage information on your own by having your application ping a remote server every time the app is accessed. You can use the unique device id to track a specific user. This will be dependent on internet access for the iPhone/iPod Touch.
Apple does give you how many downloads have occurred as well as what countries they are from. If you want more detailed usage statistics you will have to go to a third party solution, or write it yourself.
Unless Apple is secretly sending usage information when an app is opened, I don't see how anyone can get aggregate statistics about the whole app store. When I upload an app, it is in binary format, and it is probably unlikely that anyone adds in their own code to secretly do this.