SDK de Android - Configurar un ID de usuario y User Details hasheados

Seguir
Avatar
Jared Ornstead
Updated

Configurar un ID de usuario y User Details hasheados

Envíe su ID de usuario interno a Singular para habilitar el tracking entre dispositivos y los reportes de datos a nivel de usuario.

Nota: Si utiliza la solución entre dispositivos de Singular , debe recopilar el ID de usuario en todas las plataformas.

Requisitos del ID de usuario

Privacidad y mejores prácticas

Siga estas pautas al implementar el tracking del ID de usuario para garantizar el cumplimiento de privacidad y una medición entre dispositivos adecuada.

  • Sin PII: El ID de usuario no debe exponer información de identificación personal (PII) como direcciones de email, nombres de usuario o números de teléfono. Use un valor hash único de sus datos propios. Para enviar una dirección de correo electrónico o un número de teléfono, use en su lugar la API dedicada de User Details hasheados.
  • Consistencia entre plataformas: El valor del ID de usuario debe ser el mismo identificador interno que captura en todas las plataformas (Web/Mobile/PC/Console/Offline) para una medición precisa entre dispositivos.
  • Datos propios: Singular incluye el ID de usuario en exportaciones a nivel de usuario, ETL y postbacks de BI internos (si están configurados). El ID de usuario es dato propio y no se comparte con terceros.
  • Persistencia: El ID de usuario persiste hasta que se desconfigure explícitamente con unsetCustomUserId() o hasta que la aplicación se desinstale. Cerrar o reiniciar la aplicación no borra el ID de usuario.

Resumen de la implementación

Cuándo configurar el ID de usuario

Use setCustomUserId() para establecer el identificador de usuario y unsetCustomUserId() para borrarlo durante el cierre de sesión.

Mejor práctica: Si varios usuarios comparten un mismo dispositivo, implemente un flujo de cierre de sesión que llame a setCustomUserId() al iniciar sesión y a unsetCustomUserId() al cerrar sesión.

Si ya conoce el ID de usuario cuando la aplicación se abre, llame a setCustomUserId() antes de inicializar el Singular SDK. Esto garantiza que Singular reciba el ID de usuario desde la primera sesión. Sin embargo, el ID de usuario suele no estar disponible hasta que el usuario se registra o inicia sesión, en cuyo caso llame a setCustomUserId() después de que se complete el flujo de registro o autenticación.

Métodos del SDK

Configurar ID de usuario personalizado

Envíe su ID de usuario interno a Singular para el tracking entre dispositivos y los reportes a nivel de usuario.

Kotlin Java 
// Set the user ID after login or registration
Singular.setCustomUserId("custom_user_id")

Firma del método: 

public static void setCustomUserId(String customUserId);

Desconfigurar ID de usuario personalizado

Borre el ID de usuario cuando el usuario cierre sesión para garantizar un tracking de sesión preciso en dispositivos compartidos por varios usuarios.

Kotlin Java 
// Unset the user ID on logout
Singular.unsetCustomUserId()

Firma del método: 

public static void unsetCustomUserId();

User Details hasheados (correo electrónico y teléfono)

El ID de usuario descrito arriba es su propio identificador opaco. Si además desea enviar la dirección de correo electrónico o el número de teléfono del usuario a Singular, use la API independiente SingularUserDetails. El SDK normaliza y aplica un hash SHA-256 a estos valores en el dispositivo, por lo que la dirección de correo electrónico y el número de teléfono sin procesar nunca se transmiten.

Disponibilidad: Versión 12.16.0 y superiores del SDK de Android. Esta API no está disponible en la versión Kids del SDK.

Elegir un modo de hasheo

Hay dos formas de proporcionar PII. Elija una por usuario y manténgala de forma consistente.

  • Hasheo por el SDK (recomendado): Pase el correo electrónico o el número de teléfono en texto claro. El SDK normaliza el valor, le aplica hash y genera todas las variantes con las que Singular puede hacer matching.
  • Pre-hasheado: Pase valores que usted ya normalizó y hasheó con SHA-256. El SDK los almacena exactamente como se los proporciona y no realiza ningún procesamiento adicional. Use esta opción cuando su app no pueda mantener PII en texto claro en el momento de la llamada.

Importante: Si establece tanto un valor en texto claro como su variante pre-hasheada correspondiente, prevalece el valor pre-hasheado.

Setters de SingularUserDetails

Setter Detalles
setEmail

Modo: Hasheo por el SDK

Dirección de correo electrónico en texto claro. El SDK elimina los espacios y convierte el valor a minúsculas antes de aplicar el hash. Para las direcciones de gmail.com y googlemail.com también genera una segunda variante en la que se eliminan el sufijo +tag y todos los puntos de la parte local.

Ejemplo: user@example.com

setPhoneNumber

Modo: Hasheo por el SDK

Número de teléfono en texto claro. El SDK genera dos variantes: una en formato E.164 que conserva el + inicial y elimina el resto de los caracteres no numéricos, y otra únicamente con dígitos que también elimina el +. Incluya el código de país para que la variante E.164 sea utilizable.

Ejemplo: +15551234567

setEmailSTD

Modo: Pre-hasheado

Hash SHA-256 de la dirección de correo electrónico después de eliminar los espacios y convertirla a minúsculas.

setEmailNoDots

Modo: Pre-hasheado

Hash SHA-256 de la dirección de correo electrónico después de eliminar los espacios, convertirla a minúsculas y quitar el sufijo +tag y todos los puntos de la parte local. Se aplica a las direcciones de tipo Gmail.

setPhoneE164

Modo: Pre-hasheado

Hash SHA-256 del número de teléfono en formato E.164, conservando el + inicial.

setPhoneDigits

Modo: Pre-hasheado

Hash SHA-256 del número de teléfono con todos los caracteres no numéricos eliminados, incluido el + inicial.

Cada setter tiene un getter correspondiente (getEmail, getPhoneNumber, getEmailSTD, getEmailNoDots, getPhoneE164, getPhoneDigits) que devuelve el valor que estableció.

Establecer los User Details en la inicialización

Encadena withUserDetails en tu SingularConfig antes de llamar a Singular.init para que los User Details se adjunten a la primera sesión que envía el SDK.

Kotlin Java 
val userDetails = SingularUserDetails()
userDetails.setEmail("user@example.com")
userDetails.setPhoneNumber("+15551234567")

val config = SingularConfig("SDK KEY", "SDK SECRET")
    .withUserDetails(userDetails)

Singular.init(context, config)

Establecer la PII después de la inicialización

Si la dirección de correo electrónico o el número de teléfono solo se conocen después del inicio de sesión o del registro, llame a setUserDetails en ese momento. A partir de entonces, los valores se adjuntan a todas las sesiones y eventos que envía el SDK.

Kotlin Java 
// Cleartext values, hashed by the SDK
val userDetails = SingularUserDetails()
userDetails.setEmail("user@example.com")
userDetails.setPhoneNumber("+15551234567")
Singular.setUserDetails(userDetails)

// Or supply your own SHA-256 hashes
val hashed = SingularUserDetails()
hashed.setEmailSTD("b4c9a289323b21a01c3e940f150eb9b8c542587f1abfd8f0e1cc1ffc5e475514")
hashed.setPhoneE164("8a59780bb8cd2ba022bfa5ba2ea3b6e07af17a7d8b30c1f9b3390e36f69019e4")
Singular.setUserDetails(hashed)

Firma del método: 

public static void setUserDetails(SingularUserDetails userDetails);

Borrar la PII

Los User Details almacenados persisten en el dispositivo entre inicios de la app. Llama a clearUserDetails al cerrar sesión, o cuando el usuario retire su consentimiento, para eliminarlos.

Kotlin Java 
// Remove stored user details on logout
Singular.clearUserDetails()

Firma del método: 

public static void clearUserDetails();

Nota: La carga se almacena cifrada en el dispositivo, con una clave guardada en el Android Keystore. Como se persiste, llamar a withUserDetails en un inicio posterior no borra lo que se almacenó antes. clearUserDetails es la única forma de eliminarlo.

Validación y comportamiento de privacidad

  • Validación del correo electrónico: Un correo electrónico en texto claro debe contener exactamente una @ y un punto después de ella. Los valores no válidos se rechazan y se registran en el log; no se envían.
  • Validación del teléfono: Un número de teléfono en texto claro debe contener al menos 6 dígitos. Los valores más cortos se rechazan y se registran en el log.
  • Protección contra el modo incorrecto: Un valor que ya parece hasheado es rechazado por setEmail y setPhoneNumber. De la misma forma, los setters pre-hasheados rechazan cualquier valor que no sea una cadena hexadecimal SHA-256 de 64 caracteres.
  • Limit Data Sharing: Mientras Limit Data Sharing esté habilitado, la carga de PII se excluye de todas las solicitudes. Consulte: Privacidad de datos.
  • Consentimiento: Recopile y envíe direcciones de correo electrónico y números de teléfono únicamente cuando tenga una base legal para hacerlo. El hasheo no elimina sus obligaciones bajo el GDPR, la CCPA o regulaciones equivalentes.