Identificar usuarios en el SDK de Android

Adapty crea un ID de perfil interno para cada usuario. Sin embargo, si tienes tu propio sistema de autenticación, deberías definir tu propio Customer User ID. Puedes buscar usuarios por su Customer User ID en la sección Perfiles y usarlo en la API server-side, que se enviará a todas las integraciones.

Configurar el ID de usuario en la configuración

Si tienes un ID de usuario durante la configuración, pásalo directamente como parámetro customerUserId al método .activate():

Adapty.activate(applicationContext, "PUBLIC_SDK_KEY", customerUserId = "YOUR_USER_ID")

¿Quieres ver un ejemplo real de cómo se integra el SDK de Adapty en una app móvil? Echa un vistazo a nuestras apps de ejemplo, que muestran la configuración completa, incluyendo la visualización de paywalls, la realización de compras y otras funcionalidades básicas.

Establecer el ID de usuario personalizado tras la configuración

Si no tienes un ID de usuario en la configuración del SDK, puedes establecerlo más tarde en cualquier momento con el método .identify(). Los casos más habituales para usar este método son después del registro o la autenticación, cuando el usuario pasa de ser anónimo a estar autenticado.

Adapty.identify("YOUR_USER_ID") { error ->
    if (error == null) {
        // successful identify
    }
}

Adapty.identify("YOUR_USER_ID", error -> {
    if (error == null) {
        // successful identify
    }
});

Parámetros de la solicitud:

Customer User ID (obligatorio): un identificador de usuario de tipo string.

Reenvío de datos significativos del usuario En algunos casos, como cuando un usuario inicia sesión en su cuenta de nuevo, los servidores de Adapty ya tienen información sobre ese usuario. En estos escenarios, el SDK de Adapty cambiará automáticamente para trabajar con el nuevo usuario. Si pasaste algún dato al usuario anónimo, como atributos personalizados o atribuciones de redes de terceros, debes volver a enviar esos datos para el usuario identificado.

También es importante tener en cuenta que debes volver a solicitar todos los paywalls y productos después de identificar al usuario, ya que los datos del nuevo usuario pueden ser diferentes.

Cerrar sesión e iniciar sesión

Puedes cerrar la sesión del usuario en cualquier momento llamando al método .logout():

Adapty.logout { error ->
    if (error == null) {
        // successful logout
    }
}

Adapty.logout(error -> {
    if (error == null) {
        // successful logout
    }
});

Luego puedes iniciar sesión con el usuario usando el método .identify().

Detectar usuarios en varios dispositivos

Cuando el SDK se activa, lee automáticamente los derechos existentes del usuario desde StoreKit (iOS) o Google Play Billing (Android) y los sincroniza con el backend de Adapty. Una suscripción activa aparece en el perfil de Adapty sin que la app llame a restorePurchases.

Lo que no ocurre automáticamente es reconocer que un perfil en un dispositivo nuevo pertenece al mismo usuario que el perfil en el dispositivo original. Adapty relaciona perfiles por Customer User ID, así que la continuidad de identidad depende de lo que uses como CUID.

Lo que Adapty puede detectar entre dispositivos

Tu configuración	Lo que Adapty detecta	Lo que debes hacer
Customer User ID = `device_id` (sin login en la app)	El nuevo dispositivo obtiene un CUID diferente y, por tanto, un perfil diferente. La suscripción se sincroniza con el nuevo perfil mediante un evento Access level updated, pero `subscription_started` no se dispara — el nuevo perfil se trata como heredero de la compra original. Los análisis basados en `subscription_started` contarán de menos a los usuarios que vuelven.	Usa un ID de cuenta estable como Customer User ID para que un usuario que regresa coincida con el perfil existente en todos los dispositivos.
Customer User ID = ID de cuenta estable (login en cada dispositivo)	El SDK sincroniza automáticamente la suscripción en `activate()`, e `identify()` relaciona el perfil existente por CUID.	No se necesita configuración adicional — tanto la identidad como la suscripción se resuelven automáticamente.
Heredero de Apple Family Sharing	El miembro de la familia recibe la suscripción solo a través de un evento Access level updated — `subscription_started` no se dispara.	Escucha el evento Access level updated. Consulta Apple Family Sharing para ver la matriz de eventos completa.
Misma cuenta de Apple/Google, distintos usuarios dentro de la app	El primer perfil que registra la compra se convierte en el principal. Los perfiles posteriores ven la suscripción a través de una cadena de herederos, con un evento Access level updated.	Exige login y elige un modo de compartición que se adapte a tu modelo.

Restaurar compras en un dispositivo nuevo

Muestra un botón “Restaurar compras” iniciado por el usuario en tu paywall. Apple App Review (directriz 3.1.1) lo exige, y actúa como alternativa cuando la sincronización automática no cubre algún caso límite. El botón debe llamar a restorePurchases en tu SDK.

No es necesario llamar a restorePurchases de forma programática al primer inicio para el uso normal — el SDK ya ejecuta el equivalente en activate(). Reserva las llamadas programáticas para forzar una verificación de recibo actualizada, por ejemplo al depurar un acceso que falta después de que activate() haya completado.