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 dón-decir, dón-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.