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.
Índice de contenido
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.
He leido su tweet y tengo una duda.
Se la envio por fax o Fedex la Confirmacion de Suscripcion redactada por el notario, asi no ando dando check o leyendo politicas.
Espera… tiene que ser un abogado 2.0, el abogado normal me preguntaria ¿Que es GDPR?
Y algunos abogados 2.0 también Dbillyx. Lamentablemente…
Hoy (a unas horas de que entre en vigor) llevo todo el día con un par de clientes adaptándoles las webs…
Me ha pasado dos cosas, creo que el GDPR sera la anecdota del 2018.
Sobre la pagina de politicas en italiano, era por razones obvias. El problema me ha caido con una empresa enviando sus politicas, empresa de a saber cuantas mas paginas por lo que me da desconfianza al no saber con relacion a que pagina en donde este registrado me esten enviando el aviso. Y buscando info de la empresa no encuentro que tipo de paginas esten relacionadas. Creo que me van a eliminar.
Lo otro y realmente mas triste, no tan precisamente por el GDPR. Pero cierto usuario ha enviado un correo de despedida, lamentando la situacion tendra que eliminar la base de datos. En parte pequeña por el GDPR, el resto en el correo explica los desafortunados problemas que ha tenido y la imposibilidad de estar compartiendo mas en el blog por un accidente serio que tuvo semanas atras, por lo que sera una temporada larga sin esta publicando constantemente, pero igual agradece quienes cuando tengan tiempo, pasen a su pagina a volverse a inscribir aunque sera varios meses hasta que recupere una actividad normal en el blog y en su vida. Asi que el se despide de todos al enviar su ultimo correo.
Y bueno, hey, que lloro. XD
Mi página es una simple web presencial que tiene un formulario de contacto (nombre, email, mensaje) que internamente nos manda el mensaje por correo. Equivalente a enviar un correo con un gestor de email.
– No uso base de datos.
– No uso cookies propias ni de terceros.
– Ni tengo página de «términos y condiciones» ni «política de privacidad» ni checkbox en el form.
¿Estaría obligado a hacer algo respecto al GDPR?
¿Debería crear una pag. de política de privacidad que simplemente diga que no guardamos sus datos y añadir el checkbox de confirmación?
Gracias !
Así es Raúl. En tu caso, bastaría a priori con incluir una página en la que explicas esto que me has dicho, informas que tienes un formulario que simplemente envía un email y cuyos datos son utilizados por ti o por tu empresa únicamente para ponerse en contacto con la otra persona y resolverle las dudas, incluyendo en ese formulario el checkbox adecuado, y si quieres, para rizar el rizo, una coletilla como la que comento en este artículo, donde dice quién es el administrador, qué datos se recopilan (el email y el nombre) y con qué objetivo (ponerse en contacto…).
Hola Pablo, me surge una duda. Con tu sistema, puedes hacer que desde un plugin de WP donde creas el form, el checkbox sea obligatorio. Pero cuando el usuario vaya a la típica página de mailchimp para editar sus datos, que es externa a tu web, no sera obligatorio el checkbox, por lo que el usuario podría desmarcar la aceptación de políticas de privacidad, teniendo así que segmentar tu lista para no enviar emails a esos suscriptores.
he visto por ahí que alguno meten un radiobutton que si puede ser obligatorio. No se tu como has solucionado esto.
Un saludo!
Claro. Ten en cuenta que en mi caso es muy, muy difícil que el usuario se suscriba por otro lado que no sea el formulario de mi web. Y en todo caso, si lo hicieran, en el envío inicial que hago para «confirmar» el mail aviso de que para recibir los correos es necesario tener clicado ese checkbox.
¿Que aun así no lo hacen? Los envíos que realizo los realizo a la segmentación oportuna, no a toda la base de datos. Por lo que si alguien se suscribe por el formulario y hace caso omiso del email que envío, realmente no va a recibir comunicaciones por mi parte.
Como periódicamente hago limpieza de la base de datos, cuando toque la siguiente revisaré si hay alguno (es poco probable, pero podría haberlos), y los avisaré de la situación como hice esta vez con la entrada en vigor de la normativa, eliminándolos en caso de que no tomen acción.
Lo del radiobutton habría que probarlo, sí. No sabía que podías forzar a que fuera obligatorio.
Gracias Pablo por la respuesta!
En mi caso creo que probare con radiobutton, para que el cliente final no tenga que andar segmentando los envíos y revisando la lista para borrar a los usuarios que no acepten la política.
Una cosa que no entiendo es porque Mailchimp ha implementado un campo RGPD que no se puede usar en formularios incrustados, para mi no tiene sentido, esperemos que vayan actualizando esto.
Un abrazo.
Ya… Supongo (y no es por defenderles, que la verdad es que tampoco lo entiendo) que ha sido por falta de preparación, cumpliendo la normativa por poco (una semana antes) y de puertas hacia fuera. En algún momento entiendo que tienen que incluir ese checkbox a la API de mailchimp, ya que está claro que todas las cuentas profesionales utilizan desarrollos de terceros para implementar la suscripción de forma nativa en el proyecto, no mediante los formularios incrustados que ofrecen.
Ya nos cuentas, por cierto, qué tal la experiencia con el radiobutton.
Así quedo: http://magnet.cat/#boletin
Un saludo!
Te recomendaría meterle el atributo target=»_blank» a la URL enlazada en la política. Que sé que es una tontería, pero vaya, así no sacas al usuario de la página.
Por otra parte fetén. Mil gracias David!
Efectivamente. Hay que implementar medidas de adaptación como las que señalas. Y cuanto antes. Que la AEPD ya está aplicando sanciones.
Tal cual Luis. Tal cual…