Types de données de l'API Google Health

Le tableau suivant contient la liste complète des types de données, avec plusieurs colonnes pour vous aider à comprendre la représentation de chaque type dans l'API Google Health, ainsi que le champ d'application de chacun.

Champs de type de données

Le tableau des types de données de l'API Google Health inclut plusieurs colonnes de champs pour vous aider à comprendre la représentation et les exigences de chaque type de données. Voici ces colonnes :

Tableau : Descriptions des champs de type de données de l'API Google Health
Champ Description
dataType Identifiant séparé par des tirets (par exemple, active-minutes) utilisé dans les URL de point de terminaison.
Paramètre filter Identifiant séparé par des traits de soulignement (par exemple, active_minutes) utilisé comme valeur pour le paramètre de filtre dataType dans les demandes de regroupement quotidien et de regroupement.
Type d'enregistrement

Indique la structure et le format des données enregistrées. En arrière-plan, cela correspond à la représentation des ressources des points de données. Les valeurs possibles sont :

  • Interval (représente les mesures enregistrées sur une durée)
  • Sample (représente les mesures instantanées).
  • Daily (représente les mesures agrégées ou enregistrées quotidiennement)
  • Session (représente un bloc continu d'enregistrement, comme un entraînement ou une session d'électrocardiogramme (ECG))
  • Food (représente un aliment ou une entité de données liées à la nutrition)
Opérations disponibles Liste les méthodes d'API compatibles avec le type de données (par exemple, list, create et rollUp).
Scope (Portée) Champ d'application OAuth requis pour accéder au type de données.
Compatibilité avec les webhooks Indique que le type de données est compatible avec les notifications en temps réel à l'aide de webhooks lorsque de nouvelles données sont synchronisées.
Prise en charge des vrais zéros Indique que le type de données permet d'enregistrer des valeurs nulles explicites pour faire la différence entre une valeur nulle active (comme zéro minute active) et des données manquantes ou non enregistrées.
Résolution de stockage Intervalle d'enregistrement ou d'échantillonnage minimal auquel les points de données sont stockés (par exemple, 1 minute pour steps). Pour les cumuls, cela représente le windowSize minimal recommandé pour assurer une agrégation uniformément répartie sans artefacts de données de sous-intervalle.
Appareils compatibles Liste extensible des appareils physiques qui peuvent enregistrer et synchroniser ce type de données avec l'API Google Health (à l'aide de l'app Fitbit).

Tableau : Types de données de l'API Google Health
Type de données Opérations
disponibles
Champ d'application
Énergie active dépensée
dataType : active-energy-burned
filter parameter : active_energy_burned
Type d'enregistrement  : Intervalle
Résolution du stockage  : 1 minute
list, reconcile, rollup, dailyRollup .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Minutes actives
dataType : active-minutes
filter parameter : active_minutes
Type d'enregistrement  : Intervalle
Résolution du stockage  : 1 minute

Appareils compatibles

  • Fitbit Air
  • Fitbit Alta
  • Fitbit Alta HR
  • Fitbit Blaze
  • Fitbit Charge 2
  • Fitbit Charge 3
  • Fitbit Flex 2
  • Fitbit Inspire
  • Fitbit Inspire HR
  • Pixel Watch 4
list, reconcile, rollup, dailyRollup .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Minutes en zone active
dataType : active-zone-minutes
filter parameter : active_zone_minutes
Type d'enregistrement  : Intervalle
Résolution du stockage  : 1 minute

Appareils compatibles

list, reconcile, rollup, dailyRollup .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Niveau d'activité
dataType : activity-level
filter parameter : activity_level
Type d'enregistrement  : Intervalle
lister, rapprocher .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Altitude
dataType : altitude
filter parameter : altitude
Type d'enregistrement  : Intervalle
Résolution du stockage  : 1 minute
list, reconcile, rollup, dailyRollup .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Glycémie
dataType : blood-glucose
filter parameter : blood_glucose
Type d'enregistrement  : Exemple
list, get, reconcile, rollup, dailyRollup .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
Masse grasse
dataType : body-fat
filter parameter : body_fat
Type d'enregistrement  : Exemple

Appareils compatibles

list, get, reconcile, rollup, dailyRollup, create, update, batchDelete .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
Calories brûlées dans la zone de fréquence cardiaque
dataType : calories-in-heart-rate-zone
filter parameter : calories_in_heart_rate_zone
Type d'enregistrement  : Intervalle
Résolution du stockage  : 1 minute
rollup, dailyRollup .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Température corporelle centrale
dataType : core-body-temperature
filter parameter : core_body_temperature
Type d'enregistrement  : Exemple
list, get, reconcile, rollup, dailyRollup .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
Variabilité quotidienne de la fréquence cardiaque
dataType : daily-heart-rate-variability
filter parameter : daily_heart_rate_variability
Type d'enregistrement  : "Tous les jours"

Appareils compatibles

lister, rapprocher .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
Zones de fréquence cardiaque quotidienne
dataType : daily-heart-rate-zones
filter parameter : daily_heart_rate_zones
Type d'enregistrement  : "Tous les jours"
lister, rapprocher .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
Saturation en oxygène quotidienne
dataType : daily-oxygen-saturation
filter parameter : daily_oxygen_saturation
Type d'enregistrement  : "Tous les jours"

Appareils compatibles

lister, rapprocher .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
Fréquence respiratoire quotidienne
dataType : daily-respiratory-rate
filter parameter : daily_respiratory_rate
Type d'enregistrement  : "Tous les jours"

Appareils compatibles

lister, rapprocher .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
Fréquence cardiaque au repos quotidienne
dataType : daily-resting-heart-rate
filter parameter : daily_resting_heart_rate
Type d'enregistrement  : "Tous les jours"

Appareils compatibles

lister, rapprocher .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
Dérivations quotidiennes de la température de sommeil
dataType : daily-sleep-temperature-derivations
filter parameter : daily_sleep_temperature_derivations
Type d'enregistrement  : "Tous les jours"

Appareils compatibles

lister, rapprocher .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
VO2 max quotidienne
dataType : daily-vo2-max
filter parameter : daily_vo2_max
Type d'enregistrement  : "Tous les jours"

Appareils compatibles

lister, rapprocher .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Distance
dataType : distance
filter parameter : distance
Type d'enregistrement  : Intervalle
Résolution du stockage  : 1 minute

Appareils compatibles

list, reconcile, rollup, dailyRollup .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Électrocardiogramme (ECG)
dataType : electrocardiogram
filter parameter : electrocardiogram
Type d'enregistrement  : session

Appareils compatibles

list .ecg.readonly
Exercice
dataType : exercise
filter parameter : exercise
Type d'enregistrement  : session

Appareils compatibles

list, get, reconcile, create, update, batchDelete .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Étages
dataType : floors
filter parameter : floors
Type d'enregistrement  : Intervalle
Résolution du stockage  : 1 minute
reconcile, rollup, dailyRollup .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Nourriture
dataType : food
filter parameter : food
Type d'enregistrement  : Alimentation
list, get .nutrition.readonly
.nutrition.writeonly
Unité de mesure des aliments
dataType : food-measurement-unit
filter parameter : food_measurement_unit
Type d'enregistrement  : Alimentation

Appareils compatibles

list, get .nutrition.readonly
.nutrition.writeonly
Fréquence cardiaque
dataType : heart-rate
filter parameter : heart_rate
Type d'enregistrement  : Exemple
Résolution du stockage  : 1 seconde (1 s)

Appareils compatibles

list, reconcile, rollup, dailyRollup .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
Variabilité de la fréquence cardiaque
dataType : heart-rate-variability
filter parameter : heart_rate_variability
Type d'enregistrement  : Exemple

Appareils compatibles

lister, rapprocher .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
Hauteur
dataType : height
filter parameter : height
Type d'enregistrement  : Exemple
list, get, reconcile, create, update, batchDelete .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
Journal d'hydratation
dataType : hydration-log
filter parameter : hydration_log
Type d'enregistrement  : session
list, get, reconcile, rollup, dailyRollup, create, update, batchDelete .nutrition.readonly
.nutrition.writeonly
Notification de rythme irrégulier
dataType : irregular-rhythm-notification
filter parameter : irregular_rhythm_notification
Type d'enregistrement  : session
list .irn.readonly
Période menstruelle
dataType : menstrual-period
filter parameter : menstrual_period
Type d'enregistrement  : Intervalle
create, update, batchDelete .reproductive_health.writeonly
Humeurs
dataType : moods
filter parameter : moods
Type d'enregistrement  : Exemple
create, update, batchDelete .mindfulness.writeonly
Journal de nutrition
dataType : nutrition-log
filter parameter : nutrition_log
Type d'enregistrement  : session

Appareils compatibles

list, get, reconcile, rollup, dailyRollup, create, update, batchDelete .nutrition.readonly
.nutrition.writeonly
Test d'ovulation
dataType : ovulation-test
filter parameter : ovulation_test
Type d'enregistrement  : Exemple
create, update, batchDelete .reproductive_health.writeonly
Saturation en oxygène
dataType : oxygen-saturation
filter parameter : oxygen_saturation
Type d'enregistrement  : Exemple

Appareils compatibles

lister, rapprocher .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
Résumé du sommeil avec la fréquence respiratoire
dataType : respiratory-rate-sleep-summary
filter parameter : respiratory_rate_sleep_summary
Type d'enregistrement  : Exemple

Appareils compatibles

lister, rapprocher .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly
VO2 max de la course
dataType : run-vo2-max
filter parameter : run_vo2_max
Type d'enregistrement  : Exemple

Appareils compatibles

list, reconcile, rollup, dailyRollup .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Période sédentaire
dataType : sedentary-period
filter parameter : sedentary_period
Type d'enregistrement  : Intervalle

Appareils compatibles

list, reconcile, rollup, dailyRollup .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Sommeil
dataType : sleep
filter parameter : sleep
Type d'enregistrement  : session

Appareils compatibles

list, get, reconcile, create, update, batchDelete .sleep.readonly
.sleep.writeonly
Étapes
dataType : steps
filter parameter : steps
Type d'enregistrement  : Intervalle
Résolution du stockage  : 1 minute

Appareils compatibles

list, reconcile, rollup, dailyRollup .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Données sur les longueurs de nage
dataType : swim-lengths-data
filter parameter : swim_lengths_data
Type d'enregistrement  : Intervalle

Appareils compatibles

list, reconcile, rollup, dailyRollup .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Problèmes constatés
dataType : symptoms
filter parameter : symptoms
Type d'enregistrement  : Exemple
create, update, batchDelete .logged_symptoms.writeonly
Temps passé dans la zone de fréquence cardiaque
dataType : time-in-heart-rate-zone
filter parameter : time_in_heart_rate_zone
Type d'enregistrement  : Intervalle
Résolution du stockage  : 1 minute
list, reconcile, rollup, dailyRollup .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Total des calories
dataType : total-calories
filter parameter : total_calories
Type d'enregistrement  : Intervalle
Résolution du stockage  : 1 minute

Appareils compatibles

rollup, dailyRollup .activity_and_fitness.readonly
.activity_and_fitness.writeonly
VO2 max
dataType : vo2-max
filter parameter : vo2_max
Type d'enregistrement  : Exemple

Appareils compatibles

lister, rapprocher .activity_and_fitness.readonly
.activity_and_fitness.writeonly
Poids
dataType : weight
filter parameter : weight
Type d'enregistrement  : Exemple

Appareils compatibles

list, get, reconcile, rollup, dailyRollup, create, update, batchDelete .health_metrics_and_measurements.readonly
.health_metrics_and_measurements.writeonly

Contraintes de requête

Lorsque vous interrogez des points de données, des cumuls ou des cumuls quotidiens à partir de l'API, gardez à l'esprit les contraintes suivantes :

  • Exigences concernant les filtres : certains types de données dérivées en lecture seule, comme total-calories, nécessitent un filtre spécifiant une heure de début d'intervalle (en utilisant l'heure physique ou civile).
  • Limites de la période de la requête : les points de terminaison d'agrégation "rollup" et "rollup quotidien" appliquent des limites maximales à la période de la requête en fonction du type de données :
    • Une plage de requête maximale de 14 jours pour calories-in-heart-rate-zone, heart-rate, active-minutes et total-calories.
    • Une période de requête maximale de 90 jours pour tous les autres types de données.
  • Taille de la fenêtre de cumul : lorsque vous appelez le point de terminaison rollUp, la durée windowSize doit être d'au moins une seconde ("1s"). Les durées inférieures à une seconde sont refusées avec INVALID_ARGUMENT. De plus, choisissez un windowSize égal ou supérieur à la résolution de stockage sous-jacente du type de données (par exemple, "60s" pour les types de données à intervalle d'une minute comme steps et distance) pour éviter une distribution inégale entre les sous-intervalles. Pour en savoir plus, consultez Taille de la fenêtre de cumul et résolution du stockage sous-jacent.

Types de données "Jour" et "Intervalle"

Pour certaines métriques physiologiques, comme la variabilité de la fréquence cardiaque (VFC) ou la saturation en oxygène (SpO2), l'API Google Health fournit deux types de données distincts : une version quotidienne et une version par intervalle. Il est essentiel de comprendre la différence entre ces deux types de modèles pour choisir le bon critère pour votre cas d'utilisation :

  • Quotidien : un récapitulatif unique et préagrégé pour toute la journée. Utilisez-la pour les tendances générales et les tableaux de bord quotidiens afin d'économiser du temps de traitement.

  • Intervalle : mesures précises et haute résolution prises tout au long de la journée. Utilisez-le pour représenter les fluctuations intrajournalières ou effectuer une analyse approfondie, heure par heure.

Disponibilité des données

Les mises à jour des données de l'utilisateur ne sont disponibles qu'après la synchronisation de son moniteur d'activité physique ou la saisie manuelle de nouvelles données dans l'app mobile ou l'application Web Fitbit. L'appareil Fitbit et l'app mobile Fitbit peuvent se synchroniser automatiquement toutes les 15 minutes lorsque l'app Fitbit est ouverte sur l'appareil mobile et que les deux disposent d'une connexion de données active et se trouvent à portée Bluetooth. Si l'utilisateur suit son activité avec MobileTrack, MobileTrack se synchronise toutes les heures tant que l'application est ouverte.

Interroger les données historiques

L'un des principaux avantages de l'API Google Health est la possibilité de suivre les performances d'un utilisateur et de surveiller ses constantes vitales sur de longues périodes. Vous pouvez interroger les données d'un utilisateur aussi loin que possible dans le passé, dans la mesure où elles ont été enregistrées. L'API n'impose aucune limite ni restriction sur la quantité de données historiques que votre application peut consommer.

Toutefois, l'interrogation des données historiques reste soumise aux limites de fréquence standards. Pour gérer la stabilité du système et éviter les charges utiles excessives, l'API Google Health utilise la pagination automatique avec des tailles de page spécifiques aux points de terminaison. Notez les limites et le comportement suivants :

  • Pagination automatique : si vous interrogez une longue période de données, l'API ne renverra que la première page de résultats jusqu'à la limite de taille de page pour ce point de terminaison, ainsi qu'un nextPageToken. Vous devez utiliser nextPageToken pour demander les pages suivantes.
  • Taille de page variable : les limites de capping dépendent du point de terminaison et du type de données. Pour la plupart des types de données, la taille des pages est limitée à 10 000. Toutefois, pour certains types de données comme exercise et sleep, la taille de page par défaut et maximale est limitée à 25. Par exemple, si un client demande toutes les données de sommeil des 10 dernières années, l'API ne renverra que 25 sessions de sommeil sur la première page.
  • Restrictions concernant les périodes de cumul : pour les points de terminaison de cumul et d'agrégation des données (tels que rollUp et dailyRollUp), les périodes de requête sont limitées en fonction du type de données :
    • Une plage maximale de 14 jours pour calories-in-heart-rate-zone, heart-rate, active-minutes et total-calories.
    • Une période maximale de 90 jours pour tous les autres types de données cumulées.

Selon le volume de données historiques dont votre application a besoin, la récupération de l'ensemble de données nécessitera une pagination séquentielle. Gardez cela à l'esprit lorsque vous concevez le processus de synchronisation des données de votre application.

Pour garantir des performances optimales et éviter les erreurs d'API, suivez ces consignes lorsque vous interrogez des données historiques :

Synchronisation progressive des données (chargement à chaud ou à froid)

  • Chargement "à chaud" initial : récupérez et affichez uniquement les données des 7 à 14 derniers jours lors de la séquence de chargement principale. Cela permet aux utilisateurs de voir les données immédiatement sans attendre les requêtes de longue durée.
  • Chargement "à froid" en arrière-plan : déléguez la récupération des données historiques plus anciennes à une file d'attente ou à un processus en arrière-plan asynchrone et de priorité inférieure après le rendu de l'UI principale.

Segmentation des requêtes pour l'agrégation

  • Étant donné que les points de terminaison de cumul et de cumul quotidien appliquent une limite de période maximale (14 ou 90 jours selon le type de données), vous devez diviser les grandes requêtes d'agrégation historique en intervalles séquentiels plus petits respectant ces limites.
  • Regroupez ou séquencez ces sous-requêtes de manière sécurisée pour respecter les limites de simultanéité et maintenir des indicateurs de progression de l'UI stables.

Exploiter les récapitulatifs pré-agrégés

Restructurez les tableaux de bord et les graphiques de tendances pour utiliser des points de terminaison récapitulatifs pré-agrégés (tels que DailyRollUpDataPoints). Cela réduira considérablement la surcharge de calcul sur le backend et le temps de transfert réseau vers le client.

Gestion des exceptions résiliente (nouvelles tentatives intelligentes)

  • Implémentez une gestion stricte de l'intervalle exponentiel entre les tentatives lorsque vous rencontrez des limites de fréquence (429 Too Many Requests) et des délais d'expiration de la passerelle du serveur (504 Gateway Timeout). Ne réessayez jamais immédiatement les charges utiles volumineuses ayant échoué. Les nouvelles tentatives instantanées multiplient la congestion du backend et aggravent la dégradation du système.

Accès tiers

Les appareils Fitbit ne peuvent pas communiquer directement avec des applications ou services tiers. Ces appareils sont conçus pour communiquer et se synchroniser exclusivement avec l'application mobile Fitbit.

L'appareil synchronise automatiquement les données tout au long de la journée, chaque fois que l'app Fitbit est ouverte, ou toutes les 15 minutes si le Bluetooth est activé et que l'application s'exécute en arrière-plan. Une fois ce processus de synchronisation terminé, les données sont disponibles pour les services tiers via l'API Google Health.

Normes de distance

Les distances d'exercice, telles que elevationGainMillimeters, sont mesurées en millimètres, qui sont l'unité standard, pour les raisons suivantes :

  1. Maintenir la précision des données : la raison la plus importante d'utiliser les millimètres est de s'assurer de ne perdre aucune précision dans les données que nous lisons et fournissons. L'utilisation d'une unité précise comme le millimètre nous permet de représenter les mesures avec une grande précision.
  2. Standardisation : les millimètres sont l'unité standardisée conçue pour nos services. Cette cohérence permet de garantir une expérience uniforme pour les développeurs qui interagissent avec différentes parties de l'API.
  3. Prise en charge étendue du système de mesure : l'utilisation d'une unité de base telle que le millimètre permet aux développeurs de convertir facilement les valeurs dans l'unité de leur choix, qu'ils travaillent avec le système métrique, impérial ou un autre système de mesure.

Durée variable des journées

La gestion du temps par l'API Health donne la priorité à l'heure de l'utilisateur pour tenir compte des durées de journée variables causées par le passage à l'heure d'été ou les voyages. Chaque point de données est stocké avec un code temporel UTC physique et le décalage UTC actif au moment de l'événement. Cela permet au système :

  • Associez l'événement à un instant physique précis.
  • Corrigez l'heure en fonction du contexte local de l'utilisateur pour l'agrégation.

Heure d'été

Lors du passage à l'heure d'hiver, la journée civile dure 25 heures. La consolidation pour cette date contiendra donc 25 heures de données. Le passage à l'heure d'été entraîne une journée civile de 23 heures, où l'heure est avancée d'une heure.

Voyages

Les voyages à travers les fuseaux horaires peuvent entraîner des variations encore plus importantes de la durée physique d'un jour civil.

Utilisez le point de terminaison dailyRollUp pour tenir compte des différences de fuseau horaire. Il attribue automatiquement les données au jour du calendrier où elles ont été enregistrées, selon l'heure locale de l'utilisateur. Il "rassemble" ainsi la journée malgré les changements de fuseau horaire.