Índice general i
Índice de figuras iii
Índice de cuadros v
Acrónimos vii
Resumen ix
1 Introducción 1
1.1 El negocio . . . 1
1.2 Necesidad comercial . . . 2
1.3 Tecnologías involucradas . . . 3
1.4 Planteamiento del problema . . . 4
1.5 Objetivos . . . 5
2 Desarrollo del sistema de sincronización de contactos 7 2.1 Planificación . . . 8
2.2 Análisis . . . 10
2.2.1 Stakeholderso interesados . . . 10
2.2.2 Requisitos del producto . . . 11
2.2.3 Las listas de contactos . . . 13
2.3 Diseño e implementación . . . 17
2.3.1 Disparadores . . . 19
2.3.2 Núcleo del sistema: servicios y cliente . . . 26
2.4 Pruebas . . . 39
2.4.1 Pruebas unitarias . . . 39
2.4.2 Pruebas de integración . . . 44
3 Conclusiones 47 A Anexo 51 A.1 Código fuente de productores-consumidores . . . 51
A.2 Código fuente de servicios . . . 56
A.3 Tests de servicios . . . 72
A.4 Código fuente del cliente . . . 87
A.5 Tests del cliente . . . 110
Bibliografía 129
2.1 Incorporación del proyecto a la forma de trabajar del equipo. . . 10
2.2 Matriz de interés-poder . . . 11
2.3 Estado inicial de suscriptores . . . 15
2.4 Tipos de datos soportados por elInterspire Email Marketer(IEM) . . . 17
2.5 Diagrama del sistema de sincronización . . . 19
2.6 Cola de Beanstalk . . . 20
2.7 Diagrama de transición de estados del usuario . . . 23
2.8 Principales tablas implicadas en la sincronización. . . 24
2.9 Núcleo del sistema . . . 26
2.10 Estructura de los servicios . . . 27
2.11 Funcionamiento delDependency Injection(DI) para la obtención del cliente. Si es la primera vez que se solicita toma el camino (1) creando el cliente a partir de sus especificaciones, de lo contrario obtiene el cliente guardado en memoria la primera vez que se creó(2). . . 31
2.12 Inicialización del cliente, desde que es solicitado hasta que se obtiene y está listo para su uso. . . 32
2.13 Funcionamiento del cliente durante una operación cualquiera ejecutada desde uno de los servicios. . . 34
2.14 Diagrama de flujo de la suscripción . . . 46
3.1 Volumen de suscriptores antes y después . . . 47
3.2 Ritmo de crecimiento de suscriptores . . . 48
2.1 Coste de los recursos . . . 8 2.2 Presupuesto del proyecto . . . 9 2.3 Lista deCustom Field(s)(CF) implicados en la sincronización. . . 18
IEM Interspire Email Marketer BD Base de Datos
BBDD Bases de Datos
RSI Retorno Sobre la Inversión
MVP Producto viable mínimo oMinimum Viable Product B2C Business-to-Consumer
API interfaz de programación de aplicaciones SO Sistema Operativo
CF Custom Field(s) TTL Time To Live DI Dependency Injection PK Primary Key
MVC Modelo-Vista-Controlador
La empresa de InternetHabitissimoutiliza una herramienta llamada IEM para llevar a cabo las campañas deMarketingdirigidas a los usuarios de su plataforma web. Estos usuarios se dividen en dos tipos. Por una parte se encuentran los profesionales, em- presas o autónomos del sector de obras y/o reformas que quieren encontrar clientes, mientras que por otro lado están los particulares, personas interesadas en solicitar presupuestos a profesionales de su zona.
Si bien esta es la base del modelo de negocio no se limita solo a ello. Existen otros componentes destinados a retener al usuario que juegan un papel importante en las campañas deMarketing. Un ejemplo de ello es la sección de contenidos, pensada para atraer al usuario y que sirve de fuente de inspiración en muchas de las campañas. Con este enfoque y el IEM como herramienta de referencia se pretende mejorar y facilitar la forma en la que se gestionan los contactos.
El problema actual reside en que el IEM funciona con su propia Base de Datos (BD) descentralizada e independiente de la BD de Habitissimo, de modo que para enviar campañas deMarketingcon dicha herramienta hay que transferir los datos de Habitis- simo al IEM. Proceso que, hasta la fecha, se realiza esporádicamente y de forma manual mediante la exportación de los usuarios de Habitissimo y la posterior importación al IEM como contactos. Esto incurre en varios inconvenientes: el tiempo de dedicación para realizar la importación cada vez que se requiere actualizar datos, el desfase acumu- lado en los datos(datos que sobran, datos que faltan y datos des-actualizados) durante el tiempo transcurrido entre importaciones, el no poder garantizar de ningún modo la fiabilidad del resultado y el hecho de orientar las campañas a un nicho de mercado inapropiado. Todos estos inconvenientes derivan, al final, en un Retorno Sobre la Inver- sión (RSI) que dista del potencial total. Además, la mala gestión de los datos puede llevar a un incumplimiento de la Ley Orgánica de Protección de Datos de Carácter Personal[1].
La solución propuesta para este proyecto apuesta en primera instancia por analizar cómo funciona el IEM, qué uso o qué utilidad se espera obtener de esta herramienta y cuál es la información con la que se trabaja o se espera trabajar. Finalmente, tras anali- zar esta información, se modelará y desarrollará el sistema que permitirá actualizar y mantener sincronizada ambas plataformas de forma automática para así sacarle más rendimiento a todo su potencial.
Una vez obtenida una versionalfa[2] del producto se observó durante la fase de pruebas que, con los recursos y medios disponibles, no era factible alcanzar los obje-
tivos propuestos inicialmente. Encontramos un cuello de botella en la capacidad de procesamiento que hace improbable el poder sostener la sincronización en tiempo real, al menos no sin afectar o perjudicar significativamente al resto del negocio. La medida adoptada para solventar el problema fue recurrir a la metodología deProducto viable mínimo oMinimum Viable Product(MVP)[3] y reajustar los requisitos del producto.
Se establecen así una frecuencia de actualización sobre un conjunto específicos de usuarios apto para cubrir las necesidades de negocio.
C
APÍTU1
I NTRODUCCIÓN
1.1 El negocio
Habitissimo S.L.[4] es una empresa de Internet creada en 2009 con presencia en varios países de Europa y América Latina. Sirve como plataforma para conectar la oferta y la demanda del sector de obras y reformas del hogar, ofreciendo la posibilidad de que particulares puedan solicitar presupuestos de profesionales, y que, a su vez, empresas o autónomos puedan encontrar trabajos y ofrecer sus servicios como profesionales del sector.[5]. El elemento innovador introducido por Habitissimo consiste en que el particular no paga nada, directa o indirectamente, por solicitar el presupuesto. A diferencia del modelo tradicional, en el que la solicitud de presupuesto implica un coste que, a veces, podía descontarse del presupuesto si finalmente era aceptado por el particular. En este nuevo modelo de negocio son los profesionales quienes pagan para poder contactar con el particular y ofrecer así sus servicios, sin compromiso alguno por parte del particular.
El nexo de unión es la solicitud de presupuesto, a menudo considerado y con- tabilizado comolead[6, p. 72] para la compañía, aunque por definición podríamos considerar, como tal, cualquier usuario que rellene total o parcialmente el formulario de registro, que no implica necesariamente la creación de una solicitud de presupuesto.
Para este elemento clave se dispone de unalandingespecífica[7], la cual tiene un for- mulario diseñado para orientar al particular a la hora de describir, de la mejor forma posible, el tipo de trabajo que necesita realizar. De esta forma los profesionales podrán valorar si el trabajo en cuestión es de su interés para después apuntarse, previo pago, a esa solicitud. Siempre y cuando no se hayan apuntado ya 4 empresas, el máximo permitido por solicitud.
Cabe destacar que a pesar de coexistir dos perfiles de usuarios distintos, particulares y profesionales, y debido al modelo de negocio mencionado, solo es considerado como cliente[8, p. 3] el usuario profesional que compra y tiene activo algunos de los paquetes
premiumofrecidos.
1.2 Necesidad comercial
El marco de trabajo en el que se engloba este proyecto se sitúa dentro del ámbito del MarketingDigital[6, p. 47,265][9]. En concreto se centra en la técnica conocida como email marketing, que es en la que se basa y se especializa la herramienta IEM con la que debemos trabajar que se utiliza con una estrategiaBusiness-to-Consumer(B2C), puesto que los destinatarios son los clientes finales de Habitissimo.
La plataforma Habitissimo es un ecosistema en el que conviven el cliente —el profesional— y el particular. Este es un sistema delicado debido a que se debe balan- cear constantemente la oferta y la demanda.
Si se quiere ofrecer un buen servicio al cliente se debe garantizar que éste tenga una demanda los suficientemente grande —solicitudes de presupuesto— como para poder conseguir trabajos por medio de Habitissimo. Esto implica que, a pesar de no ser cliente de Habitissimo, el particular es tan importante como el profesional, dado que de él depende modelo de negocio. Del mismo modo, es igual de crítico a la hora de escalar el negocio ya que buscar y captar clientes no funcionará si no existe un volumen de particulares que los sustente.
Este equilibrio deseado se entiende como la situación en la que todas las solicitudes tienen la posibilidad ser escogidas por algún profesional, y que a su vez, todos los pro- fesionales puedan tener la posibilidad de conseguir algún trabajo. Para considerar que se cumple esta condición, dada una solicitud presupuesto y una empresa o profesional cualquiera, diremos que son candidatos entre ellos si el tipo de trabajo y la localización de la solicitud coinciden con el sector al que se dedica la empresa y la región en la que opera.
¿Qué puede aportar elEmail Marketing?
ElEmail Marketinges un herramienta útil para conseguir ambos objetivos: ofrecer un buen servicio y escalar. Con el envío de campañas se puede analizar la respuesta de los usuarios a partir de las métricas y resultados obtenidos, como el interés o nivel de actividad que muestran según la región, el tema, o las características del usuario.
Esto arroja información valiosa del estado del mercado que podría aplicarse tanto para ofrecer un mejor servicio a los clientes como para obtener una visión de hacia dónde se puede situar el foco a la hora de escalar.
Por ejemplo, supongamos que tras el envío de una campaña dirigida a particulares de Madrid con proyectos de construcción de piscinas observamos lo siguiente: la tasa de apertura del correo es muy elevada, y que además, se ha visto un aumento de solicitudes o consultas relacionadas con piscinas. Es posible entonces, aplicar medidas para retener e incentivar a las empresas que ya forman parte del directorio y que se
dedican a este sector, al mismo tiempo que se dedican recursos y esfuerzos en intentar captar más empresas de este tipo.
1.3 Tecnologías involucradas
La principal tecnología es el IEM[10], un software de pago de interspire[11] desarro- llado en PHP[12] que cuenta con una interfaz de programación de aplicaciones (API) XML[13]. Este software funciona en un servidor web con un Sistema Operativo (SO) Linux[14] y una BD MySQL[15] acorde a los requisitos[16].
Por otra parte se encuentra la página web, que es el núcleo del negocio. Existe una versión para cada país en el que se opera, aunque en realidad el código fuente es el mismo para todos. Éste se encuentra desarrollado principalmente en PHP con el frameworkSymfony[17]. Symfony utiliza un patrón de arquitectura basado enModelo- Vista-Controlador(MVC), que consiste en separar la lógica de negocio y los datos de la interfaz de usuario por medio de tres componentes: el modelo, la vista y el controlador.
Dónde el modelo representa la información con la que el sistema opera, la vista presen- ta la información que recibe del modelo en el formato propicio para interactuar y el controlador hace de intermediario entre ambos respondiendo a eventos y haciendo peticiones al modelo. Alrededor de la página web se despliegan el resto de servicios y tecnologías que dan soporte al negocio y al trabajo diario de los empleados. En lo que a este proyecto concierne cabe destacar algunos de estos servicios de soporte que, por su implicación, pueden ser relevantes durante el desarrollo.
En cuanto a información, hay unos servidores de Bases de Datos (BBDD) MariaDB[18]
que usan una replicaciónMaster-Slave, de modo que las escrituras se centralizan en el servidor con rol de master y éste se encarga de hacermirroring[19] a los nodosslavede solo lectura.
Otro servidor se encarga de procesar diversas tareas mediante Beanstalkd[20].
Beanstalk es una cola de trabajos de propósito general diseñada para ejecutar tareas que consumen tiempo de forma asíncrona. Funciona como una cola de mensajes compuesta de una serie de tubos, uno por cada tipo de tarea específica a realizar. Para añadir una tarea a la cola se envía un mensaje al tubo pertinente con los datos nece- sarios para interpretar y ejecutar la tarea, eventualmente este mensaje es recuperado por un proceso que se encarga de consumir estos trabajos. Por tanto debe existir un proceso consumidor por cada tipo de trabajo que irá asociado al tubo correspondien- te. Los criterios para escoger este sistema de procesamiento son varios, de entre los cuáles esperamos encontrarnos dos de ellos. El primero es cuando la tarea en cues- tión requiere de una consulta costosa a BD y el segundo cuando depende de un API externa, en este caso la del IEM, de la que no podemos controlar los tiempos de petición.
Por último, se utiliza Redmine[21] para la gestión de proyectos y Sentry[22] co- mo herramienta de gestión de errores, que captura y centraliza todos los errores y excepciones generadas en toda la infraestructura.
1.4 Planteamiento del problema
En el IEM los contactos se organizan por listas. Como Habitissimo es una empresa mul- tinacional los contactos se organizan en primera instancia por país y tipo de usuario, usando una nomenclatura descriptiva para nombrar las listas de la forma“<tipo de usuario><código país>”(Ej: particulares ES). En el caso de profesionales o negocios se llega a otro nivel de refinamiento, distinguiendo entre clientes —profesionales que tienen un paquete de pago activo— y no clientes, que además al poder guardar campos personalizados para los contactos podemos guardar información adicional como el tipo de paquete comprado por el cliente.
Estas listas se importaron inicialmente sin mantenimiento posterior alguno, por lo que con el transcurso del tiempo han dejado de reflejar con exactitud el estado real.
Podemos encontrar casos como usuarios que se hayan dado de baja del boletín o de su cuenta que ya no deberían constar en ninguna lista, nuevos usuarios registrados que no constan en ninguna lista y clientes que han pasado a ser ex-clientes o viceversa que no aparecen en la lista que deberían.
A la hora de preparar y seleccionar los contactos para enviar una campaña hay tres opciones:
• Usar las listas básicas iniciales
Tiene la ventaja de que una vez creada la campaña —la plantilla de correo electrónico— enviarla a través de una de estas listas es inmediato. No obstante resulta poco efectivo. En los casos en que la campaña va destinada a un círculo más reducido que el que ofrecen estas listas, se estarían enviando correos no deseados a aquellas personas pertenecientes a las listas que no encajan con el perfil deseado. Tampoco existe la certeza de que los contactos de la lista estén activos o sigan perteneciendo a la lista —recordemos los clientes que pueden con- vertirse en ex-clientes. Con estas incógnitas e inexactitudes resulta complicado sacarle el máximo partido a la herramienta y mucho menos medir los resultados de forma fiable.
• Crear nuevas listas para grupos específicos
La ventaja de este método es que se puede ajustar con mayor precisión el grupo objetivo, útil en campañas con temáticas concretas, a la vez que se garantiza que en el momento de enviar la campaña los datos serán significativamente más fiables —existe un pequeño margen de error por el lapso de tiempo entre el momento de crear la lista y el envío de la campaña.
El principal inconveniente de este proceso es que requiere de un proceso manual y costoso, cada vez que se envía una campaña nueva, para obtener la lista de contactos que cumplen con los requisitos. Este proceso se realiza por un técnico y cuanto más específico y más requisitos deban cumplir los usuarios más com- pleja será la consulta que deba realizar para extraer la información de la BD y finalmente importarla al IEM.
Otros problemas derivados de este proceso es que se acumulan listas generadas de esta forma, que al igual que las listas básicas, acaban estando desfasadas con el paso del tiempo. Estas listas, además de ocupar espacio adicional, son poco eficientes, ya que replican información que puede estar contenida en otras listas. Por ejemplo, la listaparticulares Baleares, a pesar de ser más precisa, está replicando contactos que ya están guardados en la listaparticulares España.
• Utilizar segmentos y campos personalizados
Esta es una opción que no es viable por el momento basada en el uso de una fun- cionalidad que ofrece el IEM, la posibilidad de utilizar segmentos. Los segmentos son un tipo de listas dinámicas creadas a partir de un subconjunto de contactos de una lista —no se puede crear a partir de otro segmento.
La forma de especificar el subconjunto es mediante una o varias reglas aplicadas sobre una o varias listas en función del valor de los campos del contacto. Los usuarios de la lista que cumplan todas las condiciones que se hayan definido aparecerán automáticamente en el segmento correspondiente, que es visualiza- do como cualquier otra lista.
La ventaja de este método es que una vez definidas las condiciones para pertene- cer al segmento no es necesario volverlo a actualizar, es suficiente actualizar la lista original para que los cambios se vean reflejados en todos los segmentos que derivan de él. Siguiendo con el ejemplo anterior, suponiendo que los contactos de la lista tengan un campo personalizado que sea “región”, podemos construir el segmentoparticulares Balearesaplicando la condición[región=Baleares]sobre la lista departiculares España.
Esta es, con diferencia, la mejor opción de todas. Requiere solo de unas pocas listas de contactos, sin embargo estas listas deben mantenerse actualizadas y contener información suficiente de los contactos —por medio de los campos personalizados— como para poder crear los segmentos según las necesidades de las campañas.
1.5 Objetivos
A lo largo del proyecto estudiaremos y desarrollaremos la forma más viable de solventar el problema de sincronización y gestión de contactos del IEM buscando un enfoque orientado a segmentos.
Para comenzar analizaremos, por la forma de funcionar y de utilizar la herramienta, cuál será la estructura de datos más adecuada en relación a la gestión de los contactos y su información: qué tipos de listas bases o primitivas serán necesarias, qué tipo de segmentos se esperan poder construir, qué datos son clave para la construcción de segmentos y cuál es su naturaleza.
Al final se pretende conseguir tener unas listas de contactos sincronizadas con la información correspondiente de Habitissimo sin necesidad de que haya una interven- ción manual, de forma que se puedan crear segmentos en función de sus características que puedan ser utilizados como objetivo fiable para las campañas a enviar.
C
APÍTU2
D ESARROLLO DEL SISTEMA DE SINCRONIZACIÓN DE CONTACTOS
A lo largo de esta sección explicaremos cada una de las fases, etapas e hitos que abarca el desarrollo completo del proyecto. Estas fases contemplan la planificación, el análisis, diseño, implementación y por último las pruebas.
Para comenzar, en la planificación describiremos el plan establecido como línea de base del cronograma, el presupuesto y la metodología de trabajo. Este plan concilia tanto necesidades específicas del proyecto como de la empresa en la que se enmarca, es decir, que el plan no viene determinado solo por el proyecto y las personas impli- cadas en él, sino que viene influenciado en mayor o menor medida por los planes y políticas del equipo, departamento y empresa. Seguidamente explicaremos el análisis realizado para identificar, categorizar y describir el colectivo de individuos interesados, los requisitos del producto y conocer los elementos clave que conciernen al proyec- to para definir una imagen del estado inicial del que partimos. A continuación nos adentraremos en el capítulo más amplio de todos, el del diseño e implementación del componente software desarrollado, que aunque son conceptos diferentes—diseño e implementación— los introduciremos en paralelo siguiendo una estructuratop-down, con la que esperamos facilitar la asimilación de la información. Empezando por una visión general de todo el sistema en conjunto a modo de mapa conceptual, con los principales componentes y la relación o interacciones entre ellos e ir profundizando en cada uno hasta comprender la utilidad y el funcionamiento de todos ellos. Final- mente, hablaremos sobre la batería de pruebas diseñadas y realizadas con la con el fin de contrastar los resultados con respecto a las expectativas para validar o verificar el comportamiento, o en su defecto, extraer información que justifique si es necesario re-definir los objetivos y si es posible asumirlos.
Recurso Coste/Semana(Euros)
Desarrollador 175
Responsable IEM 417
Product Owner 479
Cuadro 2.1: Coste de los recursos
2.1 Planificación
Debido a la metodología de trabajo utilizada, la cual explicaremos más en detalle a continuación, no se cuenta con una planificación rigurosa y detallada. En su lugar contamos con una estimación preliminar del período aproximado en el que se acotará el desarrollo del proyecto que constituirá la línea de base del cronograma. Esta estima- ción no incluye en ningún caso el desglose de tareas a realizar ni su relación u orden lógico.
El proyecto está planificado para ser realizado en un plazo de dos meses que se dividen en cuatro iteraciones, de dos semanas cada una. En cada iteración se reduce progresivamente el tiempo de dedicación del desarrollador encargado, hasta que final- mente se termine el proyecto.
El presupuesto se realiza solo en función del tiempo de dedicación de las personas implicadas, ya que por la metodología de trabajo y sobretodo, por tratarse de un pro- yecto interno, no se realizan estimaciones de costes indirectos ni amortizaciones de recursos materiales o intangibles. En cualquier caso si que se incluirían costes directos derivados del proyecto, como podría ser la compra de las licencias de software. Es el caso del IEM, que al ser software comercial requiere de una inversión, pero dado que ya se contaba con una licencia vitalicia no se incluye dentro del presupuesto.
Por tanto el presupuesto del proyecto se define en concepto del tiempo de dedica- ción de los RRHH y el coste de éstos por semana, como podemos ver en la tabla 2.1.
Un proyecto por definición no contempla tareas de mantenimiento ya que se consi- deran operaciones o procesos cíclicos, sino que se trata de un conjunto de actividades con un inicio y final previstos. Por ese motivo no se contempla como parte del proyecto abarcar estos temas. No obstante, aunque no forme parte del proyecto, desde un co- mienzo se conoce la necesidad de realizar monitorización y mantenimiento por parte de los responsables de operaciones además de posibles mejoras a medio-largo plazo desde alguno de los equipos de desarrollo. Por ese motivo el desarrollo se ha orientado a facilitar dichas tareas posteriores además de cumplir con los objetivos establecidos.
Metodología de trabajo El proyecto se lleva a cabo en Cliente Interno, uno de los equipos que conforman el departamento técnico de Habitissimo. Este equipo se encar- ga principalmente de desarrollar y mantener las herramientas y tecnologías utilizadas en el resto de departamentos, como son el panel de administración de la web o este sistema de sincronización. Aunque hay casos particulares en los que para determinadas
Iteración Recurso Dedicación( %) Coste(euros)
Desarrollador 75 262.5
Responsable IEM 15 125.1
1
Product Owner 20 191.6
Desarrollador 50 175
Responsable IEM 8 66.72
2
Product Owner 15 143.7
Desarrollador 20 70
Responsable IEM 5 41.7
3
Product Owner 7 67.06
Desarrollador 10 35
Responsable IEM 2 16.68
4
Product Owner 4 38.32
Total 1233.38
Cuadro 2.2: Presupuesto del proyecto
tecnologías se recurre a otros equipos o se forman otros nuevos.
Todo el departamento técnico se rige por la metodologíaScrum[23], por la que cada equipo cuenta con la figura deScrum Master, elProduct Ownery los desarrolladores.
Como la figura de cliente para el equipo de Cliente Interno viene representada por los miembros de otros departamentos, es con estos con los que debe tratar elProduct Ownerpara determinar y priorizar el trabajo que se debe realizar en el equipo.
Al hacerScrumel trabajo se organiza y realiza en ciclos de 2 a 4 semanas de dura- ción llamadossprints. Siendo 2 semanas la duración predeterminada para el equipo de Cliente Interno. Durante lossprintsse realiza una lista cerrada de tareas planificadas y priorizadas que definen el objetivo a perseguir. Este proyecto es uno de esos trabajos, donde el cliente ostakeholder[24] es el responsable del departamento deRocketissimo
—deparatamento de Marketing focalizado en usuarios particulares encargado de ges- tionar, en el que se utiliza el IEM y desde donde ha surgido la necesidad de realizar el proyecto. Por otra parte fue elProduct Ownerquien atendió las necesidades del cliente y tomó la decisión de admitirlo debido al valor que aporta al negocio.
Como el proyecto se realiza sujeto a las condiciones del equipo y las de la meto- dología no es posible dedicarse en exclusiva al proyecto desde su comienzo hasta su finalización. En su lugar se opta por desarrollarlo progresivamente atendiendo el resto de tareas y funciones propias del rol que se ejerce en el equipo. Por ello el proyecto se organiza y divide en tareas más pequeñas que se incorporan a lossprintsjunto con otras tareas tal y como se describe el figura 2.1.
Figura 2.1: Incorporación del proyecto a la forma de trabajar del equipo.
2.2 Análisis
En este apartado analizaremos y determinaremos las especificaciones y necesidades que debe cubrir el proyecto. Para comenzar identificaremos los actores de este escena- rio, es decir, todas aquellas personas que tienen o podrían tener algún tipo de interés en el proyecto. Atendiendo cada caso en particular para concluir cuáles son estos intereses y qué influencia pueden ejercer sobre el proyecto, información que en algunos casos puede ser proporcionada por el propio interesado. A continuación recopilaremos la lista de requisitos que debe satisfacer el producto, que al ser aprobados por el solici- tante sentará las bases de lo que podemos definir el alcance del proyecto. Por último estudiaremos las listas de contactos, el elemento clave entorno al que gira el proyecto.
Por ese motivo describiremos tanto el concepto como su utilidad y el estado real en el que se encuentran, así como la relevancia y la relación que tienen con el proyecto.
2.2.1 Stakeholderso interesados
Hay varios personajes interesados en el desarrollo de este proyecto que pueden verse clasificados por el nivel de interés y poder que tiene por el proyecto en la figura 2.2.
Los principales son por una parte el solicitante y todos los posibles usuarios del IEM,
que desean que los contactos se mantengan sincronizados sin necesidad de intervenir, mientras que por otro lado se encuentra el tutor o supervisor de Habitissimo designado para el proyecto y las prácticas.
El tutor además de orientar al alumno en el desempeño de sus funciones y apren- dizaje, representa los intereses del negocio en cuanto a garantizar la integridad de la infraestructura tecnológica, aunque en este rol pueden participar otros miembros del departamento técnico en procesos tales como la revisión de código.
Figura 2.2: Clasificación de los interesados según su interés y poder o capacidad de influir en el proyecto
Cabe destacar la figura delProduct Owner, quien por definición representa a todas las partes interesadas y vela por el cumplimiento del resto de objetivos marcados para el equipo, que pueden llegar a superar(o no) en prioridad a los de este proyecto. Si bien algunos de estos interesados a los que representa pueden llegar a ser considerados interesados negativos no tienen gran capacidad de influir, ya que la responsabilidad de autorizar y priorizar objetivos recae en elProduct Owner. El riesgo que implican estos interesados se limita a la posibilidad de que planteen nuevos objetivos que puedan ser considerados más prioritarios.
2.2.2 Requisitos del producto
Teniendo en cuenta los interesados identificados en el apartado anterior y la influencia que ejercen sobre el proyecto definimos los requisitos que debe satisfacer el producto final, clasificados en requisitos funcionales y no funcionales.
Requisitos funcionales
1. El servicio de usuarios de Habitissimo debe poder añadir un contacto nuevo a una lista de contactos ya existente. Cuando un usuario se suscribe o se sincro- niza por primera vez el contacto todavía no está en la lista del IEM, por lo que primero se debe añadir el contacto. Este caso se puede dar en 4 situaciones:
a) Durante la importación inicial al integrar el sistema y sincronizar todos los suscriptores de Habitissimo.
b) Cuando un usuario de Habitissimo con ficha activa se suscribe al boletín de noticias por primera vez desde que se integró el sistema(puede que lo hubiese estado anteriormente alguna vez).
c) Cuando se activa la ficha de un usuario que está suscrito al boletín. Esto se debe a que en el momento de registrarse en la web los usuarios pueden sus- cribirse al boletín pero su ficha de usuario queda pendiente de validación hasta que es revisada y aprobada por un técnico.
d) Cuando un suscriptor modifica su correo electrónico en su ficha de Habitis- simo y se le vuelve a registrar con el nuevo correo electrónico.
2. El servicio de usuarios de Habitissimo deberá poder dar de alta o baja a un contacto como suscriptor. La acción de dar de alta se produce en los mis- mos casos que en la de añadir un contacto, con la diferencia de que el usua- rio ya se encuentra registrado en la lista del IEM pero su estado es “no sus- crito(unsubscribed)”. La acción de dar de baja en cambio se produce en los siguientes 2 casos:
a) Cuando un usuario activo de Habitissimo que está suscrito al boletín se da de baja del boletín de noticias.
b) Cuando se da baja la ficha de un usuario activo de Habitissimo que está suscrito al boletín de noticias.
3. El servicio de usuarios de Habitissimo debe permitir actualizar los campos personalizados de un contacto de una lista determinada. Existen dos listas que se deben sincronizar, una para cada tipo de usuario de la web(particulares y profesionales) y cada lista tiene asociados unos campos personalizados que re- presentan cierta información sobre el contacto. Algunos de estos campos estarán presentes en ambas listas mientras que algunos serán específicos de cada lista, es decir, del tipo de usuario. Por ejemplo, un campo personalizado de la lista de profesionales es “membership”, que representa el pack contratado por el usuario.
4. El servicio de usuarios de Habitissimo debe sincronizar el estado de sus con- tactos con el del IEM. Incluyendo el estado de suscripción y los datos corres- pondientes a los campos personalizados. Esto significa que el sistema debe ser capaz de llevar a cabo la sincronización especificando tan solo el usuario de Habitissimo que se quiere sincronizar.
Requisitos no funcionales
1. En caso de producirse un error durante la sincronización con motivo de un evento o una acción en la web, no debe interrumpir la acción ni afectar al re- sultado de la misma. Por ejemplo, si un usuario se da de baja del boletín, aunque la sincronización falle el usuario será dado de baja sin interrupciones del boletín en su perfil de Habitissimo.
2. Debe estar integrado con el sistema de registro y/o monitorización de errores que haya disponible, que en este caso es Sentry, para detectar y notificar todos los posibles errores o comportamientos inesperados que se puedan producir.
Algunos errores que se pueden esperar:
a) Que el servidor en el que se aloja el IEM esté fuera de servicio y no respon- da(error 500).
b) Que la petición, sea cual sea, esté mal formada/construida. Se trata de una API XML y todas las peticiones deben estar correctamente estructuradas y con los datos necesarios.
c) Que se intente actualizar un contacto del IEM que no existe en esa lista.
Por ejemplo borrar un contacto manualmente y que el sistema intente actualizarlo más adelante presuponiendo que el contacto ya existía.
d) Que se intente añadir/actualizar un contacto a/de una lista que no existe.
Por ejemplo utilizar un identificador de lista erróneo.
e) Que se intente actualizar un campo que no pertenece a la lista: por ejemplo al incluir un campo nuevo a sincronizar que no se ha creado previamente en la lista.
3. Mantener todos los contactos sincronizados en tiempo real. Esto es, por cada usuario de Habitissimo que esté suscrito al boletín debe existir un contacto ho- mónimo en el IEM en estado suscrito y con sus datos completos acorde a los del usuario. Un contacto del IEM no contiene la misma información que se almace- na sobre un usuario de Habitissimo, por lo que no tendrá toda la información replicada, pero la información que contenga el contacto debe ser consistente con la del usuario. Un usuario que no esté suscrito puede, o no, tener su corres- pondiente contacto en el IEM mientras el contacto no esté activo. La situación se dará cuando un usuario que haya estado suscrito previamente se dé de baja, en cuyo caso en lugar de eliminar el contacto se desactiva o da de baja también del IEM y deja de actualizarse.
2.2.3 Las listas de contactos
Las listas de contactos y sus atributos es la forma básica de información del IEM. Por contacto entendemos un registro único, representado por una cuenta de correo electró- nico, que se corresponde con el de su usuario homólogo de Habitissimo. Cada contacto tiene además otro identificador numérico que es auto-generado y asignado en el mo- mento de crear el registro.
Hay que destacar que para considerar un usuario de Habitissimo como un suscrip- tor debe cumplir dos requisitos, el primero es que tenga un perfil de usuario activo
—todos los nuevos usuarios empiezan teniendo un perfil en estado pendiente que una vez revisado puede ser activado o denegado— y la segunda es que en su perfil debe tener marcada la opción de permitir el envío de boletines. Por otra parte, en el IEM un suscriptor se identifica sencillamente por el estado del contacto (activity status), el cual debe tener el valor“active”en oposición al estado“unsubcribed”, que indica la des-activación de la suscripción.
Elección de las listas a sincronizar
Para comenzar es necesario determinar qué listas van a ser las que se deben mantener sincronizadas, las cuales tienen que albergar todos los contactos a los que se pueden enviar campañas.
La forma más sencilla de organizar las listas parece ser la que atiende a país y ti- po básico de usuario. Esta organización refleja las forma más básica de clasificar la estructura de Habitissimo desde un punto de vista general, que son en función de la región, dónde el país es el nivel superior, y el tipo de usuario, que principalmente se distingue entre particular o profesional. Este tipo de organización ya está presente en el IEM a la hora de gestionar las listas, de modo que parece coherente seguir aplicando este mismo esquema.
Por tanto, las listas deberán ser dos por cada uno de los países: Brasil, Argentina, Chile,Venezuela, México, Colombia, España, Portugal y Francia. Una para particulares y otra para profesionales, sumando un total de 18 listas.
En adelante, salvo aclaración explícita, cualquier mención sobre listas de contactos se deberá entender como una referencia a las listas sincronizadas especificadas en este apartado.
Estado inicial
Inicialmente estas listas ya estaban creadas en todos los países, lo que podría ser una ventaja si implica que no es necesario sincronizar todos los usuarios. En cualquier caso desecharlas y utilizar nuevas listas no es una opción, dado que de este modo se perdería el histórico sobre el usuario, que incluye qué campañas se le enviaron, cuando fueron enviadas y cómo respondió el contacto —las métricas utilizadas en Email Marketing.
Como primera medida comparamos el volumen total de contactos y usuarios en el IEM y Habitissimo respectivamente, sin más criterio que el definido por la propia lista, que es el país y el tipo de usuario. Pronto observamos que el volumen no concuerda en ningún caso. El volumen de contactos en las listas es entre un 1 y un 5 % inferior al volumen de usuarios en Habitissimo. Estos datos todavía no son concluyentes puesto que en el IEM solo deberían registrarse aquellos usuarios que alguna vez han sido suscriptores, lo que podría explicar estas diferencias.
A continuación procedemos a realizar otra comparativa, esta vez centrada solo en los suscriptores. Aplicando este criterio esperaríamos encontrar, en una situación ideal, que todos los suscriptores se encuentran sincronizados correctamente, es decir, que los suscriptores de Habitissimo son los mismos suscriptores que aparecen en las listas.
Sin embargo la comparación nos muestra un resultado distinto, similar en todas las listas, que se puede ver reflejado en el diagrama de Venn de la figura 2.3.
U suar i os
M ar ket er
H abi t i ssi mo Si ncr oni zad os
Figura 2.3: Estado inicial de suscriptores activos con respecto a un país y tipo de usuario específico.
Las listas parecen tener un volumen mucho mayor de suscriptores, del rango de 2 a 4 veces más, que el volumen contabilizado en Habitissimo. Suponemos que los contactos que se muestran en la intersección están correctamente sincronizados y que, a priori, la representación de los suscriptores de Habitissimo es correcta por provenir o formar parte de la fuente misma de los datos, por lo que empezamos estudiando los contactos del IEM que aparentemente no deberían constar como suscriptores.
A partir del diagrama podemos definir este conjunto de contactos comoC0=C\U, siendoClos suscriptores del IEM —izquierda— yU los suscriptores de Habitissimo.
Escogiendo arbitrariamente varios de estos contactos pertenecientes aC0vemos que los usuarios correspondientes tienen dado de baja el perfil de usuario o al menos la suscripción al boletín, de lo que deducimos que no se estaba llevando a cabo ningún tipo de gestión para sincronizar las bajas, solo las altas, acumulando así suscriptores erróneos, lo que entra en conflicto con la Ley de Protección de Datos[1] que se mencio- na en el resumen.
Este hecho nos lleva a plantearnos cómo es el proceso de baja ya que de algún modo si que se está llevando a cabo. Anteriormente hemos visto que las listas contienen contactos que han sido dados de baja como bien refleja el estado de su suscripción.
Resulta que en las campañas se adjunta de forma automática un enlace para que el usuario pueda darse de baja. Este enlace no había sido modificado así que funcionaba con el definido por defecto por la aplicación. El problema es que de esta forma solo tiene efecto en el IEM, dejando la suscripción activa en Habitissimo. Esto explicaría también
por qué hay usuarios que solo aparecen como suscritos en Habitissimo —aquellos definidos comoU0=U\C.
Con este descubrimiento se acaba poniendo también en tela de juicio la fiabilidad de los datos de Habitissimo que en un principio se habían supuesto como fiables.
Además es posible que esta situación propiciase que eventualmente, al importar de nuevo contactos, se reactivase la suscripción de alguno de estos usuarios.
Tan solo nos queda por analizar aquellos usuarios suscriptores que pertenecen a los que supuestamente están sincronizados, que como cabría esperar aparecen tanto en el IEM como en Habitissimo. Si bien es cierto que estos contactos son correctos —en cuanto a que están registrados en la lista— tampoco son del todo fiables y el motivo se encuentra en los campos personalizados o CF. Los CF son utilizados para guardar información relativa al usuario contenida en la BD de Habitissimo que pueda ser útil en el IEM, algunos de estos campos son susceptibles de cambiar con el tiempo por lo que si no se actualizan también en el IEM es posible encontrar contactos con datos desfasados.
En definitiva podemos decir que el estado de las listas es inconsistente. Existen diversos factores que influyen corrompiendo una gran parte de los datos a distintos niveles, dificultando la posibilidad de discernir entre los datos correctos e incorrectos.
Requisitos de información
Antes de plantear el diseño del sistema es necesario determinar las necesidades de información con respecto a los contactos. Toda información adicional sobre los contac- tos debe gestionarse mediante el uso de los CF, por lo que primero debemos tener en cuenta algunas consideraciones sobre sus características.
Los CF no se asocian directamente al contacto sino a la lista. La asociación, que es una relaciónNaN, se puede hacer por tres vías: en el momento de crear el campo, desde la edición del mismo una vez creado, o bien desde la edición de la lista.
Estos campos pueden ser de varios tipos predefinidos, mostrados en la figura 2.4.
En cualquiera de ellos es posible indicar si se trata de un campo requerido o si tiene algún valor por defecto. Dependiendo del tipo de dato escogido es posible añadir otras condiciones que limitan los valores posibles para ese campo, como un rango de fechas límite, una longitud máxima, la lista de valores aceptados, etc.
Los datos que se quieren guardar fueron especificados en unissue—tiquet de Redmine donde se describen las especificaciones de lo que se quiere desarrollar. Estos datos vienen ya clasificados en función de si son para el particular, para el profesional o para ambos, lo que determina a que listas deben asociarse.
En la tabla 2.3 podemos ver una la lista de todos los CF a considerar. En ella se puede observar que algunos de ellos ya existían previamente, mientras que otros fueron solicitados a raíz de este proyecto. Todos estos campos se analizaron para localizar dón- de se encontraba dicha información y cómo extraerla, es decir, determinar la consulta
Figura 2.4: Tipos de datos soportados en los CF del IEM.
que se debe hacer a la BD para obtenerla.
Tras el análisis vimos que parte de la información requerida podía proporcionarse en un formato distinto de manera que, además de aportar la información deseada, podía aportar información adicional de potencial utilidad en el futuro. Todo ello sin aumentar la complejidad e incluso disminuyéndola en algunos casos.
Veamos un ejemplo en detalle: el campo “#17 - Solicitud de presupuesto” pretende reflejar la dicotomía —representado por el texto sí o no— de si el usuario ha solicitado presupuesto alguna vez. Si queremos traducir esto a una consulta debemos buscar presupuestos que estén relacionados con el usuario, dado que no es un dato que se encuentre guardado como tal en la BD.
Por tanto podemos limitar la búsqueda a un único resultado usando como criterio la fecha de creación más reciente, valor que tomaría el campo #17, ahora llamado último presupuesto. Así es ahora posible tener tanto el dato inicialmente solicitado, comprobando si la fecha está definida, como también determinar cuándo fue la última vez que lo hizo. Esto último resulta interesante pues es un indicador de si el usuario es activo.
Del mismo modo es posible optimizar varios de los campos, cuyo refinamiento está reflejado en los cambios marcados en negrita de las versiones definitivas.
2.3 Diseño e implementación
En este apartado describiremos los distintos componentes que formarán parte del sistema de sincronización siguiendo una estrategiatop-down[25], con el objetivo de aclarar los conceptos más sencillos y genéricos del diseño para después avanzar pro- gresivamente y profundizar en los detalles más técnicos de la implementación de cada
Campos existentes Campos solicitados Campos definitivos
# Nombre Tipo Nombre Tipo Nombre Tipo
Todos los usuarios
1 source name texto source name texto
2 source campaign texto source campaign texto
3 last login texto last login fecha
4 display name texto display name texto
5 salt texto salt texto
6 unsubscribe url texto unsubscribe url texto
7 birthdate texto birthdate fecha
8 user id numérico user id numérico
9 plataforma app texto plataforma app texto
10 version app texto version app texto
Solo profesionales
11 membership numérico membership numérico
12 memb. name texto memb. name texto
13 provincia texto provincia texto
14 subcategoría texto subcategoría texto
Solo particulares
15 cat. últ. presu. texto cat. últ. presu. texto
16 solicitud presu. booleano último presu. fecha
17 suscrito álbum booleano último álb. sus. fecha
18 like álbum booleano último like álb. fecha
19 suscrito proyecto booleano susc. proy. numérico
20 like proy. booleano último like proy. fecha
21 coment. proy. booleano último com. proy. fecha
22 fav. proy. booleano último fav. proy. fecha
23 rocket booleano rocket booleano
24 ame texto ame texto
25 tiene álbum booleano último álb. fecha
26 ha preguntado booleano última pregunta fecha
Cuadro 2.3: Lista de CF implicados en la sincronización.
uno de ellos.
Los componentes son los representados en el diagrama de la figura 2.5, de los cua- les solo la aplicación del IEM y la cola de trabajos —implementada con Beanstalk—
funcionan basándose en tecnología no desarrollada por Habitissimo. Mientras que el resto de componentes, sin contar el uso de librerías externas oframeworks, han sido desarrollados íntegramente con motivo de este proyecto.
El diseño está orientado a centralizar el control sobre la sincronización en la apli- cación principal de Habitissimo con el fin de disminuir las dependencias de servicios externos y facilitar el uso o mantenimiento. Modelo que se podrá apreciar mejor a me- dida que describamos con más detalle cada una de las piezas que conforman el sistema.
Figura 2.5: Diagrama del sistema de sincronización
2.3.1 Disparadores
Los disparadores son los sucesos que originan o ponen en marcha el proceso de sin- cronización. En función del tipo de disparador podemos distinguir entre dos tipos de sincronización: la sincronización por tareas y la sincronización por eventos. Al mismo tiempo se distinguen dos modos distintos de sincronización, la secuencial o síncrona y la asíncrona.
El modo síncrono consiste en realizar el proceso secuencialmente, esto es, realizar la operación u operaciones tan pronto como se acciona el disparador y mantenerse a la espera del resultado. Por tanto se trata de un método bloqueante, ya que no se realiza ninguna otra operación hasta que se obtiene la respuesta.
Puesto que todas las operaciones se realizan mediante una API a un servicio externo no es posible estimar ni controlar el tiempo de respuesta.
En el modo asíncrono el proceso se lleva a cabo siguiendo el patrón de productor- consumidor[26], realizándose en un segundo plano y sin interrupción de la ejecución.
Cuando se acciona un disparador que funciona en modo asíncrono se genera un traba- jo. Este trabajo no es más que una estructura de información que representa el proceso que debe llevarse a cabo. A continuación el trabajo es enviado a la cola de trabajos de Beanstalk, concretamente a un tubo específico designado a este tipo de tarea —los tubos son la forma que tiene Beanstalk de organizar trabajos en distintas colas, en la figura 2.6 se puede apreciar el listado de tubos.
En función de la prioridad asignada al trabajo, salvo que se agote su tiempo de espera oTime To Live(TTL), eventualmente llegará su turno. Momento en el que un consumidor de ese tubo, conocido comorunner, obtendrá el trabajo y lo procesará.
A continuación explicaremos en detalle cada tipo de disparador y los modos de sincronización utilizados en cada uno de ellos. En estos apartados explicaremos tam- bién como hemos tenido que re-definir uno de los objetivos al ver que no podía ser cumplido y plantear una alternativa que aporte una solución satisfactoria.
Figura 2.6: Cola de Beanstalk
Tareas
Las tareas otasksson comandos que se ejecutan en un momento determinado y llevan a cabo, como su nombre indica, una tarea o actividad específica para la que ha sido programada. En el caso que nos atañe se trata de una única tarea llamadaEmailMarke- terSynchronizeTask(Anexo 1, Listado 1) que se encarga de sincronizar un conjunto de usuarios.
La tarea se diseñó inicialmente con la idea de sincronizar constantemente todos los usuarios, tal y como exigía el último de los requisitos no funcionales. Pero al realizar pruebas en algunos de los países con menor volumen con el fin de medir la velocidad con la que se realizaba la sincronización. Vimos que en promedio en un entorno de pruebas esta velocidad era de 1.5 usuarios por segundo, velocidad que podría ser inferior en un entorno de producción con mayor carga de trabajo. Esto supone que sincronizar todos los contactos llevaría desde varios días hasta semanas, dependiendo
del país. Un período de tiempo demasiado largo como para ser aceptado. Tras plantear la problemática a los interesados se negoció una solución intermedia que consistía en definir un período de sincronización más amplio —en lugar de ser constante— y limitar el número de usuarios a sincronizar cada vez para y reducir así el volumen. De este modo se re-define el último de los requisitos no funcionales como lo siguiente:
Diariamente y de forma automática se realizará una sincronización de todos los usuarios activos y suscritos que hayan accedido a sus cuentas en las últimas 24 horas.
Tener los datos bien sincronizados juega un papel clave a la hora de enviar campa- ñas masivas a un conjunto de usuarios en función de los datos que se tienen de ellos, pero esto es solo una mínima parte del tiempo y siempre se puede llevar a cabo justo en el momento en el que los datos son más recientes —después de una sincronización—
durante el resto del tiempo no es tan relevante que algún contacto pueda tener parte de su información desfasada, teniendo en cuenta que el estado de la suscripción si que está sincronizada en tiempo real en todo momento.
Tras el cambio en los requisitos se modifica la tarea, además de poder sincronizar todos los contactos, poder sincronizar también solo el conjunto de usuarios que poten- cialmente podrían diferir con respecto al estado guardado en el IEM, es decir, los que podrían estar des-sincronizados.
El conjunto de usuarios que se sincronizan viene determinado por unas condicio- nes fijas y un parámetro de entrada. Las condiciones fijas son que el usuario debe ser un suscriptor válido, esto es, que el usuario tenga un perfil de usuario activo y la opción de suscripción al boletín también activo. Cualquier otro usuario puede ser descartado ya que su información resulta irrelevante, pues no será objetivo de ninguna campaña de marketing y puede ser descartado fácilmente en la segmentación de listas del IEM.
El parámetro de entrada está directamente relacionado con las dos formas de usar e integrar la tarea en el proceso a la vez que justifican la creación y uso de una herramien- ta como esta. Recibe el nombre deactiony acepta dos posibles valores:last_dayyall. A continuación explicamos que implicación tiene el uso de cada opción y la relación que tienen con el proceso de sincronización.
Parámetro“last_day”
Con esta opción, que es además la opción por defecto, indicamos que se quieren sincronizar, de entre los usuarios que cumplen la primera condición —ser un suscriptor válido, solo aquellos que accedieron a su cuenta en las últimas 24 horas.
La elección de la fecha de acceso como criterio se debe a que prácticamente cual- quier cambio en los datos está ligado a alguna acción del usuario, y por ende a que éste acceda a su cuenta. No obstante cabe aclarar que el acceso a la cuenta no implica necesariamente alguna modificación.
La elección del período viene dado por dos factores, las necesidades de uso de la herramienta y la carga de trabajo de la operación. En cuanto a rendimiento lo que interesa es utilizar la mínima cantidad de recursos y realizar el mínimo número de operaciones, con la menor frecuencia posible, para que estos recursos se liberen cuanto antes — no debemos olvidar que este proyecto forma parte de un sistema mayor con el que comparte recursos porque si los acaparamos otros sistemas se verán afectados y el resto del negocio se verá perjudicado.
Para determinar las necesidades se ha recurrido a entrevistar a losstakeholdersque dependen de la herramienta y conocen mejor el impacto que puede tener. Asumiendo que, en el peor de los casos, el margen de error son todos los cambios que se puedan dar entre sincronizaciones y que afecten exclusivamente a la información que se guarda en el IEM. Se ha llegado a la conclusión de que el período aceptable más prolongado es de 24 horas. Con este fin se ha utilizado la funcionalidad Cron de Linux para configurar un Cron Joben cada país que ejecute esta tarea diariamente a la misma hora con dicho parámetro.
En cualquier caso, e independientemente del parámetro utilizado, la tarea se ejecu- tará siempre en modo asíncrono por dos razones. La primera es el coste de la operación, al ser una sicronización completa implica obtener la información de cada CF del usua- rio y actualizarlos uno por uno. Esto implica múltiples peticiones al servidor del IEM, tantas como CF tenga el usuario además de otras peticiones implícitas en el proceso que veremos más en detalle en la descripción del cliente(2.3.2).
El segundo motivo y más importante para utilizar este método es el volumen de operaciones, siendo que cada operación equivale a la sincronización completa de un usuario. Este volumen puede oscilar entre aproximadamente varios miles de usuarios para el parámetro“last_day”, hasta más de un millón para el parámetro“all”en los países de mayor volumen. Multiplicado por el número de peticiones al servidor que se producen en cada operación, la ejecución de la tarea puede llegar a acumular fácil- mente varios millones de peticiones al servidor del IEM. Lo que no resulta viable de ningún otro modo que no sea un procesamiento progresivo, dilatado en el tiempo y no bloqueante, como el que ofrece el modo asíncrono.
Para el procesamiento progresivo la tarea divide la sincronización en pequeños trabajos que envía al tubo de Beanstalk designado para esta operación. Esta cola o tubo tiene un nivel de prioridad asignado deliberadamente de forma que no bloquee la ejecución de otras tareas mas importantes. Una vez llega el turno de ejecutar alguna de las tareas pendientes el trabajo es procesado por elrunnercorrespondiente que consumirá trabajos de ese tubo, donde cada trabajo consiste en sincronizar un único usuario y es llevado a cabo por elEmailMarketerSyncRunner(Anexo 1, Listado 2 ).
Parámetro“all”
Este valor indica que se sincronizarán todos los usuarios que cumplen las condicio- nes fijas, por tanto todos los suscriptores válidos que haya en ese momento, que son todos aquellos que se podrían incluir en campañas de marketing.
Debido al volumen de usuarios que implicaría, esta operación se reserva solo a la importación inicial, o tras aplicar ciertos cambios en el sistema de sincronización que
requiera actualizar los datos de todos los suscriptores.
Eventos
Es posible monitorizar un gran número de eventos, desde simplemente altas y bajas de suscriptores hasta eventos por cada cambio en los datos a sincronizar. En el mejor de los casos sería uno por cada campo personalizado, suponiendo que la información de cada campo se relacione con un único evento o acción en la web de Habitissimo.
Esto no resulta factible pues haría que el sistema fuese poco escalable y costoso de mantener. Así pues se han escogido los principales eventos que nos permite ajustar al diseño centralizado. Estos eventos se ven reflejados en el diagrama de estados de la figura 2.7.
Figura 2.7: Diagrama de transición de estados del usuario según la sucesión de eventos.
Cualquier transición que surja del estado S2—usuario activo y suscrito— o se dirija hacia él implica sincronizar al usuario.
En el diagrama de registro(ver 2.8) podemos ver las principales tablas relacionadas con el usuario y la sincronización. Por una parte se encuentran las generadas en el momento de registrarse: la tablahab_userque representa a cualquier usuario, la cual contiene información de primer nivel como el estado del mismo—pendiente, activo o denegado— o el tipo de usuario del que se trata—particular o profesional. Y la ficha de usuario(hab_user_profile) guarda información adicional menos relevante, como el estado de la suscripción al boletín.
En el momento de registrarse todos los usuarios, sin excepción, deben ser mode- rados antes de ser activados. Es después de esta primera activación que se crea un registro nuevo para ese usuario, en la tablahab_customersi es particular, o en la tabla hab_user_profile_businesssi es un profesional. Lo que significa que será probablemente la primera ocasión en la que el usuario se sincronice, salvo que el usuario haya desmar- cado la opción de recibir el boletín, algo que no suele ocurrir con frecuencia antes de la activación.
Figura 2.8: Principales tablas implicadas en la sincronización.
Alta de ficha y suscripción:
En el diagrama(ver 2.5) es representado como un único evento que conlleva una ac- ción, en este caso la de suscribir al usuario. En realidad se compone de dos eventos independientes que pueden producirse tanto simultáneamente como en momentos diferentes y en cualquier orden. El motivo de considerarlos como uno solo es que deben cumplirse ambas condiciones simultáneamente, es decir, el estado generado por cada evento.
• Alta de ficha o perfil:cuando un usuario se registra en Habitissimo el perfil de usuario se crea con un estado “pendiente”, que tras ser moderado pasa a ser rechazado o, por contra, aprobado, que es cuando consideramos que un usuario ha sido dado de alta.
• Alta de suscripción:el usuario tiene la opción de suscribirse al boletín de noticias, lo que incluye las campañas de marketing. Esta opción viene marcada por defecto en el formulario de registro y en caso de desactivarla en el proceso de registro puede activarse de nuevo desde el perfil de la cuenta en cualquier momento.
Por la misma razón argumentada en el caso de la tareaEmailMarketerSynchronize- Task2.3.1 este evento se procesaría de forma asíncrona. El número de operaciones es elevado, a lo que hay que añadirle la incertidumbre en cuanto a la frecuencia, ya que dependerá en gran medida de la actividad de los usuarios. Aunque cabe esperar que aumente proporcionalmente a medida que aumente el volumen de usuarios de la web.
Los trabajos de suscripción se añaden a la cola de Beanstalk, para más adelante ser consumidos por alguno de los siguientesrunners:
• SubscribeHabUserToMarketerRunner(Anexo 1, Listado 3): utilizado cuando un usuario que ya estaba registrado, sin importar del tipo que sea, cambia el estado de su suscripción o el de su ficha.
• SubscribeCustomerToMarketerRunner(Anexo 1, Listado 4): utilizado cuando se realiza el alta de un nuevo perfil de particular.
• SubscribeBusinessToMarketerRunner(Anexo 1, Listado 5): utilizado cuando se realiza el alta de un nuevo perfil de profesional.
Baja de ficha o suscripción:
Al igual que ocurre con el alta de la suscripción, la baja se compone de dos eventos que llevan asociados la des-activación de la suscripción. Estos eventos son los opuestos a los anteriores y a diferencia de ellos es suficiente con que se produzca uno de ellos para tramitar la baja.
• Baja de ficha o perfil:cuando un perfil de usuario activo se da de baja transfi- riéndolo al estado “inactivo”.
• Baja de suscripción:se produce al registrase desmarcando la opción de recibir el boletín o bien desde el perfil de la cuenta una vez registrado.
En este caso el modo utilizado es síncrono ya que para dar de baja a un contacto del IEM solo se necesitan realizar unas pocas peticiones. Que no varían en número y la frecuencia con la que un usuario se da de baja es escasa en proporción al número de altas.
Actualización de correo electrónico:a efectos prácticos lo que distingue un con- tacto de otro en el IEM es el e-mail. Es así que al actualizar el e-mail existente de un usuario en Habitissimo, y tratándose de un suscriptor, es necesario actualizar el e-mail del contacto correspondiente. Si no se llevase a cabo mantendríamos como válido a un suscriptor obsoleto, al cual no se deberían enviar campañas, a la vez que se perdería un contacto legítimo.
A nivel de complejidad resulta muy similar al proceso de tramitar la baja, con unas pocas peticiones que no varían y una frecuencia menor todavía, por lo que del mismo modo se aplica el método síncrono para realizar la actualización del e-mail.
2.3.2 Núcleo del sistema: servicios y cliente
Los servicios y el cliente conforman el núcleo del sistema de sincronización ya que es donde se llevan a cabo todas las operaciones posibles que permiten mantener las listas del IEM y encierran la lógica de funcionamiento.
Figura 2.9: Núcleo del sistema
A la hora de esbozar una primera aproximación vemos que el primer obstáculo que nos encontramos es la ambigüedad de conceptos. En términos genéricos lo que se pretende es tener la información que representa a una persona en dos plataformas distintas al mismo tiempo. Sin embargo cuando nos situamos en el contexto de Habi- tissimo se usan términos como “usuario”, “acciones” o “eventos”, mientras que en argot deMarketingy del IEM en particular se hace referencia a “contactos” o“custom fields”
entre otros.
En este punto nos damos cuenta de que para facilitar el desarrollo y mantenimiento del sistema en un futuro hay que trasladar estos conceptos a la implementación en forma de componentes aislados e independientes. Es así como se obtiene un sistema como el de la figura 2.9.
Antes de desarrollarlo se plantea como un sistema de caja negra, el cuál se compone de dos cajas negras interconectadas, en el que la salida de uno es la entrada del otro, siendo éstas la caja de los servicios y la del cliente respectivamente.
El primer componente hace la función de interfaz entre la web de Habitissimo y el cliente del IEM. Recibe como parámetro de entrada la referencia delHabUser, modelo que representa el registro en BD del usuario, y lo procesa. El procesamiento puede implicar recuperar información relativa al usuario y/o modificarla de algún modo pero en cualquier caso siempre se limitará al ámbito de la aplicación, sin interactuar direc- tamente con el IEM. En su lugar prepara los datos que necesita recibir el cliente para poder realizar esa interacción.
El cliente por otra parte necesita recibir al menos dos parámetros de entrada que identifiquen al contacto —recordemos que un “contacto” es el homólogo al “usuario”
de Habitissimo— que en este caso se tratan del e-mail y el identificador de la lista a la que pertenece.
Al diseñar el sistema usando esta forma de abstracción y encapsulamiento garanti- zamos que solo se habilitan las funcionalidades necesarias y se restringe el acceso a la información estrictamente al ámbito que corresponda.
Servicios
En este apartado se describe el componente de los servicios que al principio planteába- mos como caja negra. En realidad no es así, sino que se trata de un módulo desarrollado íntegramente para el proyecto. Como tal describiremos su estructura y funcionamiento adoptando el enfoque de caja blanca.
Los servicios son herramientas que operan con usuarios de Habitissimo y el cliente para sincronizar las listas del IEM según corresponda. Actualmente solo se sincronizan dos listas, particulares y profesionales, que se encuentran replicadas en cada país.
Los servicios se basan en el tipo de operación —suscribir, des-suscribir y actualizar e-mail— y en el tipo de usuario —particular o profesional. Hay cuatro servicios básicos mostrados en la figura 2.10 que encierran la lógica de las principales acciones posibles.
Figura 2.10: Estructura de los servicios
• SubscribeBusinessUser(Anexo 2, Listado 11): servicio que suscribe un usuario profesional a la lista de profesionales del IEM junto con la información relativa a los CF de profesionales disponible para el usuario. Si el usuario ya existe entonces lo activa si no estaba suscrito y después actualiza sus CF.
• SubscribeCustomerUser(Anexo 2, Listado 12): servicio que suscribe un usuario particular a la lista de particulares del IEM junto con la información relativa a los CF de particulares disponible para el usuario. Si el usuario ya existe entonces lo activa si no estaba suscrito y después actualiza sus CF.
