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 Perfiles y utilizarlo en la API del lado del servidor, que se enviará a todas las integraciones.

Configurar el ID de usuario en la inicialización

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

using UnityEngine;
using AdaptySDK;

var builder = new AdaptyConfiguration.Builder("YOUR_API_KEY")
    .SetCustomerUserId("YOUR_USER_ID");

Adapty.Activate(builder.Build(), (error) => {
    if (error != null) {
        // handle the error
        return;
    }
}); 

Establecer el ID de usuario después de la configuración

Si no tienes un ID de usuario en la configuración del SDK, puedes establecerlo en cualquier momento con el método .identify(). Los casos más comunes para usar este método son tras el 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
  }
});

Parámetros de la solicitud:

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

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
  }
});

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 tu usuario. StoreKit asocia este token con 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 permanezcan correctamente vinculadas. Puedes configurar el token de dos formas: durante la activación del SDK o al identificar al usuario.

using UnityEngine;
using AdaptySDK;
using System;

// During configuration:
var appAccountToken = new Guid("YOUR_APP_ACCOUNT_TOKEN");
var builder = new AdaptyConfiguration.Builder("YOUR_API_KEY")
    .SetCustomerUserId("YOUR_USER_ID", appAccountToken);

Adapty.Activate(builder.Build(), (error) => {
    if (error != null) {
        // handle the error
        return;
    }
}); 

// Or when identifying users
Adapty.Identify("YOUR_USER_ID", appAccountToken, (error) => {
    if (error == null) {
        // successful identify
    }
});

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 compras sin exponer información del usuario, lo que es especialmente importante para la prevención de fraude y los análisis.

Es posible que necesites establecer estos IDs si tu app maneja datos sensibles de usuarios o si debes cumplir con normativas de privacidad específicas. Los IDs ofuscados permiten a Google Play rastrear compras sin revelar los identificadores reales de los usuarios.

using UnityEngine;
using AdaptySDK;

// Durante la configuración:
var builder = new AdaptyConfiguration.Builder("YOUR_API_KEY")
    .SetCustomerUserId("YOUR_USER_ID", null, "YOUR_OBFUSCATED_ACCOUNT_ID");

Adapty.Activate(builder.Build(), (error) => {
    if (error != null) {
        // manejar el error
        return;
    }
});

// O al identificar usuarios
Adapty.Identify("YOUR_USER_ID", null, "YOUR_OBFUSCATED_ACCOUNT_ID", (error) => {
    if (error == null) {
        // identificación exitosa
    }
});

Detectar usuarios en múltiples 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.