El RGPD, que entró en vigencia en mayo de este año, ha afectado seriamente el mercado de marketing en Internet. A sus participantes les gustaría formar la audiencia más precisa para mostrar anuncios, pero ahora para esto es necesario obtener el consentimiento explícito del usuario, de lo contrario, incluso un pequeño recurso de nicho puede generar multas multimillonarias. Algunos recursos se han cerrado, pero muchos se están convirtiendo para cumplir con nuevos requisitos. Y nuestro proyecto de un servicio de gestión de campañas publicitarias para un cliente de EE. UU. Es un gran ejemplo de esto.
Acerca del servicio
Nuestro cliente, una empresa estadounidense de Los Ángeles, se centra en el marketing en la industria de la música. Su servicio proporciona soporte para campañas publicitarias complejas para equipos de varios tamaños, desde pandillas a la vuelta de la esquina hasta las estrellas del escenario mundial.
De hecho, el servicio de nuestro cliente es una startup que desarrolla una plataforma de marketing especializada que logró recaudar inversiones de compañías discográficas, ya que tiene en cuenta los detalles del comportamiento de la audiencia en una industria en particular. La plataforma le permite orientar anuncios mediante el análisis del comportamiento de los usuarios que alguna vez mostraron interés en un equipo en particular. Los principales usuarios del recurso son músicos y trabajadores de la industria (gerentes, empleados de compañías discográficas, organizadores de conciertos y muchos otros).
Cuando comenzó nuestro proyecto, el servicio ya estaba funcionando y logró ganar una cierta posición en el mercado. Sin embargo, fue más bien un prototipo que probó la hipótesis básica de un negocio, especialmente porque parte de la funcionalidad se implementó a través de servicios de socios. Nos conectamos con el desarrollo para crear una arquitectura completa, y el GDPR fue el ímpetu que impulsó todas las transformaciones. Nuestra tarea no era solo actualizar el servicio existente, sino reconstruirlo con la nueva legislación, actualizar y llevar a una interfaz de usuario más uniforme.
Implementación
Todo el proyecto se dividió en varias etapas.
En la primera etapa, reescribimos desde cero la parte que anteriormente había funcionado en PHP: acortador de enlaces y servicio de autorización.
El acortador de enlaces es una parte de la funcionalidad que está disponible de forma gratuita para todos los usuarios registrados y se utiliza para atraer clientes a los servicios pagos de la compañía. El servicio le permite traer un enlace largo a un formulario corto para publicarlo en las redes sociales. Al mismo tiempo, puede personalizar el enlace configurando, por ejemplo, la segmentación geográfica: según el país de origen del usuario, se le pueden mostrar diferentes páginas de destino.
Actualizando el backend, utilizamos OpenJDK 1.8, Kotlin y Spring boot / data / web, el marco estándar para un proyecto que no espera grandes cargas. Por cierto, fue en este proyecto que probamos Kotlin "en batalla" por primera vez, y debido a su sintaxis, nos permitió acelerar significativamente el desarrollo. Definitivamente, lo usaremos en otros proyectos.
La base de datos del servicio de autorización y el acortador implementado en la primera etapa se basa en PostgreSQL: el modelo de almacenamiento de datos relacionales era muy adecuado para resolver estos problemas.
En la segunda etapa, asumimos la gestión de campañas publicitarias. Esta funcionalidad en la plataforma del cliente también existía antes, pero a través del servicio del socio, por el que tenía que pagar. Ahora la plataforma del cliente ha crecido hasta el punto en que era necesario cuidar su infraestructura. El servicio propio, a diferencia de los de terceros, es mucho más fácil de desarrollar en la dirección correcta, realizando rápidamente los cambios necesarios.
En esta parte del proyecto, implementamos solo la API externa para el administrador de campaña. Pero en la tercera etapa desarrollamos este módulo: finalizamos la API e hicimos una interfaz de usuario completa para el administrador de la campaña.
Paralelamente, desarrollamos una pequeña DMP (plataforma de gestión de datos) patentada que gestiona la recopilación de datos de visitantes. Los datos DMP se almacenan en MongoDB, porque decidimos dejar las bases para el futuro escalado horizontal de esta base de datos. Ahora DMP atiende hasta 2 mil solicitudes por segundo (en picos), mientras nos centramos en almacenar aproximadamente un terabyte de datos. Tal volumen podría haberse guardado en PostgreSQL, pero a la larga habría sido necesario hacer grandes esfuerzos para escalar.
El mismo MongoDB se usa en la base de datos del administrador de campaña (Campaign DB): aquí el modelo de una base de datos orientada a documentos nos fue muy útil. Las campañas van como entidades individuales y pueden expandirse.
Todos los cachés funcionan en Redis.
Frontend: Angular 5, TypeScript, HTML5, Sass, Node.js, npm, Angular CLI.
Durante la última etapa del proyecto, completamos la integración de los sistemas del cliente y los servicios de un socio clave, abriendo el acceso a una gran base de músicos para la compañía, lo que garantizará un aumento en el número de usuarios.
Hubo algunas dificultades en el proyecto. El cliente quería guardar los datos del usuario y los registros acumulados durante la operación del servicio, mientras cambiaba ligeramente el modelo. Paralelamente a la alteración de la arquitectura, transferimos registros y cambiamos sus principios: de nombre de usuario a correo electrónico como inicio de sesión, lo que nos trajo muchas noches sin dormir debido a restricciones en el número de usuarios con la misma dirección de correo electrónico. El modelo de derechos en el sistema ha cambiado. Anteriormente, el servicio funcionaba de acuerdo con un modelo de dos niveles, pero implementamos un modelo de derechos sin restricciones (incluida la capacidad de emitir derechos limitados).
Al mismo tiempo, la funcionalidad se expandió. Por ejemplo, en una de las etapas en las que aparecieron varios niveles, con la ayuda de los cuales los visitantes finales que hacen clic en enlaces cortos a una composición específica, pueden configurar páginas con una lista de servicios donde estas composiciones están disponibles para compra legal o para escuchar.
Vale la pena decir por separado sobre GDPR
El principal mercado de nuestro cliente es Estados Unidos, pero alrededor del 10% del tráfico que la empresa no quería perder provenía de Europa. Desde que entró en vigor la nueva regulación (25 de mayo de 2018), su objetivo simplemente se ha deshabilitado. Después de consultar con abogados, creamos el servicio de tal manera que no contradijera el GDPR, y desde el 16 de agosto comenzamos a apuntar nuevamente.
Honestamente, estudiamos las complejidades de las regulaciones en todo el grupo de dos semanas. La dificultad en esta etapa fue que, con la vaguedad general de la redacción, hasta ahora no existe una práctica de aplicación de la ley, casos reales que podrían mostrar cómo hacerlo bien y qué está mal. Sin embargo, ahora (después de nuestra propia investigación y consulta con abogados) confiamos en la arquitectura implementada de la solución.
La lógica del servicio implicaba agregar un usuario que sigue un enlace corto a una audiencia específica, para que luego se le puedan mostrar anuncios. En términos de GDPR, esto no puede hacerse sin el consentimiento explícito del usuario. E implementamos una solicitud de consentimiento: cuando hace clic en el enlace en la parte inferior de la página, aparece una placa con una pregunta y dos botones. La solicitud se abre para usuarios cuya IP pertenece a Europa, y su respuesta se almacena en forma de cookies, por lo que los visitantes no tienen que presionar botones cada vez.
Si no hay consentimiento del usuario (es decir, cookies), simplemente no le mostramos un píxel, es decir En las estadísticas generales del servicio, se contará el hecho de la visita, pero los datos del usuario no se recopilarán ni se tendrán en cuenta.
El RGPD impone restricciones arquitectónicas: los datos personales no solo deben recopilarse correctamente, sino también almacenarse de forma segura. En nuestro caso, estas restricciones se aplican al DMP implementado (a pesar del hecho de que almacena datos anónimos con identificadores anónimos que solo hipotéticamente les permiten desanonimizar) y la base de datos del servicio de autorización. En nuestra arquitectura, estas bases están claramente asignadas en bloques separados. De acuerdo con las regulaciones, el acceso de terceros a estos módulos "sensibles" es naturalmente limitado.
Solo el servicio correspondiente tiene acceso a la base de datos de autorizaciones. Todos los demás servicios no saben nada sobre los datos personales del usuario de la plataforma; solo necesitan validación del servicio de autorización.
La base de datos DMP también incluye solo el servicio homónimo. Al mismo tiempo, solo los agregados de datos de audiencia se devuelven de la base de datos, pero no los datos en sí. Estos agregados forman la base de los análisis que los usuarios del servicio de la industria de la música reciben en su cuenta personal.
También tenemos un procedimiento obligatorio para cargar y eliminar datos de usuario. Hubo una pregunta sobre cómo verificar que el usuario realmente está solicitando sus datos de manera legítima. Y utilizamos la cookie almacenada por el usuario como factor de verificación.
El proyecto se completó recientemente, por lo que es demasiado pronto para hablar sobre los resultados numéricos.
Autor del artículo: Nikolay Eremin
PD: publicamos nuestros artículos en varios sitios de Runet. Suscríbase a nuestras páginas en
VK ,
FB o
Telegram-channel para conocer todas nuestras publicaciones y otras noticias de Maxilect.