Cómo cumplir el GDPR a nivel de newsletter / email marketing

Hoy ha sido el día elegido por un servidor para avisar a los miembros de la Comunidad de que era necesario que actualizasen su perfil dando consentimiento expreso del tratamiento de sus datos por mi parte.

Un tratamiento que se resume en… te envío un email semanal con toda la actualidad tecnológica… y de vez en cuando alguno extra con un sorteo (no lo digas muy alto que tampoco quiero que se enteren los típicos aprovechados que solo se suscriben para obtener beneficios) o cualquier locura que se me ocurra. Y unos datos tan privados como el email y el nombre (G.G) que comparto… conmigo mismo, y con el proveedor de la plataforma, que en este caso es Mailchimp, y en cuyas políticas aseguran por activa y por pasiva que jamás van a hacer uso de las bases de datos de sus clientes.

Este proyecto no vive de la publicidad, por lo que utilizo el email marketing simplemente como canal para estar en contacto con los miembros. Y pese a todo, estoy obligado a cumplir con este nuevo requisito.

Uno de los puntos más cuestionables del GDPR (el Reglamento Europeo de Protección de Datos), que viene a actualizar (que no a sustituir), al menos en cuanto a tratamiento de datos en email se refiere, al PECR (Privacy and Electronic Communications Regulations).

La cuestión es que a partir del 25 de mayo, todos aquellos que realicen campañas (publicitarias o no, ojo) con una base de datos, deben tener el consentimiento explícito de dichos usuarios para poder realizarles los envíos.

Y cuidado, que viene con carácter retroactivo, lo que quiere decir que aplica tanto a nuevos registros como a los que ya teníamos.

A la hora de escribir estas palabras la Comunidad de NT y Segur-Info de PabloYglesias tiene 1.280 miembros, con 34 miembros que están inactivos (o al menos, que el sistema de tracking de Mailchimp me marca como tal, que sé que muchos de vosotros, pillines, utilizáis sistemas anti-tracking). Cuando haga efectivo el borrado de aquellos que no acepten la política de privacidad en su perfil, ya informaré de cuántos quedamos.

Tengo tan pocos inactivos por la sencilla razón de que periódicamente hago limpieza. Que como ya he explicado en su día, me importa más la calidad que la cantidad, y que de hecho la última limpieza la hice por febrero, cargándome alrededor de 150 miembros. Unos 5.000 desde que empezase a hacer limpiezas periódicas.

Con algunos de mis clientes ya habíamos saneado las bases de datos en las últimas semanas, pero falta que lo hiciera por estos lares. Así que aprovecho para explicar por aquí cómo demonios se hace, ya que lamentablemente hay muy poca información en la red al respecto, y la mayoría de bloggers y empresarios digitales están obligados por ley a hacerlo.

ACTUALIZACIÓN: Explico por aquí dónde es necesario realizar este trámite y en qué situaciones no sería estrictamente necesario para cumplir la GDPR, además de mostrar los resultados obtenidos tras el borrado de inactivos en uno de mis clientes, que se resumen en menos envíos y prácticamente igual interacción, ergo más beneficio económico.

Así que, expuestas las razones, vamos al tema.

Crear el campo de aceptar la política de privacidad

Según la nueva legislación, ya no vale solo con pedir al usuario que acepte nuestra política de privacidad en el momento de realizar la suscripción, sino que además tenemos que guardar dicho registro como un campo más.

Para implementar esto, ya dependemos de las opciones que nos ofrezca el servicio de email que estemos utilizando.

El caso de Mailchimp es para colmo curioso, ya que no es posible crear un campo (field) de tipo checkbox en los formularios de suscripción. Hace unas horas (justo después de preparar este tutorial) la compañía anunció que implementaba unas herramientas que cumplían con la GDPR (EN). Y en efecto lo hacen, pero tienen el hándicap de solo funcionar, por ahora, con los formularios nativos de Mailchimp. Esos mismos que la amplia mayoría de proyectos digitales no utilizamos.

Así que o bien esperamos a que el ecosistema de plugins y desarrollos a medida se actualice para aceptar la nueva realidad, o bien cumplimos con la legislación en el tiempo que tenemos para hacerlo (llevan avisando meses, y este último mes era el último), cosa que he preferido hacer.

Para ello, desde Manage Contacts > Groups, creamos uno no oculto que en mi caso pertenece a «Tratamiento de datos» y cuyo nombre es «He leído y acepto la política de privacidad*».

Lo hago así ya que, de nuevo, al tratarse de un grupo, no podremos modificarlo en el estilo del formulario web que nos ofrece la plataforma (el nombre que tenga es el nombre que mostrará en el formulario final).

Una vez ya lo tengamos creado, veremos que automáticamente se incluye en el formulario de suscripción, y le aparecerá en el perfil a todos los miembros.

Simplemente tendremos que acordarnos de incluir en el texto (es el único sitio donde nos deja el constructor) un enlace a la política de privacidad.

Una página que ya deberíamos tener creada en nuestra web, y en cuyo contenido ya no me meto, que para eso están los abogados especializados en derecho digital. Pero básicamente ahí es donde tenemos que informar qué datos recopilamos, con qué objetivo y si se comparten o no con terceros.

Puedes ver un ejemplo (ojo, que no soy abogado) en mi página de política de privacidad (ES), por si sirve de «inspiración».

Crear los formularios en nuestra web

Con lo anterior realmente ya tenemos la parte del proveedor cubierta. Lo que pasa es que la mayoría de proyectos utilizan su propia web como gancho principal para conseguir nuevos suscriptores. Y ahí también tenemos que cumplir la GDPR.

Sin ir más lejos, el número de miembros de esta Comunidad que se suscribieron históricamente por el formulario nativo de Mailchimp es prácticamente anecdótico. Creo recordar que hablábamos de menos de una treintena, que presumiblemente vendrían de algún enlace a la versión web del email semanal que un miembro hubiera compartido por sus redes.

De ahí que también toca modificar todos los formularios que estamos utilizando. La principal razón de que haya decidido hacer el cambio ya y no utilizar la funcionalidad que se ha sacado Mailchimp hace un rato.

¿Cómo lo podemos hacer?

Para ello utilizo un plugin de WordPress llamado MailChimp for WP (EN), que tira de la API de MC, y que facilita hasta el extremo la inclusión de este nuevo campo para cumplir la GDPR. Simplemente actualizas la API, reconoce que tienes un nuevo grupo, y lo agregas mediante el botón que lleva su mismo nombre.

Lo único que sí vas a tener que hacer (y aquí se demuestra nuevamente que una cosa es que el proveedor ofrezca una alternativa a esta necesidad, y otra bien distinta que todo el ecosistema alrededor suyo se actualice) es incluirle a mano en ese campo un «required», que forzará a que el usuario tenga que aceptar esa política para continuar.

Y digo que es un problema no resuelto ya que al tratarse de un grupo, y no de un campo, no podemos de antemano forzar a que el usuario acepte obligatoriamente pertenecer a ese grupo. Es, simplemente, una casuística que Mailchimp no había contemplado (o que sí lo habían hecho y por la razón que fuese no les pareció oportuno incluir).

Sí podemos, no obstante, hacerlo a nivel de formulario, bien sea con el «hack» que yo propongo por aquí:

<input name="INTEREST[XXXXX][]" type="checkbox" value="XXXXX" required >

Bien sea desde el formulario embebido que nos ofrece Mailchimp para colocar en nuestra web (ahí sí podemos requerir que el suscriptor acepte un grupo).

Además hay que informar en la misma página, aunque sea, de la información básica de esa política de tratamiento de datos.

Una buena manera es incluir el siguiente párrafo:

Responsable: Tu nombre y apellidos o el de la empresa.

Finalidad: ¿Por qué recopilamos esos datos? (envío de publicidad, mantener comunicación…).

Legitimación: Que le estás pidiendo permiso para eso en particular.

Destinatario: ¿Dónde se almacenan esos datos? ¿En tu servidor, en una plataforma como Mailchimp…?

Derechos: Que el usuario sepa que puede darse de baja, modificar o limitar la información cuando quiera.

Tienes un ejemplo (de nuevo recalco que yo no soy abogado) en mi página de suscripción (ES).

Comunicárselo a nuestros suscriptores

Ahora viene la parte más fea, que es avisar a toda nuestra base de datos de que deben actualizar su consentimiento para seguir recibiendo nuestras comunicaciones. Esto es crítico para cumplir la GDPR.

Y para ello, toca escribir un email explicando la situación y enlazando al perfil del suscriptor (MailChimp no parece interesada en ofrecer la opción de crear un enlace que sirva para aceptar automáticamente esto, cosa que sí hacen otros proveedores).

Aquí ya entra la mano de cada uno. Yo recomendaría crear específicamente un email que esté convenientemente identificable como tal a nivel de asunto de correo, para maximizar al máximo posible su visualización.

Si lo incluimos con el resto de comunicaciones habituales habrá suscriptores que lo mismo no lo acabarán abriendo (es uno más), y eso es un gran problema para todos (para nosotros que vamos a borrar a un suscriptor que suele leer nuestros correos, y para el suscriptor, que quizás pierda para siempre acceso a nuestras comunicaciones).

Una vez allí, tendrán visible la opción anteriormente comentada, que deberán marcar y actualizar perfil.

Son, en definitiva, tres clicks. Quizás pedir demasiado si hasta el momento nuestras comunicaciones han sido puramente spam, como suele pasar con la mayoría de newsletters…

Los miembros de esta Comunidad ya están más que acostumbrados a interaccionar con el email, así que es algo que sinceramente no me preocupa en demasía. Habrá algún despistado que perderemos, y algún otro que lo verá tarde y le tocará volver a suscribirse, pero tampoco es el fin del mundo.

Deberíamos dejar un tiempo prudencial para que los suscriptores puedan ver el email y tomar acción. Por mi parte lo dejaré hasta el 24 (algo más de una semana), día en el que ya tengo programado el envío de otro email para, antes de borrar a los que no lo hayan aceptado, avisarles de la situación.

Este correo estará dirigido no a toda la base de datos, sino al conjunto de suscriptores que no pertenecen al grupo anteriormente creado. Cosa que se hace como muestro en el siguiente pantallazo.

Hay que tener en cuenta que puede que alguno de los suscriptores esté de vacaciones o se le haya pasado ese email entre toda la vorágine de emalis que le llegan a la bandeja de entrada. Así que por lo menos que haya otra oportunidad para que sepa la razón de que lo hayamos eliminado, invitándole a volver a suscribirse si quiere seguir recibiendo las comunicaciones.

A partir de entonces, todos los envíos los realizaremos al grupo, no a toda la base de datos. La forma de hacerlo es justo la contraria a la que explicaba un par de párrafos más arriba (en vez de none of, one of).

Con esto estaremos cumpliendo la legislación europea GDPR, y si el día de mañana nos piden demostrar que en efecto nuestros suscriptores habían dado su consentimiento a la hora de recibir estos emails, podremos demostrarlo jurídicamente.

Conclusiones

Quizás el forzar todo esto sea una soberana gilipollez a nivel de sentido común, pero lo cierto es que me parece una buena idea de cara a sanear las comunicaciones que recibimos a diario desde el punto de vista de los usuarios, y una oportunidad única para los administradores de ser más óptimos con sus envíos (menos base de datos pero más actualizada, ergo menos inversión con prácticamente el mismo impacto). Ya no solo para cumplir la GDPR.

Hasta ahora la gestión de datos personales se estaba haciendo a contra natura, abusando las organizaciones de nuestra habitual falta de conocimiento y/o dejadez. Con la GDPR, se fuerza a las primeras a que sean consecuentes con los datos que piden, mandando al cuerno esa estrategia tan típica del sector de aglutinar ingentes bases de datos de suscriptores que no les importa una mierda lo que tenemos que decirles.

• Desde el punto de vista de los administradores, o bien les pedimos a los suscriptores consentimiento para seguir enviándoles información (lo que significa aceptar que el control pasa a estar en manos del usuario), o bien no cumplimos la legislación, bajo multas económicas que dan verdadero miedo.
• Desde el punto de vista del usuario, una gran oportunidad para decidir si esta newsletter sigue o no interesándome. Si hasta ahora me ha aportado el valor suficiente como para que acepte que siga enviándome información, o si por el contrario prefiero que no lo siga haciendo, ya que su estrategia pasaba prácticamente por bombardearme una y otra vez con publicidad y spam.

Un servidor ya le ha dicho que no a varias a las que estaba suscrito.

Que cada uno elija consecuentemente qué decide hacer.

Y si te has quedado con más dudas, no dudes en ponerte en contacto con un servidor, comentarme tu caso particular, y ver si puedo ayudarte en algo.

Edit un día más tarde:Incluidos algunos ejemplos de la información que tenemos que incluir tanto en el formulario como en la página con la política de tratamiento de datos para cumplir la GDPR.

Edit una semana más tarde: Explico por aquí dónde es necesario realizar este trámite y en qué situaciones no sería estrictamente necesario para cumplir la GDPR además de mostrar los resultados obtenidos tras el borrado de inactivos, que se resumen en menos envíos y prácticamente igual interacción, ergo más beneficio económico.

________

¿Quieres conocer cuáles son mis dispositivos de trabajo y juego preferidos?

Revisa mi setup de trabajo, viaje y juego (ES).

Y si te gustaría ver más de estos análisis por aquí. Si el contenido que realizo te sirve en tu día a día, piénsate si merece la pena invitarme a lo que vale un café, aunque sea digitalmente.