---
title: "Identificar usuarios en el SDK de React Native"
description: "Aprende cómo identificar usuarios en tu app de React Native con el SDK de Adapty."
---

Adapty crea un ID de perfil interno para cada usuario. Sin embargo, si tienes tu propio sistema de autenticación, debes establecer tu propio Customer User ID. Puedes encontrar usuarios por su Customer User ID en la sección [Perfiles](profiles-crm) y usarlo en la [API del lado del servidor](getting-started-with-server-side-api), que se enviará a todas las integraciones.
### Establecer el ID de usuario en la configuración \{#setting-customer-user-id-on-configuration\}

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

```typescript showLineNumbers
adapty.activate("PUBLIC_SDK_KEY", {
    customerUserId: "YOUR_USER_ID"
});
```

:::tip

¿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](sample-apps), que muestran la configuración completa, incluyendo la visualización de paywalls, la realización de compras y otras funcionalidades básicas.

:::
### Configurar el ID de usuario del cliente tras la configuración \{#setting-customer-user-id-after-configuration\}

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 después del registro o la autenticación, cuando el usuario pasa de ser anónimo a estar autenticado.

```typescript showLineNumbers
try {
    await adapty.identify("YOUR_USER_ID");
    // successfully identified
} catch (error) {
    // handle the error
}
```

Parámetros de la solicitud:

- **Customer User ID** (obligatorio): un identificador de usuario de tipo string.
:::warning
Reenvío de datos significativos del usuario

En algunos casos, como cuando un usuario vuelve a iniciar sesión en su cuenta, 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, deberás reenviar 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 \{#logging-out-and-logging-in\}

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

```typescript showLineNumbers
try {
    await adapty.logout();
    // successful logout
} catch (error) {
    // handle the error
}
```

Luego puedes iniciar sesión del usuario usando el método `.identify()`.
## Asignar `appAccountToken` (iOS) \{#assign-appaccounttoken-ios\}

[`appAccountToken`](https://developer.apple.com/documentation/storekit/product/purchaseoption/appaccounttoken(_:)) es un **UUID** que te permite vincular las transacciones del App Store con la identidad interna de tus usuarios.  
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 queden correctamente vinculadas.
Puedes establecer el token de dos maneras: durante la activación del SDK o al identificar al usuario.

:::important
Siempre debes pasar `appAccountToken` junto con `customerUserId`.
Si solo pasas el token, no se incluirá en la transacción.
:::
```typescript showLineNumbers
// Durante la configuración:
adapty.activate("PUBLIC_SDK_KEY", {
    customerUserId: "YOUR_USER_ID",
    ios: { appAccountToken: "YOUR_APP_ACCOUNT_TOKEN" },
});

// O al identificar usuarios
try {
    await adapty.identify("YOUR_USER_ID", {
        ios: {appAccountToken: 'YOUR_APP_ACCOUNT_TOKEN'}
    });
    // identificado correctamente
} catch (error) {
    // gestiona el error
}
```
### Establecer IDs de cuenta ofuscados (Android) \{#set-obfuscated-account-ids-android\}

Google Play requiere IDs de cuenta ofuscados en ciertos casos de uso para mejorar la privacidad y seguridad del usuario. 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 de datos.

Es posible que necesites establecer estos IDs si tu aplicación maneja datos de usuario sensibles o si debes cumplir con normativas de privacidad específicas. Los IDs ofuscados permiten a Google Play hacer seguimiento de las compras sin exponer los identificadores reales de los usuarios.
```typescript showLineNumbers
// Durante la configuración:
adapty.activate("PUBLIC_SDK_KEY", {
    customerUserId: "YOUR_USER_ID",
    android: { obfuscatedAccountId: 'YOUR_OBFUSCATED_ACCOUNT_ID' }
});

// O al identificar usuarios
try {
    await adapty.identify("YOUR_USER_ID", {
        android: { obfuscatedAccountId: 'YOUR_OBFUSCATED_ACCOUNT_ID' }
    });
    // identificado correctamente
} catch (error) {
    // gestionar el error
}
```
## Detectar usuarios en varios dispositivos \{#detect-users-across-devices\}

---
no_index: true
---

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](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](sharing-paid-access-between-user-accounts) 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.