I'm new to using Google Analytics in applications, and I want to have a clear way of distinguishing free users versus paid users of my app.
So far, I'm considering using three different properties to track this (one for overall, one for free only, and one for paid only), however, I get the feeling there may be a better way to do this.
I've been reading over GA categories, which seems interesting and applicable, but I'm not finding much information on them on the net.
Does anyone here have a recommendation for separating free/paid analytics in a clean and concise manner whilst preferably having a good overview of app usage in general?
Set up a custom dimension on a user level (since presumably users won't usally flip between paid and unpaid versions). That way you can set up filters to have different views for paid/unpaid and still have a rollup view that displays values from both versions (for example to see how users behave that eventually upgrade to the paid version).
Related
I've a Free/Donate versions of my opensource application on playstore.The problem currently I'm facing is duplication of work. Because of two different packages, whenever I update my free version, I need to update my donate version. Both versions are exactly the same in functionality perspective and only the packages are different.
I'm thinking of converting the donate application as donate key. But not sure How strategically move all the donate users to free version. Because it's fully functional app.
BTW, the donate user base is around 1000+
Any help would be greatly appreciated ! I'm not sure whether this question can fit in SO. Please feel free to move it to relevant stackexchange.
I would do the reverse.
I'd make the donate version (app B) a free app with in-app purchases for donations (and I'd maintain several donation levels). And I'd mark all the current users as donors. This way, these users (who actually gave you money) don't have to move anywhere (this is what I would expect when I'm a paid user).
And I'd ask the users of the free version (app A) to move to the donate version (app B). I'd just mark the old version (for legacy devices) and I would only give updates to (app B). People who haven't donated anything will understand that they need to migrate to the new app if they want the new features. It's what they'd expect.
The drawback to this is that you'd lose the recorded number of downloads and positive reviews associated with your original free app, which must be pretty significant (although, technically you could keep that app around as an app for legacy devices indefinitely).
I currently have an Android app which is distributed as two applications an Ad supported version and an ad-free version. The Ad-Supported version has over 10,000 users and the Ad-Free version has a couple of hundred. Currently both projects are completely independent making updates a fairly tedious task.
Ideally I would like to just updated one project and build be able to build both versions.
After looking online it seems I have two options:
Make a library containing most of the class files and then just extend this for the two versions (changing only the files that are different). As the project is fairly big this may be a large task and may cause some serious headaches.
Just release one version and use in-app purchases to remove the ads. This seems the easiest route but how do I allow my existing ad-free users to remove the ads via in-app purchase without paying?
Hopefully someone has been in a similar predicament before and can point me in the right direction.
Where I used to work we had the 2nd option. It helped us a lot since you just need to maintain 1 code/app/apk. In your case, I suggest you to do the same thing.
In order to migrate all your users to a single App, you can give a random code (generated with the email they are using and an algorithm to create it) via your "Ad-Free version" app. Then, in your All-in-one app you can ask for that code or activate the "In-App-workflow" in order to remove all Ads.
Edit:
Check this link:
How to get the Android device's primary e-mail address
I am always recommend SO user to used android inapp purchase.
Benefits:
1) Easily track manage your playstore user.
2) If updation require then update code on one place.
3) Secure payment with google policy.
4) many more feature.
#bencallis as per your question i recommend to you option 2 is better.
if you require any inapp information then put comment.
You're in a similar boat with me, though I've taken one step already.
I made an app for a small group of people that are close to me, free and ad-free, and released it. I then created another app for a wider group of people, free but with ads. The two applications were almost the same, except a few things that had to be app-specific (like strings, resources, and a few variables). After getting frustrated with updating both of them, I decided to go with the library approach. It might give you headaches in the beginning, but it will truly cut down on your updating. You'll only have to update the library file, then just compile and check the actual application.
Because of how you describe your situation, I think you'll have an easier time than me. Turn one of your applications (probably the ad-free one) into a library, then in the ad-supported version simply overwrite the layouts that show the ads.
I can't suggest your second option, only because, as far as I know, there is no way to do what you want.
I know it is technically possible to put the same application into the app store with 2 almost identical APKs (different package names and titles), although probably a bit dodgy - I imagine this would not be allowed by Google, but I don't see anything in their Ts & Cs that prohibit this
https://play.google.com/about/developer-distribution-agreement.html
E.g. "My cool app free" And "The awesomest app trial"
Question: Is this allowed?
Reason: A colleague and I were debating the effect of titles and descriptions of downloads (based on different indexes/user searches) and wondering if people ever post a game/app with 2 different ones to see which is more successful
You can if the package name of the app is different, as you said. This is done quite often for apps with trial and paid version. Regarding your question, we have right now around 6 apps in Google Play which are different branded versions of the same app. This means, they have their own package name, splash screen, and some database data, but the app is really the same. So far we didn't get any trouble with Google, so I would say it's possible.
Just for reference, in case you are interested in doing something similar, the best option in terms of maintainability of your app, consists in using an Android library project.
Basically you have one main big project with the "Android Library" option checked in Eclipse. You have all the main code there.
On the other hand, you create two additional projects linked to your library. They will just need their manifest.xml and some activity to call the main activity of the library. Their package names must be different if you want to publish both apps in Google Play.
Additionally, you can override some resources for every project. For instance, you could have a boolean in /res/values indicating whether the project is a trial or paid version, with different values for them. Then, in the library you could check this boolean to show advertisements if it's a trial version.
Another useful thing you can do is using a custom splash screen for every app, by having different image resources in every project with the same name.
As far as I know, it is allowed and certainly has been done in the past (malware masquerading as popular games). Provided the app you're publishing is your own work (and really only the name is different), then I can't see anyone reporting it either.
It is prohibited according to Play Console Developer Program Policy (effective October 21, 2020).
We don't allow apps that merely provide the same experience as other apps already on Google Play. Apps should provide value to users through the creation of unique content or services.
Here are some examples of common violations:
Copying content from other apps without adding any original content or value.
Creating multiple apps with highly similar functionality, content, and user experience. If these apps are each small in content volume, developers should consider creating a single app that aggregates all the content.
I've got a quiz app on the Android market right now selling for $1. I would like to offer a free version with limited questions, and include a menu offering the user to upgrade to the full version.
My question is simply what the best practice is here?
The possibilities I can conceive are:
Have a link in the free version that takes the user to the paid
version's url on the android market, whereby they'd just download the full version directly.
Have condition statements in the free version that limit the
number of questions available if VERSION == FREE, enable all
questions upon purchase by setting VERSION = PAID.
Download the additional questions upon the purchase
(would that require my own file server?)
What are your thoughts?
Can't say there is a best practice between these 3 variants, you should just choose the more appropriate approach for you and your application. First variant is the simplest for you as a developer, second offers a better user experience, but you need to implement In-App Billing in your app. And the third approach is the most difficult cause you'll need a server to store your files on. I'd personally choose the first approach, since the second one has a pitfall - you need the locked questions to be inside your demo version's apk and it's just not secure. The much more secure approach is to not put them in your demo version - this is what the first approach gives you. However, it's your choice as a developer. Good luck!
I have a simple database driven app. I'm looking to offer a free and paid version. The only limitation in the free version, is that you're limited to adding 10 records per month.
What is the best way to handle upgrading from free to paid, while maintaining the database?
I had planned on using in-app billing to unlock the ability to store unlimited records/month but I think that is probably beyond complicated for my simple app.
Other ideas were to sell an unlocker app... I don't know if people get confused by this concept though or not.
I could always write the free db to an sd card and have the paid app copy it. But a concern is people without sd cards and it just seems like something would go wrong and somebody would lose their data.
Any thoughts on this?
If you don't want to use in-app billing then you need two separate packages, free/paid or free/unlocker. IMHO free/unlocker is far more convenient than the free/paid. In you choose free/paid you will end with two copies of the same app and you are going to have problems like the one you mention with the databases.
Android LVL is a no go in this case, you can use it to check licence and enable/disable the 10 records per month restriction, but you are limited to one package (meaning you will have the paid apk in the android market but for the "free" version you need to distrubute the application by your own).
I think PowerAMP offers a good solution. They have a free app that acts as a trial of their product and when the trial period ends, they show a dialog with a link to the unlocker app in the android market. You can use the same strategy, when a user tries to enter more than 10 records/month show them an alert with a link to the unlocker app. I think this should solve your concern about people getting confused.