Die folgende Tabelle enthält die vollständige Liste der Datentypen mit mehreren Spalten, die Ihnen helfen, die Darstellung der einzelnen Typen in der Google Health API sowie den Bereich, in dem sie verfügbar sind, zu verstehen.
Felder für Datentypen
Die Tabelle mit den Datentypen der Google Health API enthält mehrere Feldspalten, die Ihnen helfen, die Darstellung und Anforderungen der einzelnen Datentypen zu verstehen. Diese Spalten sind:
| Feld | Beschreibung |
|---|---|
dataType |
Die durch Bindestriche getrennte Kennung (z. B. active-minutes), die in Endpunkt-URLs verwendet wird. |
filter-Parameter |
Die durch Unterstriche getrennte Kennung (z. B. active_minutes), die als Wert für den Filterparameter dataType in täglichen Rollup- und Rollup-Anfragen verwendet wird. |
| Eintragstyp | Gibt die Struktur und das Format der aufgezeichneten Daten an. Im Hintergrund entspricht dies der Ressourcendarstellung der Datenpunkte. Die möglichen Werte sind:
|
| Verfügbare Vorgänge | Listet die für den Datentyp unterstützten API-Methoden auf (z. B. list, create und rollUp). |
| Einsatzbereich | Die erforderlichen OAuth-Bereiche für den Zugriff auf den Datentyp. |
| Webhook-Unterstützung | Gibt an, dass der Datentyp Echtzeitbenachrichtigungen über Webhooks unterstützt, wenn neue Daten synchronisiert werden. |
| Unterstützung für echte Nullen | Gibt an, dass der Datentyp die Aufzeichnung expliziter Nullwerte unterstützt, um zwischen einem aktiven Nullwert (z. B. null aktive Minuten) und fehlenden oder nicht aufgezeichneten Daten zu unterscheiden. |
| Speicherauflösung | Das minimale Aufzeichnungs- oder Stichprobenintervall, in dem Datenpunkte gespeichert werden (z. B. 1 Minute für steps). Bei Roll-ups stellt dies die empfohlene Mindest-windowSize dar, um eine gleichmäßig verteilte Aggregation ohne Datenartefakte in Unterintervallen zu gewährleisten. |
| Kompatible Geräte | Eine maximierbare Liste physischer Geräte, die diesen Datentyp aufzeichnen und über die Fitbit App mit der Google Health API synchronisieren können. |
| Datentyp | Verfügbare -Vorgänge |
Bereich |
|---|---|---|
|
Aktiv verbrannte Energie
dataType:
active-energy-burnedfilter parameter: active_energy_burned
Eintragstyp: Intervall
Speicherauflösung: 1 Minute
|
list, reconcile, rollup, dailyRollup | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Aktive Minuten
dataType:
active-minutesfilter parameter: active_minutes
Eintragstyp: Intervall
Speicherauflösung: 1 Minute
Kompatible Geräte
|
list, reconcile, rollup, dailyRollup | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Aktivzonenminuten
dataType:
active-zone-minutesfilter parameter: active_zone_minutes
Eintragstyp: Intervall
Speicherauflösung: 1 Minute
Kompatible Geräte
|
list, reconcile, rollup, dailyRollup | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Aktivitätsniveau
dataType:
activity-levelfilter parameter: activity_level
Eintragstyp: Intervall
|
list, reconcile | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Altitude
|
list, reconcile, rollup, dailyRollup | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Blutzucker
dataType:
blood-glucosefilter parameter: blood_glucose
Eintragstyp: Beispiel
|
list, get, reconcile, rollup, dailyRollup | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Körperfett
dataType:
body-fatfilter parameter: body_fat
Eintragstyp: Beispiel
Kompatible Geräte
|
list, get, reconcile, rollup, dailyRollup, create, update, batchDelete | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Kalorien in Herzfrequenzzone
dataType:
calories-in-heart-rate-zonefilter parameter: calories_in_heart_rate_zone
Eintragstyp: Intervall
Speicherauflösung: 1 Minute
|
rollup, dailyRollup | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Körperkerntemperatur
dataType:
core-body-temperaturefilter parameter: core_body_temperature
Eintragstyp: Beispiel
|
list, get, reconcile, rollup, dailyRollup | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Tägliche Herzfrequenzvariabilität
dataType:
daily-heart-rate-variabilityfilter parameter: daily_heart_rate_variability
Eintragstyp: Täglich
Kompatible Geräte
|
list, reconcile | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Tägliche Herzfrequenzzonen
dataType:
daily-heart-rate-zonesfilter parameter: daily_heart_rate_zones
Eintragstyp: Täglich
|
list, reconcile | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Tägliche Sauerstoffsättigung
dataType:
daily-oxygen-saturationfilter parameter: daily_oxygen_saturation
Eintragstyp: Täglich
Kompatible Geräte
|
list, reconcile | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Tägliche Atemfrequenz
dataType:
daily-respiratory-ratefilter parameter: daily_respiratory_rate
Eintragstyp: Täglich
Kompatible Geräte
|
list, reconcile | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Tägliche Ruheherzfrequenz
dataType:
daily-resting-heart-ratefilter parameter: daily_resting_heart_rate
Eintragstyp: Täglich
Kompatible Geräte
|
list, reconcile | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Tägliche Abweichungen der Schlaftemperatur
dataType:
daily-sleep-temperature-derivationsfilter parameter: daily_sleep_temperature_derivations
Eintragstyp: Täglich
Kompatible Geräte
|
list, reconcile | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Tägliche maximale Sauerstoffaufnahme
dataType:
daily-vo2-maxfilter parameter: daily_vo2_max
Eintragstyp: Täglich
Kompatible Geräte
|
list, reconcile | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Entfernung
dataType:
distancefilter parameter: distance
Eintragstyp: Intervall
Speicherauflösung: 1 Minute
Kompatible Geräte
|
list, reconcile, rollup, dailyRollup | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Elektrokardiogramm (EKG)
dataType:
electrocardiogramfilter parameter: electrocardiogram
Eintragstyp: Sitzung
Kompatible Geräte
|
list | .ecg.readonly |
|
Training
dataType:
exercisefilter parameter: exercise
Eintragstyp: Sitzung
Kompatible Geräte
|
list, get, reconcile, create, update, batchDelete | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Stockwerke
|
reconcile, rollup, dailyRollup | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Essen
|
list, get | .nutrition.readonly.nutrition.writeonly |
|
Maßeinheit für Lebensmittel
dataType:
food-measurement-unitfilter parameter: food_measurement_unit
Eintragstyp: Lebensmittel
Kompatible Geräte
|
list, get | .nutrition.readonly.nutrition.writeonly |
|
Herzfrequenz
dataType:
heart-ratefilter parameter: heart_rate
Eintragstyp: Beispiel
Speicherauflösung: 1 Sekunde
Kompatible Geräte
|
list, reconcile, rollup, dailyRollup | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Herzfrequenzvariabilität
dataType:
heart-rate-variabilityfilter parameter: heart_rate_variability
Eintragstyp: Beispiel
Kompatible Geräte
|
list, reconcile | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Höhe
|
list, get, reconcile, create, update, batchDelete | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Flüssigkeitszufuhr-Protokoll
|
list, get, reconcile, rollup, dailyRollup, create, update, batchDelete | .nutrition.readonly.nutrition.writeonly |
|
Benachrichtigung über einen unregelmäßigen Herzrhythmus
dataType:
irregular-rhythm-notificationfilter parameter: irregular_rhythm_notification
Eintragstyp: Sitzung
|
list | .irn.readonly |
|
Menstruation
dataType:
menstrual-periodfilter parameter: menstrual_period
Eintragstyp: Intervall
|
create, update, batchDelete | .reproductive_health.writeonly |
|
Moods
|
create, update, batchDelete | .mindfulness.writeonly |
|
Ernährungsprotokoll
dataType:
nutrition-logfilter parameter: nutrition_log
Eintragstyp: Sitzung
Kompatible Geräte
|
list, get, reconcile, rollup, dailyRollup, create, update, batchDelete | .nutrition.readonly.nutrition.writeonly |
|
Ovulationstest
dataType:
ovulation-testfilter parameter: ovulation_test
Eintragstyp: Beispiel
|
create, update, batchDelete | .reproductive_health.writeonly |
|
Sauerstoffsättigung
dataType:
oxygen-saturationfilter parameter: oxygen_saturation
Eintragstyp: Beispiel
Speicherauflösung: 1 Minute
Kompatible Geräte
|
list, reconcile | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Atemfrequenz-Schlafanalyse
dataType:
respiratory-rate-sleep-summaryfilter parameter: respiratory_rate_sleep_summary
Eintragstyp: Beispiel
Kompatible Geräte
|
list, reconcile | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Maximale Sauerstoffaufnahme bei Lauf
dataType:
run-vo2-maxfilter parameter: run_vo2_max
Eintragstyp: Beispiel
Kompatible Geräte
|
list, reconcile, rollup, dailyRollup | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Inaktive Zeit
dataType:
sedentary-periodfilter parameter: sedentary_period
Eintragstyp: Intervall
Kompatible Geräte
|
list, reconcile, rollup, dailyRollup | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Hauttemperatursensoren
v4beta
dataType:
skin-temperature-sensorsfilter parameter: skin_temperature_sensors
Eintragstyp: Beispiel
Kompatible Geräte |
list | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
|
Schlaf
dataType:
sleepfilter parameter: sleep
Eintragstyp: Sitzung
Kompatible Geräte
|
list, get, reconcile, create, update, batchDelete | .sleep.readonly.sleep.writeonly |
|
Schritte
dataType:
stepsfilter parameter: steps
Eintragstyp: Intervall
Speicherauflösung: 1 Minute
Kompatible Geräte
|
list, reconcile, rollup, dailyRollup | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Daten zu geschwommenen Bahnen
dataType:
swim-lengths-datafilter parameter: swim_lengths_data
Eintragstyp: Intervall
Kompatible Geräte
|
list, reconcile, rollup, dailyRollup | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Symptome
|
create, update, batchDelete | .logged_symptoms.writeonly |
|
Zeit in Herzfrequenzzone
dataType:
time-in-heart-rate-zonefilter parameter: time_in_heart_rate_zone
Eintragstyp: Intervall
Speicherauflösung: 1 Minute
|
list, reconcile, rollup, dailyRollup | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Kalorien insgesamt
dataType:
total-caloriesfilter parameter: total_calories
Eintragstyp: Intervall
Speicherauflösung: 1 Minute
Kompatible Geräte
|
rollup, dailyRollup | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Maximale Sauerstoffaufnahme
dataType:
vo2-maxfilter parameter: vo2_max
Eintragstyp: Beispiel
Kompatible Geräte
|
list, reconcile | .activity_and_fitness.readonly.activity_and_fitness.writeonly |
|
Gewicht
dataType:
weightfilter parameter: weight
Eintragstyp: Beispiel
Kompatible Geräte
|
list, get, reconcile, rollup, dailyRollup, create, update, batchDelete | .health_metrics_and_measurements.readonly.health_metrics_and_measurements.writeonly |
Abfrageeinschränkungen
Beachten Sie beim Abfragen von Datenpunkten, Roll-ups oder täglichen Roll-ups über die API die folgenden Einschränkungen:
- Filteranforderungen:Für einige schreibgeschützte abgeleitete Datentypen wie
total-caloriesist ein Filter erforderlich, der eine Startzeit für das Intervall angibt (unter Verwendung der physischen oder bürgerlichen Zeit). - Limits für Abfragebereiche: Für Rollup- und tägliche Rollup-Aggregationsendpunkte gelten maximale Limits für Abfragebereiche, die vom Datentyp abhängen:
- Ein maximaler Abfragebereich von 14 Tagen für
calories-in-heart-rate-zone,heart-rate,active-minutesundtotal-calories. - Maximaler Abfragezeitraum von 90 Tagen für alle anderen Datentypen.
- Ein maximaler Abfragebereich von 14 Tagen für
- Größe des Roll-up-Fensters: Beim Aufrufen des Endpunkts
rollUpmuss die Dauer vonwindowSizemindestens 1 Sekunde ("1s") betragen. Dauern unter einer Sekunde werden mitINVALID_ARGUMENTabgelehnt. Wählen Sie außerdem einenwindowSize-Wert aus, der mindestens so groß ist wie die zugrunde liegende Speicherauflösung des Datentyps (z. B."60s"für Datentypen mit einem Intervall von 1 Minute wiestepsunddistance), um eine ungleichmäßige Verteilung über Unterintervalle zu vermeiden. Weitere Informationen finden Sie unter Rollup-Fenster und Speicherauflösung.
Tägliche Datentypen im Vergleich zu Intervall-Datentypen
Für bestimmte physiologische Messwerte wie die Herzfrequenzvariabilität (HFV) oder die Sauerstoffsättigung (SpO2) bietet die Google Health API zwei verschiedene Datentypen: eine tägliche Version und eine Intervallversion. Die Unterschiede zu kennen ist für die Wahl des richtigen Messwerts für Ihren Anwendungsfall entscheidend:
Täglich: Eine einzelne, vorab aggregierte Zusammenfassung für den gesamten Tag. Verwenden Sie diese Option für allgemeine Trends und tägliche Dashboards, um die Verarbeitung zu reduzieren.
Intervall: Granulare, hochauflösende Messungen, die den ganzen Tag über durchgeführt werden. Verwenden Sie diese Option, um Schwankungen im Tagesverlauf darzustellen oder detaillierte stündliche Analysen durchzuführen.
Datenverfügbarkeit
Aktualisierungen der Nutzerdaten sind erst verfügbar, nachdem der Nutzer seinen Aktivitätstracker synchronisiert oder manuell neue Daten in die Google Health App eingegeben hat. Das Fitbit-Gerät und die Google Health App können alle 15 Minuten automatisch synchronisiert werden, wenn die Google Health App auf dem Mobilgerät geöffnet ist, die beiden Geräte eine aktive Datenverbindung haben und sich in Bluetooth-Reichweite befinden. Wenn der Nutzer seine Aktivitäten mit MobileTrack aufzeichnet, wird MobileTrack jede Stunde synchronisiert, solange die App geöffnet ist.
Verlaufsdaten abfragen
Einer der Hauptvorteile der Google Health API ist die Möglichkeit, die Leistung eines Nutzers zu verfolgen und seine Vitalwerte über einen längeren Zeitraum zu überwachen. Sie können die Daten eines Nutzers so weit zurück abfragen, wie sie aufgezeichnet wurden. Die API legt keine Beschränkungen für die Menge an Verlaufsdaten fest, die Ihre Anwendung nutzen kann.
Das Abfragen von Verlaufsdaten unterliegt jedoch weiterhin den standardmäßigen Ratenbegrenzungen. Um die Systemstabilität zu gewährleisten und übermäßige Nutzlasten zu vermeiden, verwendet die Google Health API eine automatische Paginierung mit endpunktspezifischen Seitengrößen. Beachten Sie die folgenden Grenzen und Verhaltensweisen:
- Automatische Paginierung: Wenn Sie einen langen Zeitraum abfragen, gibt die API nur die erste Seite der Ergebnisse bis zur maximalen Seitengröße für diesen Endpunkt zurück, zusammen mit einem
nextPageToken. Sie müssen dasnextPageTokenverwenden, um nachfolgende Seiten anzufordern. - Variable Seitengrößen: Die Obergrenzen hängen vom Endpunkt und Datentyp ab. Bei den meisten Datentypen ist die Seitengröße auf maximal 10.000 begrenzt.
Bei bestimmten Datentypen wie
exerciseundsleepist die Standard- und maximale Seitengröße jedoch auf 25 begrenzt. Wenn ein Client beispielsweise alle Schlafdaten der letzten 10 Jahre anfordert, gibt die API auf der ersten Seite trotzdem nur 25 Schlafeinheiten zurück. - Einschränkungen für den Zeitraum der Zusammenfassung: Für Endpunkte zur Datenzusammenfassung und -aggregation (z. B.
rollUpunddailyRollUp) sind die Zeiträume für Abfragen je nach Datentyp eingeschränkt:- Ein maximaler Bereich von 14 Tagen für
calories-in-heart-rate-zone,heart-rate,active-minutesundtotal-calories. - Ein maximaler Zeitraum von 90 Tagen für alle anderen Datentypen in der Zusammenfassung.
- Ein maximaler Bereich von 14 Tagen für
Je nach Umfang der Verlaufsdaten, die Ihre Anwendung benötigt, müssen Sie zum Abrufen des gesamten Datasets die Seiten nacheinander durchgehen. Berücksichtigen Sie dies beim Entwerfen des Datensynchronisierungsprozesses Ihrer Anwendung.
Beachten Sie die folgenden Richtlinien, wenn Sie Verlaufsdaten abfragen, um eine optimale Leistung zu erzielen und API-Fehler zu vermeiden:
Phasenweise Datensynchronisierung (aktive und selten genutzte Daten)
- Erstes „heißes“ Laden: Rufen Sie während der primären Ladesequenz nur die Daten der letzten 7–14 Tage ab und rendern Sie sie. So sehen Nutzer die Daten sofort, ohne auf langwierige Abfragen warten zu müssen.
- „Kaltes“ Laden im Hintergrund:Delegieren Sie das Abrufen älterer Verlaufsdaten an eine asynchrone Warteschlange mit niedrigerer Priorität oder einen Hintergrundprozess, nachdem die primäre Benutzeroberfläche gerendert wurde.
Abfrage-Chunking für die Aggregation
- Da für Rollup- und tägliche Rollup-Endpunkte ein maximaler Zeitraum gilt (14 oder 90 Tage, je nach Datentyp), müssen Sie große Abfragen für historische Aggregationen in kleinere, aufeinanderfolgende Intervalle innerhalb dieser Limits aufteilen.
- Fassen Sie diese Unterabfragen sicher in Batches oder Sequenzen zusammen, um die Limits für gleichzeitige Abfragen einzuhalten und die Fortschrittsanzeigen der Benutzeroberfläche stabil zu halten.
Vorab aggregierte Roll-ups nutzen
Strukturieren Sie Übersichts-Dashboards und Trenddiagramme so um, dass voraggregierte Zusammenfassungsendpunkte (z. B. DailyRollUpDataPoints) verwendet werden. Dadurch werden der Rechenaufwand im Backend und die Netzwerkübertragungszeit zum Client drastisch reduziert.
Fehlerbehandlung (intelligente Wiederholungsversuche)
- Implementieren Sie eine strikte exponentielle Backoff-Verarbeitung, wenn Ratenbegrenzungen (
429 Too Many Requests) und Server-Gateway-Zeitüberschreitungen (504 Gateway Timeout) auftreten. Versuchen Sie niemals, große, fehlgeschlagene Nutzlasten sofort noch einmal zu senden. Sofortige Wiederholungsversuche vervielfachen die Backend-Überlastung und verschlimmern die Systemverschlechterung.
Zugriff durch Drittanbieter
Fitbit-Geräte können nicht direkt mit Anwendungen oder Diensten von Drittanbietern kommunizieren. Diese Geräte sind ausschließlich für die Kommunikation und Synchronisierung mit der Google Health App vorgesehen.
Das Gerät synchronisiert die Daten im Laufe des Tages automatisch, wenn die Google Health App geöffnet ist, oder alle 15 Minuten, wenn Bluetooth aktiviert ist und die App im Hintergrund ausgeführt wird. Sobald dieser Synchronisierungsvorgang abgeschlossen ist, sind die Daten für Drittanbieterdienste über die Google Health API verfügbar.
Filterung nach Datenqualität und -gültigkeit
Damit zuverlässige Gesundheitsmesswerte bereitgestellt werden können, ohne dass eine benutzerdefinierte clientseitige Rauschfilterung erforderlich ist, validiert die Google Health API Sensortelemetriedaten und schließt ungültige Messungen aus, bevor Antworten zurückgegeben werden:
- Für die minütliche Sauerstoffsättigung (
oxygen-saturation) gibt die API nur validierte Messwerte zurück. Minuten, die aufgrund von Armbewegungen, einem lockeren Sitz am Handgelenk oder einem Sensor-Konfidenzwert unter 50 % als ungültig markiert wurden, werden entfernt. Das gilt auch für die 3 Minuten vor und nach einem ungültigen Messwert sowie für isolierte gültige Abschnitte, die kürzer als 4 Minuten sind. Daher kann die Abdeckung auf Minutenebene lückenhaft sein und es sind Lücken zu erwarten. Weitere Informationen findest du unter SpO2-Filterung auf Minutenebene und Datengültigkeit.
Abstandsstandards
Trainingsdistanzen wie elevationGainMillimeters werden aus folgenden Gründen in Millimetern als Standardeinheit gemessen:
- Datengenauigkeit beibehalten: Der wichtigste Grund für die Verwendung von Millimetern ist, dass wir keine Genauigkeit bei den Daten verlieren, die wir lesen und bereitstellen. Mit einer feinen Einheit wie Millimetern können wir Messungen mit hoher Genauigkeit darstellen.
- Standardisierung: Millimeter sind die standardisierte Einheit in unseren Diensten. Diese Konsistenz sorgt für eine einheitliche Erfahrung für Entwickler, die mit verschiedenen Teilen der API interagieren.
- Breite Unterstützung von Maßsystemen: Durch die Verwendung einer Basiseinheit wie Millimeter können Entwickler die Werte ganz einfach in jede andere gewünschte Einheit umrechnen, unabhängig davon, ob sie mit metrischen, imperialen oder anderen Maßsystemen arbeiten.
Unterschiedliche Tageslängen
Bei der Zeitverarbeitung durch die Health API wird die Zeit des Nutzers priorisiert, um variable Tageslängen aufgrund von Sommerzeit oder Reisen zu berücksichtigen. Jeder Datenpunkt wird sowohl mit einem physischen UTC-Zeitstempel als auch mit dem UTC-Offset gespeichert, der zum Zeitpunkt des Ereignisses aktiv war. Dadurch kann das System Folgendes tun:
- Ordnen Sie das Ereignis einem genauen physischen Zeitpunkt zu.
- Korrigieren Sie die Zeit für die Aggregation auf den lokalen Kontext des Nutzers.
Sommerzeit
Bei der Umstellung auf die Sommerzeit führt die Zeitumstellung zu einem 25-Stunden-Tag und die Zusammenfassung für dieses Datum enthält 25 Stunden Daten. Die Umstellung auf Sommerzeit führt zu einem 23-Stunden-Tag, an dem die Zeit auf die Standardzeit zurückgestellt wird.
Reisen
Reisen über Zeitzonen hinweg können zu noch größeren Abweichungen bei der physischen Dauer eines einzelnen bürgerlichen Tages führen.
Verwenden Sie den Endpunkt dailyRollUp, um Zeitzonenunterschiede auszugleichen. Die Daten werden automatisch dem Kalendertag zugeordnet, an dem sie gemäß der Ortszeit des Nutzers aufgezeichnet wurden. So werden die Daten des Tages trotz Zeitzonenverschiebungen effektiv „zusammengefügt“. Weitere Informationen und Beispiele finden Sie im Leitfaden „Daten aggregieren“ unter Über Kalendertage hinweg aggregieren.