Since I noticed a misalignment between the count of Users and the count of User IDs on Google Analytics (for mobile apps), I need to understand technically how Google counts Users in mobile apps. While I have extremely clear that on Web Users are counted based on cookies, on mobile app I still have doubts (I never developed a mobile app). I made some research and I'd like to have a confirmation from people who knows it.
I start with this assumption: the metric Users in Firebase / Google Analytics represents the count of the field user_pseudo_id (StackOverflow answer). A comment to this question seems to confirm this assumption, as well as this sentence in the official documentation to set the User ID: "Setting a user ID is never required for Analytics to work correctly. If you're only interested in finding events belonging to the same user for the same app on a single device, you can use the user_pseudo_id. This value is generated automatically by Analytics and is stored within BigQuery for each event."
user_pseudo_id should correspond to the App Instance ID (BigQuery Export Schema). If it's correct, why on the documentation the App Instance ID is referenced as an example? The field allows customizations?
The App Instance ID can change in some cases (device factory reset, app uninstall, data cleared, etc. --> Instance ID API), and that would explain the misalignment.
Since, as mentioned before, I have zero experience in mobile app development, can someone confirm this flow? Is everything correct or am I missing something?
Thanks!
Related
I have developed an android "Group Chat" app. Me and 20 of my friends are using this app to group chat with each other. When I look at the firebase database, I obviously see 21 users (including myself). However, I can't know whether all of them actually have the app installed on their phones, or some of them have uninstalled it. Is there any way I can differentiate among my uses? Generally speaking, can I "flag" my users as, say, active, inactive, and the like?
What is if you add a timestamp every time a use log in. With this timestamp you can see how long the user not log in and so if he is in active for a long time or not. It's not say if the user have delete the app. It's only a prognosis.
If i understand correctly your question, it can be split in two parts.
First part is whether you want to know if your users are online or offline this could be achieved by an online presence system as described here
The second part is whether or not users have installed or uninstalled your app.
In my opinion easiest way to do this is by using the Firebase Analytics SDK. This way you can check the app_remove stats and whenever a user uninstalls an app, it gets updated in the console under events section.
This will give you how many devices uninstalled the app and some info on country, gender and age of the user but you could couple this with a "last login" timestamp to pinpoint the exact user.
More details along with how to include analytics SDK to your app can be found here
Or you can use the .info/connected to have this functionality in your client code. You can read more info about this here and the sample presence app at the bottom of the page will help you get a grip on how to do it.
One possible solution is to add a flag in the database as the child of the user. This flag will have an initial value of active.
And instead of uninstalling the app directly, you can have a delete account functionality in the app, and whenever someone wants to delete his/her account, it simply updates the flag to inactive in firebase database.
Now you will know actually who is active / inactive.
My system consists of a mobile app (a Cordova app), and a webservice, providing all the relevant data. When a user buys the app in the appstore (or playstore, if android), a user account should be created on the webservice, ideally without any user interaction (no registration). The user account could be linked with the gmail account, apple id, ... This is required, to only allow people who have paid to use the webservice.
My Problems:
I did not find a way to get the user id of the user. (Android seems to have a way: https://github.com/loicknuchel/cordova-device-accounts , but iOS not).
I only want exactly one registration per user. This saves me from using something like a registration page, when the app is first started - this could easily be bypassed and lead to multiple registrations.
The user account should be linked to the user and not the device (so no device UUID or so, as this would not be portable between devices).
Ideas that I had:
(Favorite, doesn't seem to be possible) I have a method "getUserID()" in the app, which returns the right user on the phone. Additionally, I have access to an API to check who bought my App. I can easily cross check, to make sure that the user has permission to use the webservice.
(Unnecessary complicated, seems wrong) Make the app free, use a single in-app purchase to buy access to the webservice. When I searched, I found that it seems that in app purchases give you more information, so there might be the chance to link the app with a user.
(Even worse than 2.) Make the app free, use an own payment system/registration.
My question:
What does the Android/iOS app-store eco system provide, so that I can ensure that one user buying the app creates exactly one user account on my webservice, and this user account is linked to the user and not the device?
You should generate a secret api key for each paying user.
Then the user should use this key to auth into your API and get a token back (you can make it expire after some time if you want a stronger protection). User should attach this token to all of his api calls.
Can anyone here tell me if the transfer of ownership of an iOS and Android app will change the URL where the app is accessed. I have a client that had a previous developer publish the application for them, I have advised them that they should get their own developer accounts and then have the apps transferred to them. The only concern they have is that they have printed material out there in the world with QR codes that take you to the app store. So they wanted to know if it will all continue to work.
I do release this might be a bit off topic here.
Thanks guys
Here it says what it will NOT do: https://developer.apple.com/library/ios/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/TransferringAndDeletingApps.html
After an app is transferred, its associated App ID is also transferred
to the recipient’s Member Center account. If the transferor’s App ID
was a wildcard App ID, it’s converted to an explicit App ID that
exactly matches the app’s bundle ID. Associated client SSL
certificates for push notifications aren’t transferred. If the app
uses Apple Push Notifications service (APNs), the recipient needs to
create a client SSL certificate using Member Center to reenable it.
For games, several actions take place depending on whether the app was
associated with any other apps. Apps that are part of a cross-app
Multiplayer Compatibility Matrix are no longer compatible or appear in
the other app’s matrix.
Apps that are part of a Game Center group are removed from the group
during the transfer. After the transfer, all leaderboards and
achievements revert back to their original status. Leaderboards that
were originally a group leaderboard retain the grp. prefix in their
identifier.
Leaderboards that were originally single leaderboards but were merged
into a group lose the grp. prefix. They also revert back to the
original leaderboard IDs they had before the merge. Make sure you
update the app build with the new leaderboard IDs so that scores are
posted correctly.
If you transfer an app that is part of an app bundle, you will no
longer be able to view your app bundle’s history. It is important to
make a record of your app bundle information before you transfer the
app, as you will no longer be able to access the bundle within iTunes
Connect.
If you transfer an app that uses ApplePay, the merchant ID is not
transferred along with the app. Transactions continue to be successful
as long as the original certificates are valid. However, when you
submit an update, the recipient needs to create a new merchant ID on
his or her account
So if even your gameplay scores stay intact. I think the URL will stay the same too.
appID is preserved so yeah, go on.
According to this documentation, Facebook's userID is dependent of the app that requests the userID, i.e., the useriD is different for each app that requests the userID.
My question is the following. Will the userID remain the same for my app when:
My app will be updated on the play store (or apple store)?
A user uses another phone to login to my app via Facebook?
It is not clear to me how I can make sure that the userID will remain the same.
The reason I ask this question is that I would like to provide my users with Facebook auth to my app. However, I need to be able to identified each and every user with a unique identifier (in this case, it would be the userID). User's email or phone number can't be used as unique identifiers as it is not guarantied that users have filled these info on Facebook (even though it is one or the other, I would prefer to have another unique facebook-related identifier of my users).
Maybe I have misunderstood the documentation, in this case, I apologise and thank you for pointing me to the part of the doc that answers my questions.
Regards
It is different for each Facebook app ID. So as long as you use the the same Facebook app ID it will not change.
I have an app that creates an account for a web app, which is basically sending and receiving SMS messages from the web. This is how it works (not released yet, nearing the end of the first-release features I had planned):
The user purchases the app.
The user enters their name, email, and password.
The account is created on the server-end, and the final view is shown telling the user where to access the web app.
The background processes are opened (C2DM and ContentObserver for SMS).
All goes well. The android part of this app all works flawlessly, but I'm scared of people making multiple accounts from one purchase. How could I stop this from happening? I am clueless when it comes to this subject. First of all, when the final view is shown, a user could just hit back and then recreate another account. How can I prevent them from going to that form ever again? I am thinking I can just set a SharedPreference, but then all the user has to do to make another account is uninstall the app and then reinstall it, and bam another account is made.
I need a way, so once the user registers for the first time, there is in no possible way they can register again, on that specific phone (or specific Google account). Is there any real way to accomplish this? Any help is appreciated, I am stuck when it comes to this topic.
Since SIM identification functions (getSimSerialNumber) return null on CDMA devices and *ANDROID_ID* is said to be the same value on CDMA devices; with addition of tablets which do not have either of them, I highly suggest implementing your own unique identifier in your database and matching it with user's Google Account.
However, since a poweruser can always reset their app data storage and clear their identification from device (thus making your app session on device brand new on app launch) this approach has it's caveats.
You may want to check this blogpost for ideas about generating your unique id
http://android-developers.blogspot.com/2011/03/identifying-app-installations.html
I would make it a check on the server side.
Every device has a unique identifier. If you save this on the webserver side during the account creation, you check whether or not an account has already been made on this device. Also add the same check for the Google ID, just in case.
String android_id = Secure.getString(getBaseContext().getContentResolver(),
Secure.ANDROID_ID);
Might be worth a try. Your safest bet will always be something on the server side, since the device side is easily tempered with if people really wanted to.