We currently have about 10,000 android devices of those 10,000. About 8,800 of those devices are running Android 7.1.1. On two of the eight applications installed on these devices, we decided to use firebase analytics to be able to collect useful data about how users are using our applications.
Upon looking at the data that was collected in the first week. App_open, a number of events that are being logged from the device. The results did not seem reflective of our user base.
The number of users who had information being logged was roughly about 800 users.
Its should be noted that we do not use the google play store to release and update our application and use the device manufacturer's store to upload and update the applications on these devices.
I know that the information that is collected or logged from the device is cached and posted by google play services.
However, I cannot seem to find a reason why there is such a great disparity in actual and expected results. I was expecting feedback from roughly 8,800 devices.
There are few reasons:
10k devices doesn't mean that they use your app, according to this article apps have in average 29% retention rate within 90 days but it can be much lower(from my experience it can be less then 2%), so in fact at least 70% of users not using your app.
The users that use your app doesn't updated to latest version with analytics.
Also you need to keep in mind that 800 users some of them are new users that just downloaded the app, firebase analytics show all the statistics so in few weeks you will see your retention rate.
Related
we have a business where we have developed an android platform in 1,000 devices inside taxis.
For this, we need to login 1,000x into play store.
We have used one account so far (test#gmail.com) but it seems that often it automatically logs out on many devices, even though it should permanently be logged in, to receive software updates.
We currently tried to log in around 80 devices, but about 40 of them get logged out of Play Store.
Is the issue that we can't login multiple devices with 1 account or what can be the problem?
Are we able to use one account and keep them logged in on all devices?
From Google Play Terms of Service
Limits on access on Devices. Google may from time to time place limits
on the number of Devices and/or software applications you may use to
access Content (for more information, please visit the Help link for
the relevant Content within Google Play). Google may record and store
the unique device identifier numbers of your Devices in order to
enforce such limits.
I would like to be able to receive notifications, when I receive a negative rating with a review on my Google Play Store account. Have any of you tried this and do you know how this can be done?
So far, the only interesting thing I have found are Alerts, but those seem to only be interested in the number of times my applications has been installed and uninstalled. Maybe there is a way that I could get alerts customized?
On your Google Play Developer Console, you can currently receive 4 types of app alerts:
Crashes
Installs
Average rating. The Average Rating of your app has significantly decreased compared to the previous week. If the Average Rating has decreased in a specific country, language, or on specific device, additional details may be mentioned in the alert.
Uninstalls.
Reference: https://support.google.com/googleplay/android-developer/answer/3433208
I want to make a mobile app where users need to purchase licence every year to continue using it. Once they buy it from the app store/market they will get a one year subscription plus 10 POINTS credit which they need for a specific part of the app. Whenever they want to use that specific part of the app, they must have enough points. Otherwise, they may top up.
Is that possible in iTunes, Google Play and BlackBerry App World? I mean can I have annual subscription and top up features in one app.
And, can the unused points be carried over next subscription? In case the licence is over but not the credits!
It sounds like you need both subscription and one-off purchase revenue models. The subscription model is fairly simple to implement, and can be implemented without adding much code to your app. Your users will be charged a regular (monthly/yearly) fee to use your app.
The points/credits model will require you to keep track of the user's points balance inside your app. You can set up virtual goods on the various stores which the user can purchase in order to get more points e.g.
10 points - $0.99
30 points - $1.99
You may also need to think about how users can transfer their balance to a new phone if they change devices. (Note: This is mandatory on the BlackBerry platform, can't advise on the others).
Both of these revenue models are supported on the BlackBerry, Android and iOS platforms. Docs here: iOS, Android, BlackBerry.
I am in the process of integrating In-App Billing in my application for unmanaged products. I've configured my application in the market already to implement the BILLING permission. I've published the product ids as expected by my in-development version of my application. I've used test products so far, but for quality assurance have been trying to test with real products, charging to an AMEX card as well as personal VISA/Mastercard cards.
When I have a transaction go through, everything in my application works without a hitch. I'm even confirming all of the notification ids, so no problems there.
Throughout the process though, I have run into an issue where there is an inability to purchase the products.
The Market application responds to the user with a dialog with text
"Purchase canceled
Your payment could not be processed. Sign in to your Google Wallet account to request support."
This issue is seen on 2 Galaxy Nexus 4G devices as well as an HTC Sensation 4G. The issue occurs on WiFi, 3G, and 4G networks. The accounts purchasing initially receive an "Order receipt" email, followed by an "Order cancellation" email. The order receipt email properly includes the full information for the transaction including product name, cost, order number, date, etc. The order cancellation also includes all of this information and describes the reason for cancellation as, "Took too long to deliver". The application gets a broadcast of a purchase state change at this time, which is the cancelation of the transaction.
Any insight into what's happening and why I'm having all of my transactions fail to complete?
Through email feedback from an Android Developer Advocate, I have confirmed that this is a risk/settlement issue.
Full response from him:
Dallas,
I'm sorry to hear that you've been having difficulty getting adequate support for this issue. My apologies.
The issue you describe is currently a known issue. Your assessment was correct when you said that this was a settlement/risk issue.
Specifically, these users are being flagged by Google Checkout as being in a "risk bin" by our automated systems. These users' orders are temporarily delayed while we manually investigate the account. In the majority of cases, the orders are released for processing within 24 hours without problem.
In-app billing is a special case, as all in-app billing orders are subject to a 45 second processing timeout. (This was based on feedback from several prominent app developers.) Unfortunately, this means that any user who is placed into a risk bin will have their order canceled. Attempting the purchase again 24 hours later should work correctly.
In particular, all the orders mentioned in your bug report are from the same user, whose account is currently listed as "On Hold" while a risk review is completed. (Note that accounts used for developer testing are much more likely to get flagged for risk review, as they tend to display anomalous purchasing patterns.)
Again, the Market team is aware of this issue and is actively working on improving the customer experience.
Thanks for your patience.
Apparently, this is a Google Issue. Please check this link for more info:
http://groups.google.com/group/android-developers/browse_thread/thread/66e26d87a7226000?pli=1
I developed a remote app where the user has to provide an ethernet ID for the target device.
For users who have two of these devices I would like to give the possibility to install the app twice, one for each device.
But they should not have to pay for the second one (eg just selling the same app with different package-names might not even be accepted by Apple, while on Android it is possible)
Designing the app in such a way that it works with two devices would make it quite complex to use.
Is there a good workable solution for this for iPhone and/or Android?
Many thanks
From an iPhone perspective, this wouldn't be possible. Selling the app with different package names is a very poor solution for a number of reasons:
As you say, it wouldn't be accepted by the App Store (and would probably be eventually removed from the Android Market if it is just a duplicate app).
You have no control over which version of the app people download, and then need to keep track of this, which is overly complex.
2 versions of the app would be acceptable if the user has 2 devices, but what if they have 3? What if they had 10?
To me, this would seem like an issue that would be solved by some sort of severside registration server which links up to some logic within the app in order to determine whether the user has made the necessary payment in order to use the app.
In other words -- and if I am understanding the concept of your app correctly (more explanation would be needed for a more complete answer) -- the user goes onto your site (or within the app) and creates an account, registering their Ethernet ID(s) and arranging any payment (or does this via in-app purchase). You could even charge on a per-device basis and have this built in to the app via in-app purchasing.
So the app itself would be free, but in order to use the app they would need an account which has been registered with you in order to ensure it is only being used by paid users.
Not sure exactly what you trying to build but there are other apps (games & tools) have a client and a server app.
Usually people give the client app away for free, but charge for the server app.
Another way, you could do in-app billing so give the app away for free, but charge for the features in the app to unlock it.
Implement your own registration server that keeps track of registered/licensed devices a user has.
That would you would know that a user has bought the required upgrade that can be used with his/her registration on x number of devices.
Each device the user downloads the app onto and logs into their account.
The app could check check if they have purchased the licence on at least one of their devices, thus unlocking the features.
Not definitive, but those are the two ways I would look into if I were developing such an application
Any iOS app from the App store can already be installed on multiple devices, as many as are logged into to the same iTunes customer account. The customer only pays once for one to as many installs as they have devices on that same account.