Aperçu

L'API Google Health est une nouvelle API entièrement repensée qui permet aux développeurs d'interroger les données utilisateur Fitbit. Il ne s'agit pas d'une simple mise à jour, mais d'une décision stratégique visant à garantir que vos applications sont sécurisées, fiables et prêtes pour les futures avancées de la technologie de santé. L'API est compatible avec une nouvelle console pour enregistrer vos applications, avec Google OAuth 2.0, avec de nouveaux types de données, avec un nouveau schéma de point de terminaison et avec un nouveau format de réponse.

Ce guide est conçu pour aider les développeurs à migrer leurs applications Fitbit Web API existantes vers la nouvelle API Google Health.

Pourquoi migrer ?

Voici les avantages de l'utilisation de l'API Google Health :

  • Sécurité renforcée : respect des bonnes pratiques de Google en matière de sécurité, conformément aux normes de Google en matière de sécurité, de confidentialité et d'identité.
  • Cohérence : élimine les incohérences héritées dans les formats de données, les fuseaux horaires, les unités de mesure et la gestion des exceptions pour une expérience de développement plus intuitive.
  • Évolutivité et pérennité : conçu pour évoluer afin de répondre aux besoins futurs et compatible avec les protocoles modernes tels que gRPC.

Migrer vos utilisateurs

La migration de l'API Fitbit Web vers l'API Google Health est plus qu'une mise à jour technique. Vos utilisateurs doivent à nouveau donner leur consentement à votre nouvelle intégration, car vous avez modifié la bibliothèque OAuth. Il n'est pas possible de transférer des jetons d'accès et d'actualisation vers l'API Google Health et de les faire fonctionner. Pour vous aider à fidéliser les utilisateurs lors de votre migration, voici quelques suggestions techniques et stratégiques pour réussir votre migration.

Stratégie de double bibliothèque

Étant donné que l'API Fitbit Web et l'API Google Santé utilisent des bibliothèques OAuth2 différentes, vous devez gérer une période de transition pendant laquelle les deux bibliothèques existent dans votre code.

Gestion parallèle des autorisations

  • Encapsuler les clients : créez une couche d'abstraction ou une interface pour votre "service de santé". Cela permet au reste de votre application de demander des données sans savoir quelle bibliothèque (Fitbit OAuth ou Google OAuth) est active pour cet utilisateur spécifique.
  • Mise à jour du schéma de base de données : mettez à jour votre tableau utilisateur pour inclure un indicateur oauth_type. Par exemple, utilisez fitbit pour l'authentification OAuth Fitbit et google pour l'authentification OAuth Google.
    • Nouveaux utilisateurs : par défaut, ils utilisent l'API Google Health et la bibliothèque Google OAuth. Définissez oauth_type sur google.
    • Utilisateurs existants : continuez à utiliser l'API Fitbit Web jusqu'à ce qu'ils aient terminé le processus de réobtention du consentement. Définissez oauth_type sur fitbit.

Processus de recueil du consentement "Step-Up"

Au lieu de forcer la déconnexion, utilisez une approche d'autorisation incrémentielle :

  1. Détecter le jeton Fitbit Open Source : lorsqu'un utilisateur de l'API Fitbit Web ouvre l'application, déclenchez une notification "Mise à jour du service".
  2. Lancer le flux Google OAuth : lorsque l'utilisateur clique sur "Mettre à jour", lancez le flux de la bibliothèque Google OAuth2.
  3. Remplacer et révoquer : une fois le jeton Google OAuth reçu, enregistrez-le dans le profil utilisateur, mettez à jour oauth_type de fitbit à google et (si possible) révoquez l'ancien jeton fitbit de manière programmatique pour que le profil de sécurité de l'utilisateur reste propre.

Maximiser la fidélisation des utilisateurs

Le réconsentement est une "zone de danger" pour le churn. Pour éviter que les utilisateurs n'abandonnent l'application, suivez ces bonnes pratiques en matière d'UX :

La communication "axée sur la valeur"

Ne commencez pas par "Nous avons mis à jour notre API". Mettez en avant les avantages du nouveau système soutenu par Google :

  • Sécurité renforcée : mentionnez la protection de compte et l'authentification à deux facteurs de Google, qui sont les meilleures du secteur.
  • Fiabilité : synchronisation plus rapide et connexions de données plus stables.
  • Feature Gating : informez les utilisateurs en douceur que les nouvelles fonctionnalités et les nouveaux types de données nécessitent la mise à jour.

Smart Timing

  • N'interrompez pas les tâches à forte valeur ajoutée : ne déclenchez jamais l'écran de recueil du consentement pendant qu'un utilisateur est en train de faire de l'exercice ou d'enregistrer des aliments.
  • Phase d'incitation : pendant les 30 premiers jours, utilisez une bannière pouvant être fermée.
  • Phase de "désactivation définitive" : ne rendez le nouveau consentement obligatoire qu'après plusieurs semaines d'avertissements, en même temps que les dates limites officielles de l'arrêt de l'API Fitbit Web.

Comparaison des flux de migration

Une distinction visuelle claire entre les anciens et les nouveaux flux aide les développeurs à comprendre où la logique se divise.

Fonctionnalité API Web Fitbit (ancienne) API Google Health (Google-Identity)
Bibliothèque Auth Open Source standard Google Identity Services (GIS) / Authentification Google
Comptes utilisateur Identifiants Fitbit hérités Compte Google
Type de jeton Accès / Actualisation spécifiques à Fitbit Jetons d'accès/d'actualisation émis par Google
Gestion du champ d'application Autorisations étendues Autorisations précises / incrémentielles

Gérer les nuances de la migration de compte

Selon la documentation de Fitbit, les utilisateurs qui migrent leur compte vers Google ne perdent généralement pas immédiatement leurs connexions tierces, mais la modification de la version de l'API est une exigence côté développeur.

  • Vérifier la validité du jeton : utilisez un worker en arrière-plan pour vérifier si les jetons Fitbit échouent avec des erreurs "Non autorisé". Cela peut indiquer que l'utilisateur a migré son compte, mais que votre application n'a pas suivi.
  • Gestion des échecs : si un appel Fitbit OAuth échoue, redirigez l'utilisateur vers une page personnalisée "Reconnecter Fitbit" qui utilise spécifiquement le nouveau flux Google OAuth.