Guía de gestión del consentimiento para aplicaciones móviles
Descripción general
Este documento proporciona directrices completas para implementar la gestión del consentimiento en aplicaciones móviles, garantizando el cumplimiento de las normativas de protección de datos, como el RGPD, la LGPD y los requisitos del Marco de Transparencia y Consentimiento (TCF) de IAB. Aborda la gestión adecuada del consentimiento del usuario para servicios de terceros, como redes publicitarias, plataformas de análisis y otros servicios de seguimiento.
Requisitos de implementación
1. No inicialice servicios de terceros sin verificación de consentimiento
Pasos de implementación:
- Comprobar si el usuario ha tomado una decisión de consentimiento
- Verificar el consentimiento para el proveedor/servicio específico
- Solo inicialice el servicio si se cumplen ambas condiciones
- Si no se otorgó el consentimiento para un proveedor o propósito determinado, deberá:
- Omitir la inicialización de ese servicio (por ejemplo, Google AdMob);
- Utilice alternativas que respeten la privacidad, si hay alguna disponible;
- Limite las funcionalidades disponibles según su estrategia de ingresos del producto. Por ejemplo, en una aplicación totalmente gratuita que depende de la visualización de anuncios como única fuente de ingresos, puede mostrar un mensaje intuitivo que indique que la aplicación no funcionará o que solo estará disponible parcialmente a menos que se dé el consentimiento para fines de marketing.
2. Verificación del consentimiento en dos fases
Implemente siempre ambas comprobaciones según lo exige el artículo 7(1) del RGPD y las especificaciones TCF de IAB:
Fase 1: ¿El usuario ha tomado una decisión?
- Comprueba si el usuario ha interactuado con la capa de consentimiento
- Si no se ha tomado ninguna decisión, no procese los datos personales
Fase 2: ¿El usuario consiente un propósito específico?
- Comprobar si se otorgó el consentimiento para el servicio de terceros específico
- Cada proveedor/servicio requiere verificación de consentimiento individual
Escenarios de flujo de trabajo del usuario
Escenario 1: Flujo de trabajo de usuario normal
Flujo: El usuario abre la aplicación → El SDK muestra la capa de consentimiento (si es necesario) → El usuario realiza una elección → La aplicación continúa con los servicios apropiados
Importante: la navegación con el botón Atrás o los gestos están deshabilitados en nuestros SDK móviles, por lo que el usuario no puede descartar la capa de consentimiento sin el consentimiento adecuado.
Pasos de implementación:
- Inicio de la aplicación: Inicialice la plataforma de gestión de consentimiento. Para ello, utilice el método checkAndOpen(). Consulte los ejemplos en nuestra documentación de ayuda (iOS, Android)
- Verificación de consentimiento: el paso anterior determinará automáticamente si es necesario o no el consentimiento, para que el usuario pueda informar su decisión de consentimiento.
- Inicialización del servicio: inicializar los servicios según las opciones de consentimiento del usuario
Ejemplo de implementación:
// This hypothetical example assumes you have implemented:
// - OneSignal (s1448)
// - Google Ads/AdMob (s1)
// - Google Analytics (s26)
class yourGreatApp {
void function onAppLaunch() {
if shouldInitializeService("s148") {
OneSignal.initialize("your-token")
}
if shouldInitializeService("s1") {
AdMobService.initialize()
}
if shouldInitializeService("s26") {
FirebaseAnalytics.initializeApp("your-token")
}
}
boolean private function shouldInitializeService(string: purposeId):
// Phase 1: Check if user has made any decision
consentStatus = CMPManager.getUserStatus()
if consentStatus.status = "choiceDoesntExist"
return false // Consent Layer was not yet displayed to this client
return CMPManager.shared.getStatusForPurpose(id: purposeId) == "granted"
}
}Escenario 2: Sin conexión a Internet
Flujo: El usuario abre la aplicación sin Internet → CMP no puede cargar la capa de consentimiento → La aplicación debe manejarlo correctamente
Observaciones críticas:
- Nuestro SDK móvil no puede recuperar la configuración de los servidores
- Las decisiones de consentimiento previas aún pueden ser válidas (según el artículo 7(3) del RGPD sobre la revocación del consentimiento)
- La aplicación debe funcionar en modo degradado sin procesar datos personales en caso de que aún no se haya dado el consentimiento
Estrategia de implementacion:
- Verifique si hay posibles datos de consentimiento persistentes de sesiones anteriores (usará
getUserStatus()como en el ejemplo anterior para eso) - Si existe consentimiento previo, proceder normalmente
- Si no hay consentimiento persistente y no hay internet:
-
- Bloquear todos los servicios de terceros no esenciales
- Mostrar un mensaje fácil de usar que explique la situación.
- Configurar el detector de conectividad para volver a intentarlo cuando se restablezca la conexión y mostrar la capa de consentimiento cuando esto suceda
- Permitir la funcionalidad básica de la aplicación que no requiere el procesamiento de datos personales
Consideraciones sobre la experiencia del usuario:
- Mostrar un mensaje claro sobre la funcionalidad limitada
- Implementar la opción de reintento cuando la conexión esté disponible
- Explique que no se compartirán datos personales hasta que se tomen decisiones de privacidad.
- Proporcionar la opción de continuar en modo limitado
Escenario 3: No se necesita consentimiento
Situación: El usuario está fuera de la UE y CMP está configurado para mostrarse solo en la UE → No se muestra la capa de consentimiento
Estrategia de implementacion:
- Inicialice la configuración de CMP de forma normal
- Permitir que CMP determine si se debe mostrar la capa de consentimiento usando
checkAndOpen() - Si no se requiere el consentimiento, el estado del usuario volverá a ser “choiceExists” y los proveedores y propósitos se establecerán como “concedidos”.
- Inicializar todos los servicios normalmente
Reaccionar a los cambios de consentimiento
Los cambios de consentimiento pueden ocurrir en varios escenarios:
- El usuario abre la configuración de consentimiento y cambia las preferencias
- El consentimiento caduca y necesita renovación (esta configuración se puede encontrar en Legal en su panel de CMP)
- Cambios en los requisitos legales que obligan a la revocación del consentimiento
- El usuario solicita la eliminación de datos
El checkAndOpen() El método reaccionará a todas esas situaciones. Implemente un detector que rastree los cambios de consentimiento. Puede usar el didReceiveConsent devolución de llamada para eso (iOS y Android). Si en algún momento se rechaza un proveedor o propósito determinado, tome medidas de inmediato y bloquee los servicios en consecuencia.
Lista de verificación de pruebas
Prueba de funcion
Prueba de flujo normal:
- La aplicación se inicia correctamente y muestra la capa de consentimiento cuando es necesario
- Las opciones de consentimiento del usuario se registran y respetan adecuadamente
- Los servicios se inicializan únicamente con el consentimiento apropiado
- La aplicación funciona correctamente después de las decisiones de consentimiento
Prueba de flujo de rechazo:
- El rechazo del usuario bloquea adecuadamente los servicios de terceros
- La aplicación permanece funcional o entra en modo degradado según su estrategia de ingresos
Pruebas fuera de línea:
- La aplicación gestiona sin problemas la falta de conexión a Internet
- Los datos de consentimiento almacenados en caché se utilizan adecuadamente
- El modo que respeta la privacidad se activa cuando es necesario
- La restauración de la conexión activa la lógica de reintento adecuada
Prueba de tiempo de espera:
- El tiempo de espera de la capa de consentimiento activa una alternativa adecuada
- La aplicación no se congela ni se bloquea durante el tiempo de espera
- El modo de respaldo bloquea adecuadamente el procesamiento de datos
- El usuario recibe una comunicación clara sobre el estado
Pruebas de conformidad
Verificación del procesamiento de datos:
- No se envían datos de seguimiento antes de que el usuario tome la decisión de consentimiento
- Los identificadores de proveedores se asignan correctamente a los servicios reales
- El bloqueo de servicios individuales funciona según lo previsto
- Granularidad del consentimiento correctamente implementada
Verificación de requisitos legales:
- La retirada del consentimiento detiene inmediatamente el procesamiento de datos
- Los derechos del interesado pueden ejercerse a través de la aplicación
- Se mantiene un registro de auditoría adecuado para las decisiones de consentimiento
- Base legal documentada para todo el procesamiento de datos
Localización de averías
Problemas comunes y soluciones
Problema: Los servicios se inicializan incluso cuando se deniega el consentimiento
Causas fundamentales:
- Falta la verificación de consentimiento antes de la inicialización del servicio
- Asignación incorrecta de ID de proveedor
Soluciones:
- Agregar verificación de consentimiento explícito antes de TODA inicialización de servicios de terceros
- Verificar que los ID de los proveedores coincidan con los de la Lista global de proveedores
- Implementar una sincronización adecuada entre el consentimiento y la inicialización del servicio
- Instancias de servicio claras cuando se revoca el consentimiento
Problema: La capa de consentimiento nunca aparece
Posibles causas:
- Configuración incorrecta de CMP (ID incorrecta, dominio, etc.)
- Problemas de conectividad de red
- El usuario está fuera de la región geográfica de destino
- Problemas de integración de aplicaciones
Pasos de depuración:
- Verificar que la configuración de CMP coincida con la configuración de la cuenta
- Pruebe la conectividad de la red y la accesibilidad del servidor CMP
- Verifique los registros de la consola para ver si hay mensajes de error
- Pruebe con la capa de consentimiento de apertura forzada para verificar la integración
- Confirmar la configuración de segmentación geográfica en el panel de CMP
Lista de verificación de prioridades de implementación
Alta prioridad (debe completarse antes del lanzamiento):
- Verificación de consentimiento implementada antes de TODA inicialización de servicios de terceros
- Manejo adecuado de errores en casos de tiempo de espera, red y configuración
- La funcionalidad básica de la aplicación se conserva cuando no se puede determinar el consentimiento
- Todos los ID de proveedores verificados y asignados correctamente a los servicios reales
Mejoras continuas:
- Análisis de seguimiento en su panel de CMP para conocer las tasas de éxito del consentimiento
- Pruebas A/B para la optimización de la capa de consentimiento
- Integración con marcos de cumplimiento adicionales
- Mejor educación del usuario sobre las opciones de privacidad
Recuerde: Ante la incertidumbre sobre los requisitos de consentimiento, elija siempre el enfoque que proteja más la privacidad. Es mejor ser demasiado precavido que infringir la privacidad del usuario o los requisitos regulatorios.
