Si vous utilisez les API FCM pour créer des requêtes d'envoi de manière programmatique, vous constaterez peut-être qu'au fil du temps, vous gaspillez des ressources en envoyant des messages à des appareils inactifs avec des jetons d'enregistrement obsolètes. Cette situation peut affecter les données de distribution des messages signalées dans la console Firebaseou les données exportées vers BigQuery, en affichant une baisse spectaculaire (mais en réalité non valide) des taux de distribution. Ce guide présente certaines mesures que vous pouvez prendre pour garantir un ciblage efficace des messages et des rapports de distribution valides.
Jetons d'enregistrement obsolètes et expirés
Les jetons d'enregistrement obsolètes sont des jetons associés à des appareils inactifs qui ne se sont pas connectés à FCM depuis plus d'un mois. Au fil du temps, il devient de moins en moins probable que l'appareil se connecte à nouveau à FCM Les envois de messages et les diffusions de sujets pour ces jetons obsolètes ne seront probablement jamais distribués.
Un jeton peut devenir obsolète pour plusieurs raisons. Par exemple, l'appareil auquel le jeton est associé peut être perdu, détruit ou mis en stockage et oublié.
Pour Android, lorsque les jetons obsolètes atteignent 270 jours d'inactivité, FCM les considère comme expirés. Une fois qu'un jeton expire, FCM le marque comme non valide et refuse les envois. Toutefois, FCM émet un nouveau jeton pour l'instance d'application dans le cas rare où l'appareil se reconnecte et où l'application est ouverte.
Pour d'autres plates-formes comme iOS, FCM s'appuie sur le service push sous-jacent (par exemple, APNs), qui n'a pas la même expiration de jeton basée sur l'inactivité de 270 jours. Nous vous recommandons donc de maintenir de manière proactive la fraîcheur des jetons et de supprimer les jetons d'enregistrement obsolètes.
Bonnes pratiques de base
Vous devez suivre certaines pratiques fondamentales dans toute application qui utilise FCM API pour créer des requêtes d'envoi de manière programmatique. Voici les principales bonnes pratiques :
- Récupérez les jetons d'enregistrement depuis FCM et stockez-les sur votre serveur. Le serveur a pour rôle important de suivre le jeton de chaque client et de tenir à jour une liste de jetons actifs. Nous vous recommandons vivement d'implémenter un code temporel de jeton dans votre code et vos serveurs, et de le mettre à jour à intervalles réguliers.
- Maintenez la fraîcheur des jetons et supprimez les jetons obsolètes. En plus de supprimer les jetons que FCM ne considère plus comme valides, vous pouvez surveiller d'autres signes indiquant que les jetons sont devenus obsolètes et les supprimer de manière proactive. Ce guide présente certaines options pour y parvenir.
Récupérer et stocker des jetons d'enregistrement
Au démarrage initial de votre application, le FCM SDK génère un jeton d'enregistrement pour l'instance d'application cliente. Il s'agit du jeton que vous devez inclure dans les requêtes d'envoi ciblées de l'API ou ajouter aux abonnements aux sujets pour cibler les sujets.
Nous vous recommandons vivement de récupérer ce jeton au démarrage initial et de l'enregistrer sur le serveur de votre application avec un code temporel. Ce code temporel doit être implémenté par votre code et vos serveurs, car il n'est pas fourni par FCM SDK.
Il est également important d'enregistrer le jeton sur le serveur et de mettre à jour le code temporel chaque fois qu'il change, par exemple lorsque :
- l'application est restaurée sur un nouvel appareil ;
- l'utilisateur désinstalle ou réinstalle l'application ;
- l'utilisateur efface les données de l'application ;
- l'application redevient active après que FCM a expiré son jeton existant .
Exemple : stocker des jetons et des codes temporels dans Cloud Firestore
Par exemple, vous pouvez utiliser Cloud Firestore pour stocker des jetons dans une collection
appelée fcmTokens. Chaque ID de document de la collection correspond à un ID utilisateur, et le document stocke le jeton d'enregistrement actuel et son code temporel de dernière mise à jour. Utilisez la fonction set comme indiqué dans cet exemple Kotlin :
/**
* Persist token to third-party servers.
*
* Modify this method to associate the user's FCM registration token with any server-side account
* maintained by your application.
*
* @param token The new token.
*/
private fun sendTokenToServer(token: String?) {
// If you're running your own server, call API to send token and today's date for the user
// Example shown below with Firestore
// Add token and timestamp to Firestore for this user
val deviceToken = hashMapOf(
"token" to token,
"timestamp" to FieldValue.serverTimestamp(),
)
// Get user ID from Firebase Auth or your own server
Firebase.firestore.collection("fcmTokens").document("myuserid")
.set(deviceToken)
}
Chaque fois qu'un jeton est récupéré, il est stocké dans Cloud Firestore en appelant
sendTokenToServer :
/**
* Called if the FCM registration token is updated. This may occur if the security of
* the previous token had been compromised. Note that this is called when the
* FCM registration token is initially generated so this is where you would retrieve the token.
*/
override fun onNewToken(token: String) {
Log.d(TAG, "Refreshed token: $token")
// If you want to send messages to this application instance or
// manage this apps subscriptions on the server side, send the
// FCM registration token to your app server.
sendTokenToServer(token)
}
var token = Firebase.messaging.token.await()
// Check whether the retrieved token matches the one on your server for this user's device
val preferences = this.getPreferences(Context.MODE_PRIVATE)
val tokenStored = preferences.getString("deviceToken", "")
lifecycleScope.launch {
if (tokenStored == "" || tokenStored != token)
{
// If you have your own server, call API to send the above token and Date() for this user's device
// Example shown below with Firestore
// Add token and timestamp to Firestore for this user
val deviceToken = hashMapOf(
"token" to token,
"timestamp" to FieldValue.serverTimestamp(),
)
// Get user ID from Firebase Auth or your own server
Firebase.firestore.collection("fcmTokens").document("myuserid")
.set(deviceToken).await()
}
}
Maintenir la fraîcheur des jetons et supprimer les jetons obsolètes
Il n'est pas toujours facile de déterminer si un jeton est récent ou obsolète. Pour couvrir tous les cas, vous devez adopter un seuil à partir duquel vous considérez les jetons comme obsolètes. Par défaut, FCM considère qu'un jeton est obsolète si son instance d'application ne s'est pas connectée depuis un mois. Tout jeton datant de plus d'un mois est susceptible d'être un appareil inactif. Un appareil actif aurait actualisé son jeton.
Selon votre cas d'utilisation, un mois peut être trop court ou trop long. C'est donc à vous de déterminer les critères qui vous conviennent.
Détecter les réponses de jeton non valides du backend FCM
Veillez à détecter les réponses de jeton non valides de FCM et à répondre en supprimant de votre système tous les jetons d'enregistrement connus comme non valides ou expirés. Avec l'API HTTP v1, ces messages d'erreur peuvent indiquer que votre requête d'envoi ciblait des jetons non valides ou expirés :
UNREGISTERED(HTTP 404)INVALID_ARGUMENT(HTTP 400)
Si vous êtes certain que la charge utile du message est valide et que vous recevez l'une de ces réponses pour un jeton ciblé, vous pouvez supprimer votre enregistrement de ce jeton, car il ne sera plus jamais valide. Par exemple, pour supprimer les jetons non valides de Cloud Firestore, vous pouvez déployer et exécuter une fonction comme celle-ci :
// Registration token comes from the client FCM SDKs
const registrationToken = 'YOUR_REGISTRATION_TOKEN';
const message = {
data: {
// Information you want to send inside of notification
},
token: registrationToken
};
// Send message to device with provided registration token
getMessaging().send(message)
.then((response) => {
// Response is a message ID string.
})
.catch((error) => {
// Delete token for user if error code is UNREGISTERED or INVALID_ARGUMENT.
if (error.errorCode == "messaging/registration-token-not-registered") {
// If you're running your own server, call API to delete the
token for the user
// Example shown below with Firestore
// Get user ID from Firebase Auth or your own server
Firebase.firestore.collection("fcmTokens").document(user.uid).delete()
}
});
FCM renvoie une réponse de jeton non valide si un jeton pour un appareil Android a expiré après 270 jours d'inactivité ou si un client s'est explicitement désinscrit. Si vous devez suivre plus précisément l'obsolescence selon vos propres définitions, vous pouvez supprimer de manière proactive les jetons d'enregistrement obsolètes.
Mettre à jour les jetons régulièrement
Nous vous recommandons de récupérer et de mettre à jour régulièrement tous les jetons d'enregistrement sur votre serveur. Pour cela, vous devez :
- ajouter une logique d'application dans votre application cliente pour récupérer le jeton actuel à l'aide de l'
appel d'API approprié (tel que
token(completion):pour les plates-formes Apple ougetToken()pour Android), puis envoyer le jeton actuel au serveur de votre application pour le stockage (avec un code temporel). Il peut s'agir d'une tâche mensuelle configurée pour couvrir tous les clients ou jetons. - ajouter une logique de serveur pour mettre à jour le code temporel du jeton à intervalles réguliers, que le jeton ait changé ou non.
Pour obtenir un exemple de logique Android permettant de mettre à jour les jetons à l'aide de WorkManager, consultez Gérer les jetons Cloud Messaging sur le blog Firebase.
Quel que soit le modèle de timing que vous suivez, veillez à mettre à jour les jetons régulièrement. Une fréquence de mise à jour d'une fois par mois constitue un bon équilibre entre l'impact sur la batterie et la détection des jetons d'enregistrement inactifs. En effectuant cette actualisation, vous vous assurez également que tout appareil qui devient inactif actualise son enregistrement lorsqu'il redevient actif. Il n'est pas utile d'effectuer l'actualisation plus d'une fois par semaine.
Supprimer les jetons d'enregistrement obsolètes
Avant d'envoyer des messages à un appareil, assurez-vous que le code temporel du jeton d'enregistrement de l'appareil se trouve dans votre période d'obsolescence. Par exemple, vous
pouvez implémenter Cloud Functions for Firebase afin d'exécuter une vérification quotidienne pour vous assurer que le
code temporel se trouve dans une période d'obsolescence définie, telle que const
EXPIRATION_TIME = 1000 * 60 * 60 * 24 * 30;, puis supprimer les jetons obsolètes :
exports.pruneTokens = functions.pubsub.schedule('every 24 hours').onRun(async (context) => {
// Get all documents where the timestamp exceeds is not within the past month
const staleTokensResult = await admin.firestore().collection('fcmTokens')
.where("timestamp", "<", Date.now() - EXPIRATION_TIME)
.get();
// Delete devices with stale tokens
staleTokensResult.forEach(function(doc) { doc.ref.delete(); });
});
Désabonner les jetons obsolètes des sujets
Si vous utilisez des sujets, vous pouvez également désinscrire les jetons obsolètes des sujets auxquels ils sont abonnés. Cela implique deux étapes :
- Votre application doit se réabonner aux sujets une fois par mois et chaque fois que le jeton d'enregistrement change. Cela constitue une solution d'autoréparation, où les abonnements réapparaissent automatiquement lorsqu'une application redevient active.
- Si une instance d'application est inactive pendant un mois (ou votre propre période d'obsolescence), vous devez la désabonner des sujets à l'aide du SDK d'administration Firebase pour supprimer le mappage jeton-sujet du backend FCM.
L'avantage de ces deux étapes est que vos diffusions ramifiées se produiront plus rapidement, car il y aura moins de jetons obsolètes à distribuer, et vos instances d'application obsolètes se réabonneront automatiquement une fois qu'elles seront à nouveau actives.
Mesurer la réussite de la distribution
Pour obtenir une image plus précise de la distribution des messages, il est préférable d'envoyer des messages uniquement aux instances d'application activement utilisées. Cela est particulièrement important si vous envoyez régulièrement des messages à des sujets avec un grand nombre d'abonnés. Si une partie de ces abonnés sont en fait inactifs, l'impact sur vos statistiques de distribution peut être important au fil du temps.
Avant de cibler des messages sur un jeton, tenez compte des points suivants :
- Google Analytics, les données capturées dans BigQuery ou d'autres signaux de suivi indiquent-ils que le jeton est actif ?
- Les tentatives de distribution précédentes ont-elles échoué de manière cohérente sur une période donnée ?
- Le jeton d'enregistrement a-t-il été mis à jour sur vos serveurs au cours du mois dernier ?
- Pour les appareils Android, l'API de données FCM
signale-t-elle un pourcentage élevé d'échecs de distribution de messages en raison de
droppedDeviceInactive?
Pour en savoir plus sur la distribution, consultez Comprendre la distribution des messages.