I have an android app with some activities. My question is:
Is that legal to use different AdMob ids for each because it will help me to monitor which activities are more frequently visited. Moreover, i also want different content of ads in each activity.
Thanks
IANAL but why would you use Admob to track which Activities are the most used in your app? Besides, since they issue just the one publisher ID for each app you configure on the Admob platform, I am sure they have a pretty good reason for it. Also, if you have, say, 20 Activities, you would essentially be registering 20 apps (non existent apps in the real sense). Not sure if that's a good idea either. But you might want a lawyer to clarify that for you if that is your primary concern and you have already decided that this is the best way to go about it.
Alternatively, if the only purpose is track which Activities are most used in your app, consider using the Android Native Application Tracking SDK. You can download it off their website here or from the SDK Manager from Eclipse. In The SDK Manager, it is under the Extras section titled Google Analytics App Tracking SDK
This is the Dev Guide that will help you get started with it: https://developers.google.com/analytics/devguides/collection/android/v2/
EDIT:
As pointed out by user908821 in his comment, you should also take a look at the Analytics SDK Policy.
There is nothing illegal with using a different AdmobId for different spots within your app. And if each Activity has certain distinct characteristics that make it more useful to a certain portion of your users then it may help to segment traffic and provide better eCPM.
But I would not be doing it just to track users. Use an analytics tools to do that.
Related
What's the best way to set up Google Analytics to track one app on multiple platforms (e.g. Android, iOS).
The app is very similar on all the platforms, so we'd like to view activity in aggregate, but also have the ability to cut by key values such at platform, user state (signed in, signed out etc)
Also, what's the best way to track a unique instance of the app (as a user)? Is there some way to create a unique ID on install that stays in all tracking calls for the lifetime of the install?
Thanks!
What I did is make a list of what I want to track and name them the same thing in both apps. The code in the app will be different from android to iOS.
But for the analytics part just use one project in the google dev console. Then add both app to the project like the docs say. you will have to follow the steps in the google documentation. But just keep it in the same project and then both devices types will be in the same project and you won't have to juggle two projects at the same time.
It works great doing it like that
Currently, I'm looking to see if there is a way to sync the information we've obtained through an online site with the information we use on a phone application.
All I need to know is that the user that visited our site is the same user that is using our phone application, No stats and preferably no one needs to enter a thing.
You won't get that from Apple, because of their history with privacy concerns, but you could do something like generate an identifying number in your app, that your web site asks for, that would tie the two together. Of course, you'd have to make allowances if your app is deleted from the device, then re-installed, to either make sure you're generating the same number, or other such solution as befits your requirements.
The first thing that would come to my mind is Google Analytics, available for different platforms and services (i.e. Youtube, etc). You would have to go through Google Analytics API to figure out a way on how to track a particular customer visit across several location/platforms.
See Hello Analytics example of Google Analytics API
See Data Feed API
Ok, so far I've answered my own question for androids. Apparently you can pass a referrer param through google play which actually allows your app to receive the parameter and they even have an app that test this functionality.
https://play.google.com/store/apps/details?id=net.stevemiller.android.referrertest
now I have yet to test this, nor is it a possible solution for iOS.
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 been training myself up in Android development. I have an idea for a series of apps that all relate to the same basic data store which stores similar/related hobby data. I suppose in my mind access to this data should be similar to how many apps make use contacts. So I started reading up on content providers but from what I can see they don't actually provide the flexibility I require.
What I want is to create say 4 or 5 hobby related apps that record similar and related data however a customer might decide they only need a specific one to start with. Later they might decide that one or more of the other apps might also be useful.
The data the apps store is very similar, the core data is the same. So the obvious choice is a content provider. However I can't see the providers offer the flexibility I require. Firstly how does the 2nd app purchased figure out that a content provider is already available and if so not install its own (this seems to be hardwired in the manifest and there is no programatic control). Secondly how would an app realise there is no content provider and install one (related to point one). Thirdly a new app installed might have a more up to date provider or an older provider!
So I don't think the providers offer what I need. I also notice that the databases are sandboxed and providers seem to be the only method for apps to share persisted data, or is there something I'm missing. It actually makes me wonder how for none default installed content providers how useful providers are!
I suppose an alternative method would be for a customer to purchase and app and then later ad on extra functionality but I'm not sure if this is possible and if so where the information is.
Any help would be appreciated.
Steve
Note to moderators: at first I thought I'd consider this an argumentative question, but now that I think again I think it's a design problem. A good one that shall stay here.
The data the apps store is very similar, the core data is the same. So the obvious choice is a content provider.
Yes.
Firstly how does the 2nd app purchased figure out that a content provider is already available and if so not install its own (this seems to be hardwired in the manifest and there is no programatic control). Secondly how would an app realise there is no content provider and install one (related to point one). Thirdly a new app installed might have a more up to date provider or an older provider!
Many apps do this by having a "library app" available in the Market that provides the common functionality that other apps from you may need. You should ask the user, in any of those apps, to download that library app to enable the underlying functionality of the "UI apps". I don't know, maybe I would take that route... after all, you need to consider the namespace conflict of your content provider(s), hence the "library app".
I suppose an alternative method would be for a customer to purchase and app and then later ad on extra functionality but I'm not sure if this is possible and if so where the information is.
Yes, that's what the in-app billing is for. However, that assumes you'd have one app with different features.
Truth is, it's a good question. It certainly caught me thinking. I believe it's up to you to provide one app featuring a suite of features added by in-app billing, or many apps that share a common functionality provided by one central app also available in the market.
About this last problem, I would do what feels more natural do the user. If the apps are really unrelated, subject-wise, I'd provide different apps. If it's a suite-like product (think Office suites, for example), I'd implement in-app purchases. There is also a small security issue regarding the code visibility (enabling by software versus per-download).
Anyway, in-app purchases are definitely simpler and easier to maintain, in my opinion. But if your apps are that big, it could be a waste of space... not efficient.
My 2 cents.