Bonnes pratiques pour l'efficacité des extractions Remote Config

Firebase Remote Config vous permet de contrôler de manière flexible le comportement et l'apparence de votre application. Cela permet d'activer des fonctionnalités telles que le déploiement de fonctionnalités et les tests A/B multiplates-formes pour vos applications, le tout sans déployer de nouvelles versions ni gérer plusieurs mises à jour de plates-formes de téléchargement d'applications.

Que vous prototypiez, que vous gériez une start-up en pleine croissance ou que vous gériez une application d'entreprise à grande échelle, la gestion du volume de récupération du réseau est essentielle pour offrir une expérience utilisateur rapide et réactive. Une gestion efficace de la configuration réduit la latence de démarrage à froid, économise les données client et l'utilisation de la batterie, et évite les frais généraux réseau inutiles. De plus, si votre base d'utilisateurs s'étend rapidement et que l'utilisation augmente à l'avenir, la simplification de votre intégration Remote Config vous aidera à maintenir une utilisation efficace.

Vous pouvez réduire considérablement le trafic de requêtes réseau côté client en affinant la façon dont et le moment où les applications récupèrent les paramètres et les activent.

Passer au modèle "fetch for next session" (récupérer pour la prochaine session)

Un schéma courant à éviter consiste à utiliser l'appel fetchAndActivate, qui récupère de nouvelles valeurs sur le réseau et les active, à chaque lancement de l'application, combiné à une courte période d'expiration du cache pour les valeurs précédemment récupérées (par exemple, 15 minutes à une heure). Le modèle mental derrière cette approche est que chaque fois qu'un utilisateur ouvre l'application, les dernières valeurs récupérées et appliquées sont toujours disponibles. Bien qu'une mise à jour immédiate soit parfois nécessaire (par exemple, pour une campagne de promotion ou de soldes quotidiennes), il est important de trouver un équilibre entre cet objectif et l'impact sur les performances et l'utilisation de la récupération de votre application.

Cette approche force de nouveaux appels réseau chaque fois que le cache expire, ce qui génère un volume de récupération élevé pour les utilisateurs qui ouvrent l'application plusieurs fois par jour.

Envisagez plutôt d'utiliser les appels fetch et activate séparément avec un intervalle de récupération minimal plus élevé pour adopter un modèle de "récupération pour la prochaine session". Vous pouvez toujours utiliser fetchAndActivate avec un intervalle de récupération minimal plus élevé, car fetch n'exécute une requête réseau que si le cache est invalidé. Toutefois, l'utilisation des deux appels séparément permet de consolider le modèle et de l'établir comme pratique standard dans votre processus de développement d'applications. De plus, en activant les valeurs de configuration séparément, vous ne risquez pas de les appliquer en cours de session et de perturber l'expérience utilisateur.

Fonctionnement de cette approche

  • Activer immédiatement au lancement : appliquez instantanément les configurations mises en cache de la session précédente (0 ms de latence réseau).
  • Récupérer en arrière-plan avec un cache plus long (par exemple, plus de 12 ou 24 heures) : demandez des configurations mises à jour de manière asynchrone pour actualiser le cache local pour la prochaine session.

Comment cela optimise-t-il le volume de récupération ?

Un intervalle de récupération minimal plus long entraîne moins de demandes de récupération. Récupérer de nouvelles valeurs pour la prochaine session et activer les valeurs mises en cache pour la session actuelle signifie que votre application se charge instantanément à partir du cache local sur une période de validation plus longue, ce qui améliore l'expérience utilisateur.

Par exemple, si vous définissez minimumFetchInterval sur 24 heures et qu'un utilisateur ouvre votre application 5 ou 10 fois en une seule journée, le SDK satisfait automatiquement les lancements 2 à 10 directement à partir du cache local, ce qui réduit le nombre de requêtes réseau quotidiennes de cet utilisateur de 10 récupérations ou plus à 1.

Les exemples suivants montrent à quoi ressemble cette implémentation pour les applications Android, les plates-formes Apple et les applications Web :

Android

val remoteConfig = Firebase.remoteConfig

// Set a 24-hour minimum fetch interval (86,400 seconds)
val configSettings = remoteConfigSettings {
    minimumFetchIntervalInSeconds = 86400
}
remoteConfig.setConfigSettingsAsync(configSettings)

// 1. Instantly activate values cached from the LAST session
remoteConfig.activate().addOnCompleteListener {
    applyAppConfigurations()
}

// 2. Fetch new values in the background for the NEXT session
remoteConfig.fetch().addOnCompleteListener { task ->
    if (task.isSuccessful) {
        // Optional: Activate values if needed
    }
}

iOS+

let remoteConfig = RemoteConfig.remoteConfig()

// Set a 24-hour minimum fetch interval (86,400 seconds)
let settings = RemoteConfigSettings()
settings.minimumFetchInterval = 86400
remoteConfig.configSettings = settings

// 1. Instantly activate values cached from the LAST session
remoteConfig.activate { changed, error in
    guard error == nil else { return }
    DispatchQueue.main.async {
        self.applyAppConfigurations()
    }
}

// 2. Fetch new values in the background for the NEXT session
remoteConfig.fetch { status, error in
    if status == .success {
        // Optional: Activate values if needed
    }
}

Web

import { getRemoteConfig, fetchConfig, activate } from "firebase/remote-config";

const remoteConfig = getRemoteConfig(app);

// Set a 24-hour minimum fetch interval (86,400,000 ms)
remoteConfig.settings.minimumFetchIntervalMillis = 86400000;

// 1. Instantly activate values cached from the LAST session
activate(remoteConfig).then(() => {
    applyAppConfigurations();
});

// 2. Fetch new values in the background for the NEXT session
fetchConfig(remoteConfig).then(() => {
    // Optional: Activate values if needed
});

Implémenter la récupération "intelligente" conditionnelle

Si le modèle "fetch for next session" introduit trop de latence entre le moment où vous devez mettre à jour les valeurs Remote Config et le moment où elles deviennent disponibles dans vos applications clientes, envisagez d'adopter la récupération "intelligente" conditionnelle.

Pour implémenter cela efficacement, évitez d'associer des déclencheurs fetch à des hooks de cycle de vie d'UI généraux, par exemple chaque fois qu'un écran se charge, qu'un onglet change ou qu'une vue est sélectionnée.

Au lieu de cela, déclenchez les requêtes de récupération de manière sélective en fonction des actions ou des états explicites de l'application, par exemple :

  • Événements de connexion des utilisateurs
  • Transition vers des parcours utilisateur spécifiques où vos paramètres sont utilisés (par exemple, entrer dans un entonnoir de paiement ou passer au niveau supérieur dans un jeu)

À l'inverse, évitez de déclencher des requêtes d'extraction pour des actions de routine telles que :

  • Lorsqu'un utilisateur ouvre l'application ou démarre une nouvelle session
  • Lorsque l'application passe de l'arrière-plan au premier plan et inversement

Étapes suivantes