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.
Related
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
I'll soon have to implement the StoreKit functionality and I was wondering...
is there a way to also offer a product for free to a user once, like as a gift for using the app for the first time ?
In my special scenario I'll offer several products in my educational app, which the user will need to buy time by time, if he is interested in continuing to learn with the app.
But the first product I want the user to have for free and it should be his choice which one he takes. So generally all products should have a price, but the first download shall be free.
And I want this to get logged on my server so I can reidentify him, so (A) he can't delete the app, reinstall and download yet another free product and (B) so he will also get the products on any other of his devices.
I'm also open to workarounds, like maybe get something similar to the apple id or so, to be able to store it on the server. I know that I could also use the [[UIDevice currentDevice] uniqueIdentifier], but I want the user to have this first free product on all his devices, and ONLY ONE.
Is there a way to get (A) and (B)?
Apple's In-App Purchase infrastructure (and by extension, StoreKit) does not support free content.
But there's nothing stopping you from providing free content via your own mechanisms, as you surmise. You would have to do all the tracking yourself in terms of remembering device IDs on a server somewhere, and noting that device != user, so would miss some edge cases.
You don't get access to (iTunes) user data at all, so you probably can't guarantee the "only once" across multiple devices, unless your app has an associated backend service account that is already unique per user.
(Before building infrastructure for this, you should double-check the developer agreement/contracts on this stuff. You're not circumventing Apple's revenue stream here, which is good, but what you're talking about may be unusual enough to raise a flag with them in terms of experience consistency if nothing else.)
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 am new to iphone stuff. After deploying an application in iTunes is there a way to find out the number of iphone/ipod touch which has installed / uninstalled this application ?
During uninstall the user is asked to rate the application, how to get that information with a developer license credentials ?
Apple tells you the number of sales (and the number of upgrades) in iTunes Connect. What they don't tell you is how many people have uninstalled your application or, more importantly, how many people are still using it n days after installing it.
You may be able to get this information (and more) using one of the third party analytic tools such as Flurry, although Apple has recently started to object to service like them. Another option would be to gather the same kind of information on your own server.
It would be really nice if Apple provided better information but, unfortunately, they don't at the moment.
All this data is provided through Apples iTunes connect site
https://itunesconnect.apple.com
Additionally you could subscribe to one of the support sites like
http://www.appfigures.com
which will give you nice graphs on sales etc
You should also take a look at Flurry Analytic's. Not only will it tell you how many unique devices it has been installed on, but you can add events as well. So lets say your app has a "Featured Listings" area or something like that. Flurry will log how many times people enter into the "Featured" area. It will help track conversion rates...
Also shows you the navigation path the user took. So they click on , "search", then they click on "homes", then they clicked on "featured"... yada yada yada... it provides excellent information.
If your app uses Core Location you can even see a dot on a map as to where the user was when they did all of this.
http://www.flurry.com/
-LT
The information provided by iTunes Connect is the number of downloads of your app. The ratings and reviews are actually not provided via iTunes Connect, but you can find it indirectly on the app store.
There are some services that aggregate all this information for you. A new one is www.appannie.com which shows you both downloads and ratings.
For number of installed Apple just updated https://itunesconnect.apple.com site you can adjust the date range in the middle of screen (using the slider) or by adjusting the dates on top left corner after navigating to sale and trends screen to see how many downloads you have had.
Regarding In App Purchases, I can find a lot of information on all the technicalities of actually making purchases and interacting with the store (how to retrieve product information, verify receipts, etc), but I can't seem to find information on guidelines or special instructions for preparing the actual "apps" or "components," whatever they're to be considered, which will act as the In App Purchases.
For instance, once a component is downloaded into an app, where does it exist in the overall architecture of the app? How do they combine to join forces? How do they know about one another. If I have a game, and using In App Purchases I allow users to both download new levels, but also download new game play modes that can affect any of the built-in or downloaded levels, how do I prepare all of these assets so that they integrate?
I'm not looking for a tutorial, per se, but would love to know if anyone has had experience with In App Purchases or knows of a useful reference besides Apple's In App Purchase programming guide which only speaks to the specifics of making the actual download transaction.
The things you download aren't really "apps", they're just data files like anything else your app can download.
Sometimes, they're not really that, they're just effective "switches", i.e. all of the functionality and data is there in your code already, but it's just protected by a line of code like
if (user has purchased extra levels)
add extra items to menu/list
You aren't allowed to download new executable code; I admit I'm not sure how carefully Apple works to prevent you from downloading scripts that control your program's behavior, since it would be very difficult for them to tell what is intrinsic to your original app or not.
In my own programs, I've put the control logic and tables into the main application, and separated out big resource files into a separate ZIP file. When the user buys the add-on pack, they do download that ZIP file of images which keeps the original application size down, and the program just uses those images out of the documents directory instead of the application bundle like it would if they were built in.
I am using the Urban Airship in-app purchase support, which insulates you from running your own server or learning most details of the StoreKit, at the cost of a slice of your revenue.
You can let the levels be in the app from the beginning and just let them become available when the user pays an in-app level. This is by far the most simple solution.
If you want to have downloadable levels you will need to set up an own server that will deliver and check correct purchase transactions with apples servers. You will also need to create all the download and architecture to load and use these levels into your app.
But, you can have a look here http://urbanairship.com/in-app-purchase/ for help in creating downloadable items.
This code will get you going: works on the simulator too: https://github.com/boxerab/InAppPurchase