Analytics de app y RGPD: configúralo desde el día uno

Montar analytics de app cumpliendo el RGPD es una de esas tareas que cuesta media jornada si la haces antes de lanzar y varias semanas si la arreglas después. La diferencia no es técnica. Es que antes de lanzar decides qué datos recoges, y después de lanzar tienes que justificar los que ya recogiste, con usuarios reales de por medio y un histórico que puede que no puedas conservar.

Esta guía es lo que hacemos nosotros al empezar un producto. No es asesoría legal, y para un tratamiento complejo conviene contar con quien lo sea. Es el procedimiento práctico que evita los tres errores que vemos una y otra vez: medirlo todo, medirlo antes del consentimiento y no documentar nada.

Analytics de app y RGPD: dónde está exactamente la línea

La respuesta corta es que la analítica de app y el RGPD chocan en un punto concreto: si puedes vincular la medición a una persona identificable, es tratamiento de datos personales y necesitas una base jurídica. Los identificadores de dispositivo y las direcciones IP cuentan como datos personales, así que la pregunta no es si recoges nombres, es si puedes reconstruir a alguien.

Sobre el consentimiento, la guía de la AEPD sobre cookies para herramientas de medición de audiencia reconoce una exención, pero con condiciones estrictas: los datos no pueden cotejarse con otras operaciones de tratamiento ni transmitirse a terceros, y la finalidad tiene que quedarse en la medición agregada del servicio. En la práctica eso descarta a la mayoría de plataformas de terceros tal y como vienen configuradas, y deja dentro a las herramientas que procesan en tu propio dominio o infraestructura y no perfilan.

Esa es la bifurcación que ordena todo lo demás, y conviene tomarla de forma consciente en lugar de heredarla del primer script que alguien pegó en el proyecto.

Paso 1: define seis eventos, no sesenta

El impulso natural es instrumentar cada pulsación por si acaso. Es un error por dos motivos. Legalmente, cuanto más recoges, más tienes que justificar, minimizar y conservar con criterio. Prácticamente, un sistema con doscientos eventos no lo mira nadie, porque nadie sabe cuál importa.

Empieza por seis, alineados con el recorrido crítico:

1. Alta completada. El usuario ha terminado el registro, no solo lo ha empezado.
2. Primera acción con éxito. El primer momento en que el producto hace lo que promete.
3. Segunda sesión. El indicador temprano de retención más honesto que existe.
4. Activación. Tu definición propia de “este usuario ya entendió el producto”.
5. Conversión. Pago, contratación o el equivalente en tu modelo.
6. Abandono en el paso crítico. El punto del embudo donde más gente se cae.

Con esos seis respondes a casi todas las preguntas de producto de los primeros seis meses. El resto se añade cuando tengas una pregunta concreta que no puedas contestar, que es el único motivo válido para añadir un evento.

Paso 2: elige herramienta según lo que necesites saber

Hay tres perfiles y cada uno tiene una respuesta distinta.

La trampa habitual es instalar la tercera fila cuando la pregunta real era de la primera. Si lo que quieres saber es cuánta gente entra, desde dónde y qué pantallas ve, no necesitas una plataforma publicitaria y sí ganas mucho evitándola.

La segunda fila es donde vive la mayoría de productos serios. Ahí el consentimiento no es opcional, pero es perfectamente gestionable: eliges región europea, firmas el contrato de encargado del tratamiento, configuras la conservación y sigues adelante.

Paso 3: consentimiento primero, instrumentación después

Este es el error caro y es de orden, no de herramienta. Muchas apps piden el consentimiento en una pantalla que aparece después de que el SDK de analítica ya se haya inicializado y haya enviado el primer evento de apertura. El banner existe, la casilla está bien redactada, y el incumplimiento ya se produjo.

La regla práctica es que ningún SDK que trate datos personales se inicializa hasta que hay una decisión registrada. En la mayoría de plataformas eso significa mover la inicialización fuera del arranque de la aplicación y ponerla detrás de la respuesta del usuario. Es un cambio de veinte líneas si se hace al principio y una refactorización desagradable si se hace después.

Registra además la decisión con marca de tiempo y versión del texto que se mostró, porque el principio de responsabilidad proactiva exige poder demostrar el consentimiento, no solo haberlo pedido. Y ofrece una forma de cambiar de opinión que esté a la vista, no enterrada en tres niveles de ajustes.

Si tu app además maneja datos de salud, menores o cualquier categoría especial, el listón sube bastante y merece revisión específica. Cubrimos el marco general en nuestra guía sobre cómo cumplir el RGPD en una app en España.

Paso 4: el plan de medición que hace doble trabajo

Una sola hoja de cálculo resuelve la necesidad de producto y buena parte de la documentación que exige el RGPD. Columnas: nombre del evento, cuándo se dispara, propiedades que envía, si alguna propiedad es dato personal, base jurídica, plazo de conservación y responsable.

Esa tabla es lo que enseñas si alguien pregunta, lo que consulta un desarrollador nuevo antes de añadir un evento, y lo que impide que en nueve meses tengas tres eventos distintos que miden lo mismo con nombres parecidos. Cuesta una hora escribirla y ahorra bastante más que eso.

Fija también una convención de nombres antes del primer evento. Algo tan simple como objeto_accion en minúsculas y sin acentos, aplicado sin excepciones. La analítica de producto se degrada casi siempre por desorden de nomenclatura, no por falta de herramienta.

Paso 5: conservación y borrado, que es donde se rompe todo

El RGPD exige plazos de conservación definidos y la capacidad de atender solicitudes de supresión. En analítica eso se traduce en dos decisiones concretas.

Primera, configura la conservación en la propia herramienta. Muchas plataformas guardan por defecto mucho más de lo que necesitas. Para datos a nivel de usuario, entre doce y veinticuatro meses cubre prácticamente cualquier análisis de producto real. Los agregados anonimizados pueden conservarse más tiempo sin el mismo problema.

Segunda, comprueba que puedes borrar. Antes de lanzar, haz la prueba: crea un usuario de prueba, genera actividad, y ejecuta el borrado en todos los sistemas donde ese identificador aparece. Si no puedes hacerlo en una operación, tienes trabajo pendiente, y es mucho más barato hacerlo ahora que cuando llegue la primera solicitud real.

Los cinco errores que vemos siempre

Después de montar esto en bastantes productos, la lista de fallos es corta y muy repetitiva.

Instrumentar la interfaz en lugar del comportamiento. Eventos llamados boton_azul_pulsado que dentro de tres meses, cuando el botón cambie de sitio, no significarán nada. El evento debe describir lo que el usuario consigue, no dónde pulsó. pedido_confirmado sigue siendo válido después de cinco rediseños.

Copiar el banner de otra empresa. El texto de consentimiento tiene que describir tus tratamientos, tus finalidades y tus encargados. Un banner copiado suele mencionar cookies publicitarias que no usas y omitir el SDK que sí tienes instalado, lo que es peor que no tener banner, porque documenta por escrito que no sabes qué recoges.

Enviar el identificador de usuario a todas partes por defecto. Muchos SDK permiten adjuntar el identificador interno a cada evento, y muchos equipos lo activan sin pensarlo. Eso convierte una analítica agregada en un tratamiento a nivel de persona, con todo lo que implica. Actívalo solo donde la pregunta lo exija.

No incluir la analítica en el registro de actividades de tratamiento. Se documenta el CRM, la facturación y el envío de correos, y la analítica se queda fuera porque “es solo una métrica”. Es un tratamiento como cualquier otro y aparece igual en cualquier revisión.

Dejar el entorno de desarrollo enviando datos a producción. Sucede en casi todos los proyectos y ensucia las métricas de las primeras semanas justo cuando más importan. Separa los proyectos de analítica por entorno desde el primer día, que cuesta cinco minutos.

Ninguno de los cinco es un problema técnico difícil. Los cinco son consecuencia de tratar la analítica como algo que se añade al final, cuando es una decisión de diseño de producto y de tratamiento de datos que conviene tomar al principio.

Qué medir en los primeros noventa días

Con los seis eventos y el plan en su sitio, las preguntas que de verdad importan al principio son pocas: cuántos de los que se registran llegan a la primera acción con éxito, cuántos vuelven en la semana siguiente, y en qué paso concreto se cae la gente. Todo lo demás puede esperar.

Esas tres respuestas son las que deciden si el producto tiene tracción o si estás mirando a un embudo que no convierte, que es la diferencia entre iterar con criterio y añadir funciones a ciegas. Lo desarrollamos desde el lado de crecimiento en cómo conseguir los primeros 100 usuarios en España, y desde el lado de presupuesto en el mito del MVP de 25.000 €.

Si estás a punto de lanzar y quieres que alguien revise tu plan de medición y tu posición de consentimiento antes de que haya usuarios reales de por medio, cuéntanos tu proyecto. Es una revisión corta y evita casi siempre un arreglo caro seis meses después.

Fuente: AEPD, guía sobre el uso de cookies para herramientas de medición de audiencia.