Was looking at the default metrics within iTunes Connect today. Clicked on the question mark icon at the top of the page next to the About App Analytics Data title to see what the current Opt-In rate is and it says (emphasis added by me):
We only show data from users who have agreed to share their diagnostics and usage information with app developers. In the last 30 days, 545% of users that installed "The App" agreed to share their data.
How is that even possible?! And would the be skewing the analytics data?
I assume that if it says I have 100,000 Sessions but the Opt-In rate is 500%, that would mean that maybe I only actually have 20,000 Sessions...?
Perhaps the .greater.than. 100% Opt-In rate is resolved in the current App Store Connect. For example, 29%.
Related
I have currently an app that through in-app purchases a user can unlock content on the app. What I have noticed is that some users "abuse" of this by logging with their Apple ID in multiple devices and I'm currently looking into possibilities on how to limit the use of the content to the device where the purchase was done. I understand that Apple doesn't allow that, so that means the payment system should go away from the app.
Therefore, introducing logging will help me to be able to identify the person that is using the app against a backend but still, I need to be able to limit on a device. As far as I know, the UUIDString of the CurrentDevice is not really a way anymore. What other options are?
I saw this library, which seems to promise unique identification:
https://github.com/fabiocaccamo/FCUUID
Another solution probably would be to create a licensing system, so one license can only be used at the time.
Thanks!
I will describe our experience with using same account on different devices (VOD):
User is able to use application on how many devices he want, but he able to watch content only on 5 uniq devices.
Each time user try to watch content, app check if device registered with some UUID, if not then try to register. UUID is uniq per installation, it mean that if user will watch content, then delete app, download again and watch, then he basically lose 1 device.
In same time user able to unregister device via web, but he had only like 25 unregistrations (I don't know what happened if user use them all).
We don't use in-app purchases and accounts are cross-platform (android, iOS, web, tvs, etc), so not sure if it helps you.
AFAIK, Apple does not have limit on how many devices you can user Apple Id. You can have 6 family members so number of devices could be lot more.
I feel it is bias how Apple's guideline talks about limiting music, movies, shows and books to 10 devices but does not say anything about Apps!
Apple - Family Sharing
If your family has purchase sharing turned on, music, movies, TV shows, and books can be downloaded on up to 10 devices per account, five of which can be computers.
I have not seen any application limiting IAP on devices. You could run into risk of Apple rejecting your app, potentially on every update you submit. I would reach out to App Store or if your company have Sales rep contact and get their suggestions/buy-in before spending lot of time and money.
Also, create issue/radar and give specifics about issue. More people request this feature, has better chances of it getting added.
One way you can achieve this is to keep track of receipt you get for IAP and check how many users/devices using that receipt. You would need to build entire flow to educate user about device limitations. Like updating App Store page, warning before purchasing, option to add/remove device and more...
If you are planning to implement device limitation, please beware of the rejection risk.
As opposed to Google Play Console, I can't find a way to check the amount of app sales being made in real time. I am not a patient person so I'd like to be able to check this information multiple times throughout the day.
At the moment, I track my website's performance with Google Analytics so I can see how many people visit the app's manual compared to the amount of people who did the same thing 7 days ago. However, this value can vary up to 40% while having the same amount of app sales so it's not a very good indicator.
The app is dependent on a very small footprint so including a framework that tracks usage statistics would be overkill. I only need a way to get notified how many people have opened this app today. Have you implemented this somewhere in your own projects? Or is there even a section for that in iTunesConnect?
You could log an event with Google Analytics called "App Opened" or something where the label is the identifierForVendor. Another option is to create an UUID and store it in UserDefaults, and use that as the label.
By checking the number of events with a unique label you could see the amount of installs.
This wouldn't require you to add a new framework or to implement anything else.
Trying to follow instructions here:
https://developers.google.com/games/services/console/enabling#step_3_generate_an_oauth_20_client_id
There is a long description of how to generate fingerprints, but this never happened for me... it just said
'Successfully linked your Client ID'
XXXXXXXXXXXXXXX-XXXXXXXXXXXXXXXX.apps.googleusercontent.com
'You only need to include the application ID (1098532227899) in your Android app. '
I did that, I'm testing and I can't connect. Do I have to get it as an alpha release through the store to test? I'm listed as a tester, but when I send the invitation I get
'App not available for this account'
If I send myself a signed release APK is that the same as getting it through the store?
Based from this blog, there are certain reasons why you encounter the App not available for this account error. It might be:
Country restriction. The developer can specify application availability for each country and if on the Google Play you will see a clear message about that - on this page, it will look like “App not available for this account”. The best thing which you can do in this case is to ask developers to the associated Google+ community to add your country to the list.
Testers limit. The developer can also specify a maximum amount of beta testers which means that if this limit is 1000 testers, you won’t be able to get an access to this page. I will look like “App not available for this account” either. You can try to contact developers in this case too.
Time delay. Sometimes, even if you joined Google+ community you will see “App not available for this account” just because it may take up to 4 hours (according to the google documentation) before an application will become available for your account. In this case, I would suggest checking this OPT-IN url after some time, according to my experience it usually takes less than 15 minutes.
You may check this SO post for reference: Beta testing: App not appearing in Play Store Beta tab
I want to offer a free trial and the option to BUY (Non-Consumable In-App Purchase) on my ios app. I can see that I can offer a trial and then SUBSCRIBE (Auto-Renewable Subscription), but I personally don't like having to pay over and over for a simple app, but I do want to try it first. Is there a way to achieve the same thing when setting the option to buy? I realize I could track the first usage after download, but this presents a couple of issues:
Will Apple now approve apps for a trial period - previously they have been rejected, but that was before IAP and subscribe was available at all!
How do I prevent the user deleting the app (and any data I might store to know they have activated a trial) and then downloading again?
Or do I have to succumb to the pernicious "subscribe" model or release a "light" version with an upgrade? The last time I went "light", Apple insisted I make so much functionality available, I may well have not bothered with the full version - but that was a while ago.
Apple now allows you to add a free trial for Non-Subscription apps. It's a 0 price plan for fixed days. After this trial expires, you can show the non-subscription plan for purchase. The downside is user need to do a purchase again after trials end. But offering a free trial is a good user experience.
Non-subscription apps may offer a free time-based trial period before
presenting a full unlock option by setting up a Non-Consumable IAP
item at Price Tier 0 that follows the naming convention: "14-day
Trial." Prior to the start of the trial, your app must clearly
identify its duration, the content or services that will no longer be
accessible when the trial ends, and any downstream charges the user
would need to pay for full functionality.
Dont prevent the user from deleting the app. Just store the data online when user hits the trial button, you can store a flag in the web services which can be zero or one based on the user.
One way you could do this if you only care about iOS 11 is using the new DeviceCheck API. It's pretty limited in functionality (it lets you track 2 bits, or 4 cases, total) but should persist between install.
i am developing an iDevice chat application. The user of this application can use it free for 1 week, but after the trial period is over, the user needs to make an in-app purchase for $1.99 to continue using the app, or it will be disabled. Does Apple accept such a condition, and if so how do I implement it? Please help.
Thanks!
Apple will not accept it. App Store Review Guidelines state that:
Apps containing "rental" content or services that expire after a limited time are not permitted
Apps that are "beta", "demo", "trial", or "test" versions are not permitted
Based on your description, the app will be a trial one after expiration, so it will become unusable, which is not allowed.
In order to avoid the app to be rejected for the reasons above, you should provide for the app at least a minimum functionality after the trial period expires. E.g. you can offer unlimited chat messages by IAP and, for people that don't unlock this feature, you can offer a maximum of 10 or so messages per day, or intermix messages with ads.