I'm looking to accurately track users who decide they no longer want receive push notifications from my app OR users who delete the app.
https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/RemoteNotificationsPG/BinaryProviderAPI.html
From Apple documentation here there are some push error codes but none seem to fit clearly with user token removal. A
https://developers.google.com/cloud-messaging/http-server-ref#table9
From the Google docs this following error code seems to be close to what I want.
Error
Unregistered Device
HTTP Code
200 + error:NotRegistered:
Recommended Action
An existing registration token may cease to be valid in a number of scenarios, including:
If the client app unregisters with GCM.
If the client app is automatically unregistered, which can happen if
the user uninstalls the application. For example, on iOS, if the APNS
Feedback Service reported the APNS token as invalid.
If the registration token expires (for example, Google might decide
to refresh registration tokens, or the APNS token has expired for iOS
devices).
If the client app is updated but the new version is not configured to
receive messages.
For all these cases, remove this registration token from the app server and stop using it to send messages.
It seems here there is no way to differentiate between app uninstalls / token removals & token expiration
I already am sure uninstalls can't be track with Apple.
Related
I am not sure what a proper FCM token handling mechanism would be so I’m writing our process down here just to get some validation or suggestions for improvements:
Fetch FCM token on client Login (Flutter)
Save FCM token on our Database (Using our REST API)
Delete FCM token on Logout (Using our REST API)
Q1: Should we be getting the FCM token more often than just on login? AFAIK, FCM token only changes on app re-installs, clearing cache, etc. Does this also include app-updates from the PlayStore? In that case, should we save the FCM token on every app launch since the user will remain logged in after an app update and hence we wouldn't trigger the save FCM call.
Q2: Did I mention the right way to handle deleting FCM tokens from our DB? We don’t want the user to keep getting notifications once they have logged out.
Q3: An add-on idea is to send the device_id to the server along with the fcm_token so that server deletes all previously saved FCM tokens for that device_id. This is useful to not have useless tokens on the DB from cases where the user uninstalls the app without logging out (which means that the DELETE fcm_token call never went through.)
The FCM token is refreshed under conditions that you don't control, and those conditions have even changed over time. To handle token updates properly, you'll need to implement both initially getting the token and then monitoring for token updates.
Note that FCM tokens are not associated with a user. It is fine if you want to associate them with a user, but it's up to your application code in that case to maintain the association. So that for example includes deleting the token from your database when the user signs out, as you're doing in step 3. 👍
For keeping your token registry clean, you can indeed do this proactively as you intend, or reactively as shown here: https://github.com/firebase/functions-samples/blob/master/fcm-notifications/functions/index.js#L76-L88
Hi Rohan fundamentaly you should use below logic to save tokens on server.
Step1:
as soon as you get token in callback whether new or same try to save it localstorage.
Step2:
Call your REST API to save it to your server. it is upto you if you want to send unique user identifier along with the token.
Step3:
It is obvious you will recieve token callback a lot of time so you can check whether you have similar token in localstorage, it means you have the token on the server so no point calling REST API.
Step 4: Now your app can send events back to server and based on it trigger Push notifications to the users.
Step 5: You can Add/update user token based on uniqye user identifier. In some cases a user can be guest user, so your app should generate guest userId and link it with token.
Stay safe.
I'm doing analysis on Firebase Token and understood below points:-
-> A Firebase token is saved in database which will be used for sending notifications.
-> The token generally do not expire except in the following cases:
- The app deletes Instance ID
- The app is restored on a new device
- The user uninstalls/reinstall the app
- The user clears app data.
-> When we use a token which is expired we get errors like Not Registered from the response while sending messages.
-> To avoid the error, we should be deleting the token from database.
However I have found that If we login to a cloud application (which is my app currently), a new fcm token gets generated when i logged in to a new browser say FireFox, Edge etc.
So, the token is generated based on browser or System IP or what exactly the Fcm uses to generate a token ?
The method used to generate the token is an implementation detail, and you should not depend on that to build your app.
A token uniquely identifies a device. Each device receives messages independently of each other, and does not know anything about the user of that device. It's expected that if a user signed into an app on multiple devices, that each device would generate a unique token. If you want to send message to a user, you will have to map each of the user's device tokens in your own database, and send the message to each of them, or only the ones that the user chooses.
You can expect that device tokens might change over time. If you send a message to a device, and the API tells you that the token is not valid, you should simply delete it from your records.
This is the documentation for the error:
The provided registration token is not registered. A previously valid registration token can be unregistered for a variety of reasons, including:
The client app unregistered itself from FCM.
The client app was automatically unregistered. This can happen if the user uninstalls the application or, on iOS, if the APNS Feedback Service reported the APNS token as invalid.
The registration token expired. For example, Google might decide to refresh registration tokens or the APNS token may have expired for iOS devices.
The client app was updated, but the new version is not configured to receive messages.
For all these cases, remove this registration token and stop using it to send messages.
In order to figure out what the error is, I first need to narrow it down to one of the following four reasons. But first I have to understand what they mean.
App Unregistered: What does it mean for an app to unregister? How can I test it?
Invalid APNS token: How can I check this?
Expired token: The tokens are brand new, so this seems unlikely, but how can I validate this?
Not configured to receive messages: It's the same app that's generating these tokens, so what else needs to be done? How can I test this?
Overall, my big question is, how can I test any one of these 4+ circumstances in which this error might be thrown? What can I do to make progress here?
In our app we use Firebase Cloud Messaging to send push notifications to our users. We save the registration tokens of our users in our SQL database and when a user logs in or out we use the Firebase API to manage his topic subscriptions.
This works out pretty well in most of the cases but now the topic subscriptions return the following error for some of our registration tokens:
The provided registration token is not registered. A previously valid registration token can be unregistered for a variety of reasons. See the error documentation for more details. Remove this registration token and stop using it to send messages
In which cases does Firebase delete previously registered registration tokens? I can not find any specific information about this in the error documentation.
Thanks for your help!
From the documentation:
A previously valid registration token can be unregistered for a variety of reasons, including:
The client app unregistered itself from FCM.
The client app was automatically unregistered. This can happen if the user uninstalls the application or, on iOS, if the APNS Feedback
Service reported the APNS token as invalid.
The registration token expired. For example, Google might decide to refresh registration tokens or the APNS token may have expired for
iOS devices.
The client app was updated, but the new version is not configured to receive messages.
A single user can have multiple devices connected to his account.
Because of that he can have multiple cloud messaging tokens.
Everytime the user opens the app the token from that device is send to the app server and saved there.
What happens if a user uninstalls the app from one of his devices? I have no chance to tell the server that the token is not longer in use.
Can it occure that I notify an other user instead since this other user has acquired the not longer used token from the original user?
What happens if a user uninstalls the app from one of his devices?
Usually, when your app is uninstalled, it is advisable for you (the developer) to automatically make sure that the corresponding registration token is deleted from your own App Server.
Can it occure that I notify an other user instead since this other user has acquired the not longer used token from the original user?
No. Each registration token is unique per each app instance. So rest assured that if a registration token is invalidated/expires for whatever reason, no other user will be able to use it. Sending a message to an invalid/expired registration token will result to a NotRegistered error.
Tokens are not re-used so there should be no risk of notifying another user. Tokens cannot be acquired by one user from another.