A API Google Health é uma nova API criada do zero que permite aos desenvolvedores consultar dados do usuário do Fitbit. Essa não é apenas uma atualização, mas uma mudança estratégica para garantir que seus apps sejam seguros, confiáveis e estejam prontos para futuros avanços na tecnologia de saúde. A API é compatível com um novo console para registrar seus apps, suporte ao OAuth 2.0 do Google, novos tipos de dados, novo esquema de endpoint e novo formato de resposta.
O guia foi criado para ajudar os desenvolvedores a migrar os apps da API Fitbit Web para a nova API Google Health.
Por que migrar?
Os benefícios de usar a API Google Health são:
- Segurança aprimorada: compliance com as práticas recomendadas de segurança do Google, alinhamento com os padrões de segurança, privacidade e identidade do Google.
- Consistência: elimina inconsistências legadas em formatos de dados, fusos horários, unidades de medida e tratamento de erros para uma experiência de desenvolvedor mais intuitiva.
- Escalonabilidade e preparação para o futuro: projetado para escalonar e atender às demandas futuras e compatível com protocolos modernos, como o gRPC.
Migrar seus usuários
Migrar da API Fitbit Web para a API Google Health é mais do que uma atualização técnica. Seus usuários precisam dar consentimento novamente para a nova integração devido à mudança na biblioteca OAuth. Não é possível transferir tokens de acesso e atualização para a API Google Health e fazer com que eles funcionem. Para ajudar na retenção de usuários durante a migração, confira algumas sugestões técnicas e estratégicas para uma migração bem-sucedida.
A estratégia de biblioteca dupla
Como a API Fitbit Web e a API Google Health usam bibliotecas OAuth2 diferentes, é necessário gerenciar um período de "ponte" em que as duas bibliotecas existem na sua base de código.
Gerenciamento de autorização paralela
- Encapsular clientes: crie uma camada de abstração ou interface para seu "Serviço de saúde". Isso permite que o restante do app solicite dados sem saber qual biblioteca (OAuth do Fitbit ou do Google) está ativa para aquele usuário específico.
- Atualização do esquema do banco de dados: atualize sua tabela de usuários para incluir uma flag
oauth_type. Por exemplo, usefitbitpara o OAuth do Fitbit egooglepara o OAuth do Google.- Novos usuários: padrão para a API Google Health e a biblioteca
Google OAuth. Defina
oauth_typecomogoogle. - Usuários atuais: mantenha na API Fitbit Web até que concluam
o fluxo de novo consentimento. Defina
oauth_typecomofitbit.
- Novos usuários: padrão para a API Google Health e a biblioteca
Google OAuth. Defina
Fluxo de novo consentimento "Step-Up"
Em vez de forçar um logout, use uma abordagem de autorização incremental:
- Detectar token de código aberto do Fitbit: quando um usuário da API Fitbit Web abrir o app, acione uma notificação de "Atualização do serviço".
- Iniciar o fluxo do Google OAuth: quando o usuário clicar em "Atualizar", inicie o fluxo da biblioteca do Google OAuth2.
- Substituir e revogar: depois que o token OAuth do Google for recebido, salve-o no perfil do usuário, atualize o
oauth_typedefitbitparagooglee, se possível, revogue programaticamente o tokenfitbitantigo para manter o perfil de segurança do usuário limpo.
Maximizar a retenção de usuários
A renovação do consentimento é a "zona de perigo" para o churn. Para evitar que os usuários abandonem o app, siga estas práticas recomendadas de UX:
A comunicação "Prioridade ao valor"
Não comece com "Atualizamos nossa API". Comece com os benefícios do novo sistema com tecnologia do Google:
- Segurança reforçada: mencione a proteção de conta e a autenticação de dois fatores (2FA) líderes do setor do Google.
- Confiabilidade: tempos de sincronização mais rápidos e conexões de dados mais estáveis.
- Controle de recursos: informe aos usuários que novos recursos e tipos de dados exigem a atualização.
Programação inteligente
- Não interrompa tarefas de alto valor: nunca acione a tela de novo consentimento enquanto um usuário estiver no meio de um treino ou registrando alimentos.
- A fase de "sugestão": nos primeiros 30 dias, use um banner dispensável.
- Fase de corte definitivo: só torne o novo consentimento obrigatório após várias semanas de avisos, coincidindo com os prazos oficiais de descontinuação da API Fitbit Web.
Comparação do fluxo de migração
Uma distinção visual clara entre os fluxos antigos e novos ajuda os desenvolvedores a entender onde a lógica se ramifica.
| Recurso | API Fitbit Web (legada) | API Google Health (Google-Identity) |
| Biblioteca de autenticação | Código aberto padrão | Serviços de Identificação do Google (GIS) / autenticação do Google |
| Contas de usuário | Credenciais legadas do Fitbit | Conta do Google |
| Tipo de token | Acesso / atualização específicos do Fitbit | Tokens de acesso/atualização emitidos pelo Google |
| Gerenciamento de escopo | Permissões amplas | Permissões granulares / incrementais |
Lidar com a nuance da migração de contas
De acordo com a documentação do Fitbit, os usuários que migram a conta para o Google geralmente não perdem as conexões de terceiros imediatamente, mas a mudança da versão da API é uma exigência do desenvolvedor.
- Verificar a validade do token: use um backgroundworker para verificar se os tokens do Fitbit estão falhando com erros "Não autorizado". Isso pode indicar que o usuário migrou a conta, mas o app ainda não foi atualizado.
- Falhas normais: se uma chamada OAuth do Fitbit falhar, redirecione o usuário para uma página personalizada "Reconectar o Fitbit" que usa especificamente o novo fluxo OAuth do Google.