Adapty crea un ID de perfil interno para cada usuario. Sin embargo, si tienes tu propio sistema de autenticación, deberías establecer tu propio Customer User ID. Puedes encontrar usuarios por su Customer User ID en la sección de Perfiles y utilizarlo en la API del lado del servidor, que se enviará a todas las integraciones.

Establecer el ID de usuario del cliente en la configuración

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

try {
  await adapty.activate({
    apiKey: 'YOUR_PUBLIC_SDK_KEY',
    params: {
      customerUserId: 'YOUR_USER_ID'
    }
  });
} catch (error) {
  console.error('Failed to activate Adapty:', error);
}

Establecer el ID de usuario tras la configuración

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

try {
  await adapty.identify({ customerUserId: 'YOUR_USER_ID' });
  console.log('User identified successfully');
} catch (error) {
  console.error('Failed to identify user:', error);
}

Parámetros de la solicitud:

Parámetro	Presencia	Descripción
customerUserId	obligatorio	Identificador de usuario en formato string.

Cerrar sesión e iniciar sesión

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

try {
  await adapty.logout();
  console.log('User logged out successfully');
} catch (error) {
  console.error('Failed to logout user:', error);
}

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

Asignar appAccountToken (iOS)

appAccountToken es un UUID que te permite vincular las transacciones del App Store con la identidad interna de tus usuarios.
StoreKit asocia este token a cada transacción, de modo que tu backend puede relacionar los datos del App Store con tus usuarios.

Usa un UUID estable generado por usuario y reutilízalo para la misma cuenta en todos los dispositivos. Así te aseguras de que las compras y las notificaciones del App Store queden correctamente vinculadas. Puedes establecer el token de dos maneras: durante la activación del SDK o al identificar al usuario.

// Durante la configuración:
await adapty.activate({
    apiKey: 'YOUR_PUBLIC_SDK_KEY',
    params: {
        customerUserId: 'YOUR_USER_ID',
        ios: { appAccountToken: "YOUR_APP_ACCOUNT_TOKEN" },
    }
});
// O al identificar usuarios
await adapty.identify({
    customerUserId: 'YOUR_USER_ID',
    params: {
        ios: { appAccountToken: 'YOUR_APP_ACCOUNT_TOKEN' },
    }
});

Establecer IDs de cuenta ofuscados (Android)

Google Play requiere IDs de cuenta ofuscados en ciertos casos de uso para mejorar la privacidad y seguridad de los usuarios. Estos IDs ayudan a Google Play a identificar las compras manteniendo el anonimato de la información del usuario, lo que resulta especialmente importante para la prevención del fraude y el análisis.

Es posible que necesites configurar estos IDs si tu aplicación maneja datos sensibles de los usuarios o si debes cumplir con normativas de privacidad específicas. Los IDs ofuscados permiten a Google Play rastrear las compras sin exponer los identificadores reales de los usuarios.

// Durante la configuración:
await adapty.activate({
  apiKey: 'YOUR_PUBLIC_SDK_KEY',
  params: {
    android: { obfuscatedAccountId: 'YOUR_OBFUSCATED_ACCOUNT_ID' },
  }
});
// O al identificar usuarios
await adapty.identify({
    customerUserId: 'YOUR_USER_ID',
    params: {
        android: { obfuscatedAccountId: 'YOUR_OBFUSCATED_ACCOUNT_ID' },
    }
});

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.