L'API Google Health è una nuova API creata da zero che consente agli sviluppatori di eseguire query sui dati utente di 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 la registrazione delle app, il supporto di Google OAuth 2.0, nuovi tipi di dati, un nuovo schema di 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 preparazione per il futuro: progettata per scalare in base alle 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. Gli utenti devono dare nuovamente il consenso alla nuova integrazione a causa della modifica della libreria OAuth. Non è possibile trasferire i token di accesso e i token di aggiornamento all'API Google Health e farli funzionare. Per aiutarti a fidelizzare gli utenti durante la migrazione, ecco alcuni suggerimenti tecnici e strategici per una migrazione riuscita.
La 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.
Gestione parallela delle autorizzazioni
- Incapsula i client: crea un livello di astrazione o un'interfaccia per il tuo "servizio sanitario". In questo modo, il resto dell'app può richiedere i dati senza sapere quale libreria (Fitbit OAuth o Google OAuth) è attiva per l'utente specifico.
- Aggiornamento dello schema del database: aggiorna la tabella utente in modo da includere un
oauth_typeflag. Ad esempio, utilizzafitbitper Fitbit OAuth egoogleper Google OAuth.- Nuovi utenti: per impostazione predefinita, utilizza l'API Google Health e la libreria Google OAuth. Imposta
oauth_typesugoogle. - Utenti esistenti: mantieni l'API Fitbit Web finché non completano
il flusso di consenso. Imposta
oauth_typesufitbit.
- Nuovi utenti: per impostazione predefinita, utilizza l'API Google Health e la libreria Google OAuth. Imposta
Il flusso di consenso "step-up"
Anziché forzare la disconnessione, utilizza un approccio di autorizzazione incrementale:
- Rileva il token open source di Fitbit: quando un utente dell'API Fitbit Web apre l'app, attiva una notifica di "Aggiornamento del servizio".
- Avvia il flusso Google OAuth: quando l'utente fa clic su "Aggiorna", avvia il flusso della libreria Google OAuth2.
- Sostituisci e revoca: una volta ricevuto correttamente il token Google OAuth, salvalo nel profilo utente, aggiorna
oauth_typedafitbitagooglee (se possibile) revoca a livello di programmazione il vecchio tokenfitbitper mantenere pulito il profilo di sicurezza dell'utente.
Massimizzare la fidelizzazione degli utenti
Il consenso è la "zona di pericolo" per il churn. Per evitare che gli utenti abbandonino l'app, segui queste best practice UX:
La 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 e l'autenticazione a due fattori leader del settore di Google.
- Affidabilità: tempi di sincronizzazione più rapidi e connessioni dati più stabili.
- Gating delle funzionalità: informa delicatamente gli utenti che i nuovi tipi di dati e funzionalità richiedono l'aggiornamento.
Tempistica intelligente
- Non interrompere le attività di alto valore: non attivare mai la schermata di consenso mentre un utente sta eseguendo un allenamento o registrando il cibo.
- La fase di "nudge": per i primi 30 giorni, utilizza un banner ignorabile.
- La fase di "interruzione definitiva": rendi obbligatorio il consenso solo dopo diverse settimane di avvisi, in concomitanza con le scadenze ufficiali di ritiro dell'API Fitbit Web.
Confronto del flusso di migrazione
Una chiara distinzione visiva tra i flussi vecchi e nuovi aiuta gli sviluppatori a capire dove si dirama la logica.
| Funzionalità | API Fitbit Web (legacy) | API Google Health (identità Google) |
| Libreria di autenticazione | Open source standard | Servizi di identità Google (GIS) / Autenticazione Google |
| Account utente | Credenziali legacy di Fitbit | Account Google |
| Tipo di token | Accesso / aggiornamento specifico di Fitbit | Token di accesso/aggiornamento emessi da Google |
| Gestione degli ambiti | Autorizzazioni ampie | Autorizzazioni granulari / incrementali |
Gestire la sfumatura 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 con errori "Non autorizzato". Questo potrebbe indicare che l'utente ha eseguito la migrazione del proprio account, ma la tua app non è stata aggiornata.
- Errori graduali: se una chiamata Fitbit OAuth non va a buon fine, reindirizza l'utente a una pagina personalizzata "Riconnetti Fitbit" che utilizza specificamente il nuovo flusso Google OAuth.