Panoramica

L'API Google Health è una nuova API creata da zero che consente agli sviluppatori di eseguire query sui dati utente Fitbit. Non si tratta solo di un aggiornamento, ma di una mossa strategica per garantire che le tue app siano sicure, affidabili e pronte per i futuri progressi della tecnologia sanitaria. L'API supporta una nuova console per registrare le tue app, il supporto di Google OAuth 2.0, nuovi tipi di dati, nuovi schemi degli endpoint e un nuovo formato di risposta.

La guida è progettata per aiutare gli sviluppatori a eseguire la migrazione delle app API Fitbit Web esistenti alla nuova API Google Health.

Perché dovresti eseguire la migrazione?

I vantaggi dell'utilizzo dell'API Google Health sono:

  • Sicurezza avanzata: conformità alle best practice di sicurezza di Google, in linea con gli standard di sicurezza, privacy e identità di Google.
  • Coerenza: elimina le incoerenze legacy nei formati dei dati, nei fusi orari, nelle unità di misura e nella gestione degli errori per un'esperienza di sviluppo più intuitiva.
  • Scalabilità e a prova di futuro: progettato per scalare in modo da soddisfare le esigenze future e supporta protocolli moderni come gRPC.

Eseguire la migrazione degli utenti

La migrazione dall'API Fitbit Web all'API Google Health è più di un aggiornamento tecnico. I tuoi utenti devono dare nuovamente il consenso alla nuova integrazione a causa della modifica della libreria OAuth. Non è possibile trasferire i token di accesso e di aggiornamento all'API Google Health e farli funzionare. Per favorire la fidelizzazione degli utenti durante la migrazione, ecco alcuni suggerimenti tecnici e strategici per una migrazione riuscita.

Strategia a doppia libreria

Poiché l'API Fitbit Web e l'API Google Health utilizzano librerie OAuth2 diverse, devi gestire un periodo di "bridging" in cui entrambe le librerie esistono nel tuo codebase.

Parallel Authorization Management

  • Encapsulate Clients: crea un livello di astrazione o un'interfaccia per il tuo "servizio sanitario". In questo modo, il resto dell'app può richiedere dati senza sapere quale libreria (OAuth Fitbit o OAuth Google) è attiva per quello specifico utente.
  • Aggiornamento dello schema del database: aggiorna la tabella degli utenti in modo che includa un flag oauth_type. Ad esempio, usa fitbit per Fitbit OAuth e google per Google OAuth.
    • Nuovi utenti: impostazione predefinita dell'API Google Health e della libreria Google OAuth. Imposta oauth_type su google.
    • Utenti esistenti: continua a utilizzare l'API Fitbit Web fino al completamento del flusso di consenso. Imposta oauth_type su fitbit.

Flusso di riacquisizione del consenso "Step-Up"

Invece di forzare la disconnessione, utilizza un approccio di autorizzazione incrementale:

  1. Detect Fitbit Open Source Token: quando un utente dell'API Fitbit Web apre l'app, attiva una notifica "Aggiornamento del servizio".
  2. Avvia il flusso OAuth di Google: quando l'utente fa clic su "Aggiorna", avvia il flusso della libreria OAuth2 di Google.
  3. Sostituisci e revoca: una volta ricevuto correttamente il token Google OAuth, salvalo nel profilo utente, aggiorna oauth_type da fitbit a google e (se possibile) revoca a livello di programmazione il vecchio token fitbit per mantenere pulito il profilo di sicurezza dell'utente.

Massimizzare la fidelizzazione degli utenti

Il nuovo consenso è la "zona di pericolo" per l'abbandono. Per evitare che gli utenti abbandonino l'app, segui queste best practice UX:

Comunicazione "Value-First"

Non iniziare con "Abbiamo aggiornato la nostra API". Inizia con i vantaggi del nuovo sistema supportato da Google:

  • Sicurezza avanzata: menziona la protezione dell'account leader del settore di Google e l'autenticazione a due fattori.
  • Affidabilità: tempi di sincronizzazione più rapidi e connessioni dati più stabili.
  • Feature Gating: informa gli utenti che i nuovi tipi di dati e le nuove funzionalità richiedono l'aggiornamento.

Smart Timing

  • Non interrompere le attività di alto valore: non attivare mai la schermata per il consenso mentre un utente si sta allenando o sta registrando alimenti.
  • Fase "Sollecito": per i primi 30 giorni, utilizza un banner ignorabile.
  • Fase di "interruzione definitiva": rendi obbligatorio il nuovo consenso solo dopo diverse settimane di avvisi, in concomitanza con le scadenze ufficiali per il ritiro dell'API Fitbit Web.

Confronto del flusso di migrazione

Una chiara distinzione visiva tra i flussi precedenti e quelli nuovi aiuta gli sviluppatori a capire dove si dirama la logica.

Funzionalità API Fitbit Web (legacy) API Google Health (Google-Identity)
Libreria di autenticazione Standard open source Servizi di identità Google (GIS) / Google Auth
Account utente Credenziali legacy di Fitbit Account Google
Tipo di token Accesso / aggiornamento specifico per Fitbit Token di accesso/aggiornamento emessi da Google
Gestione dell'ambito Autorizzazioni generiche Autorizzazioni granulari / incrementali

Gestire le sfumature della migrazione dell'account

Secondo la documentazione di Fitbit, gli utenti che eseguono la migrazione del proprio account a Google in genere non perdono immediatamente le connessioni di terze parti, ma la modifica della versione dell'API è un requisito lato sviluppatore.

  • Controlla la validità del token: utilizza un backgroundworker per verificare se i token Fitbit non funzionano e restituiscono errori "Non autorizzato". Ciò potrebbe indicare che l'utente ha eseguito la migrazione del proprio account, ma la tua app non è ancora aggiornata.
  • Errori controllati: se una chiamata OAuth di Fitbit non va a buon fine, reindirizza l'utente a una pagina personalizzata "Riconnetti Fitbit" che utilizza in modo specifico il nuovo flusso OAuth di Google.