Übersicht

Die Google Health API ist eine umfassende Lösung, die von Grund auf neu entwickelt wurde und Entwicklern einen robusten Zugriff auf eine Vielzahl von Gesundheitsdaten von Nutzern mit Einwilligung und auf verschiedene Datentypen bietet. Die Google Health API verwendet eine neue Console für die Registrierung von Apps, Google OAuth 2.0, neue Datentypen, ein neues Endpunktschema und ein neues Antwortformat.

Dieser Leitfaden soll Entwicklern helfen, ihre vorhandenen Fitbit Web API-Apps zur neuen Google Health API zu migrieren. Er enthält Empfehlungen für eine nahtlose Migration, bei der Nutzer nicht verloren gehen.

Warum sollten Sie migrieren?

Dies ist nicht nur ein Update, sondern ein strategischer Schritt, um sicherzustellen, dass Ihre Apps sicher sind und für zukünftige Fortschritte in der Gesundheitstechnologie bereit sind. Einige der Vorteile der Google Health API sind:

  • Zugriff auf umfassende Daten: Sie erhalten robusten Zugriff auf eine Vielzahl von Gesundheitsdaten von Nutzern mit Einwilligung und auf verschiedene Datentypen.
  • Verbesserte Sicherheit: Einhaltung der Best Practices für die Sicherheit von Google, die mit den Sicherheits-, Datenschutz- und Identitätsstandards von Google übereinstimmen.
  • Konsistenz: Beseitigt Legacy-Inkonsistenzen in Datenformaten, Zeit zonen, Maßeinheiten und der Fehlerbehandlung für eine intuitivere Entwickler erfahrung.
  • Skalierbarkeit und Zukunftssicherheit: Die API ist so konzipiert, dass sie zukünftigen Anforderungen gerecht wird, und unterstützt moderne Protokolle wie gRPC.

Die Umstellung von der Fitbit Web API zur Google Health API umfasst mehr als nur technische Änderungen. Aufgrund der Umstellung auf eine neue OAuth-Bibliothek können vorhandene Zugriffs- und Aktualisierungstokens nicht übertragen werden. Nutzer müssen daher der aktualisierten Integration noch einmal zustimmen.

Beide Anmeldemethoden unterstützen

Da die Fitbit Web API und die Google Health API unterschiedliche Systeme für die Verarbeitung von Nutzeranmeldungen verwenden, muss Ihre App vorübergehend beide Methoden gleichzeitig unterstützen, solange die Fitbit Web APIs noch aktiv sind.

Implementieren Sie eine Ebene, die entscheidet, ob für einen bestimmten Nutzer die Fitbit Web API oder die Google Health API verwendet werden soll, anstatt dass Ihre App direkt Daten anfordert. So müssen sich die anderen Teile Ihrer App nicht um die Details kümmern.

Aktualisieren Sie Ihre Nutzerdatenbank, um ein Flag (z. B. oauth_type) hinzuzufügen, mit dem Sie erkennen können, welches Anmeldesystem verwendet wird.

  • Neue Nutzer: Richten Sie sie automatisch mit der neuen Google Health API ein (oauth_type: google).
  • Vorhandene Nutzer: Sie können die Fitbit Web API weiterhin verwenden, bis sie ihre Einwilligung aktualisieren (oauth_type: fitbit).

Um die Nutzererfahrung nicht zu beeinträchtigen, empfehlen wir, Nutzer nicht zum Ab- und wieder Anmelden zu zwingen. Gehen Sie stattdessen so vor:

  1. Wenn ein Nutzer, der weiterhin mit den Fitbit Web APIs verbunden ist, mit Ihrer App interagiert, zeigen Sie ihm eine freundliche Benachrichtigung an, in der er aufgefordert wird, die Verbindung zu aktualisieren.
  2. Wenn der Nutzer die Aktualisierung akzeptiert, lösen Sie sofort den Google Health-Anmeldevorgang aus.
  3. Sobald die Google-Anmeldung erfolgreich war, speichern Sie die neuen Google-Anmeldedaten im Profil des Nutzers und ändern Sie das Flag oauth_type von fitbit zu google. Wenn Ihre Einrichtung dies zulässt, melden Sie den Nutzer programmatisch vom alten Fitbit System ab, indem Sie seine Tokens widerrufen, um alles übersichtlich und sicher zu halten.

Datenkontinuität sicherstellen

Bei der Umstellung einer Integration von der Legacy-Fitbit Web API zur Google Health API müssen Entwickleranwendungen eine Änderung der Nutzeridentifikationsstrukturen berücksichtigen.

Die Legacy-Fitbit Web API identifiziert Konten mit einer alphanumerischen Zeichenfolge mit 6 Zeichen (z. B. A1B2C3), während die Google Health API eine healthUserId verwendet, die als String mit bis zu 63 Ziffern und Zeichen formatiert ist.

Um diese Lücke zu schließen, ohne den Nutzerkontext zu verlieren, können Entwickler den getIdentity Endpunkt abfragen, um die Fitbit- und Health-Nutzer IDs zu erhalten. Dieser Endpunkt gibt eine Nutzlast zurück, die sowohl die legacyUserId als auch die neue healthUserId enthält. So können Anwendungen dynamisch eine Zuordnung zwischen vorhandenen Datensätzen und dem neuen Kontosystem erstellen.

Backfill für Verlaufsdaten

Wenn sich ein Nutzer nicht bei den neuen Google Health API-Endpunkten authentifiziert, bevor die Legacy-Endpunkte deaktiviert werden, sind seine Daten weiterhin verfügbar, solange er sein Gerät mit der Google Health App synchronisiert. Es kann jedoch eine Lücke in den Daten dieses Nutzers geben.

Sobald sich der Nutzer bei den neuen Endpunkten neu authentifiziert hat, können Sie mit unserer Google Health API seine Verlaufsdaten backfillen. Weitere Informationen finden Sie unter Verlaufsdaten abfragen.

Kommunikation und Timing

Folgen Sie diesen Best Practices, um Ihren Nutzern die Umstellung von ihrem vorhandenen Fitbit OAuth zu Google OAuth zu erleichtern.

Kommunikation mit Fokus auf den Mehrwert

Beginnen Sie nicht mit „Wir haben unsere API aktualisiert“, sondern mit den Vorteilen der Integration von Google Health-Daten in Ihre App. Machen Sie aber deutlich, dass sich Nutzer neu authentifizieren müssen, wenn ihre Daten synchronisiert werden sollen:

  • Erklären Sie deutlich, welche Funktionen in Ihrer App durch die Integration unterstützt werden, und passen Sie Ihre Nachricht so an, dass der Nutzer den Nutzen dieser Funktionen erkennt.
  • Konzentrieren Sie sich auf Ihre Funktionen und geben Sie Anwendungsfälle anstelle von technischen Implementierungsdetails an.
  • Falsch : „Sie können keine Verbindung zur Fitbit API herstellen.“
  • Richtig: „Wenn Sie weiterhin detaillierte Trainingseinheiten mit Herzfrequenzdaten sehen möchten, stimmen Sie den Google Health APIs noch einmal zu.“

Wann Nutzer benachrichtigen?

Halten Sie sich in der gesamten Nutzerkommunikation an die Google Health-Markenrichtlinien, und verwenden Sie Banner, Karten oder Benachrichtigungen, die geschlossen werden können.

  • Lösen Sie den Bildschirm für die erneute Einwilligung nicht aus, während ein Nutzer gerade trainiert oder etwas manuell protokolliert.
  • Machen Sie die erneute Einwilligung erst nach mehreren Wochen mit Warnungen obligatorisch, und zwar gleichzeitig mit den offiziellen Fristen für die Einstellung der Fitbit Web API.
  • Wenn ein Nutzer nach dem endgültigen Stichtag keine erneute Einwilligung erteilt hat, bieten Sie einen reibungslosen Wiederherstellungspfad an. Geben Sie in einem Banner, Karte oder Tooltip eine Hilfemeldung an, die dem Nutzer erklärt, warum seine Daten fehlen und wie er das Problem beheben kann.