Treb

allF

inal

de

Gra

u

GRADO EN INGENIERÍA INFORMÁTICA

Sistema de automatización para GoogleAdwords

ENRIQUE PIÑA MONSERRAT

TutorBeatriz Gómez Suárez

Escola Politècnica SuperiorUniversitat de les Illes Balears

Palma, Septiembre de 2016

Quiero dedicar este trabajo de final de grado a mis padres por todo el soporteemocional y económico a lo largo de la carrera.

Tengo muy presente que tampoco habría sido posible terminar la carrera sin todo elapoyo de mi mujer Patri. Siento todos los quebraderos de cabeza.

Por último, dar las gracias a todas aquellas personas que día tras día me han dadoánimos para llegar donde estoy.

ÍNDICE GENERAL

Índice general iii

Índice de figuras v

Índice de cuadros vii

Acrónimos ix

Resumen xi

1 Introducción 11.1 Contexto del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.1.1 Habitissimo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.1.2 Google AdWords . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Entorno operacional del sistema . . . . . . . . . . . . . . . . . . . . . . . 31.3 Motivación / Necesidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.4 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Análisis del problema 52.1 Requisitos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.1.1 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.2 API RESTful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.1.3 Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Requisitos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2.1 Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Requisitos tecnológicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.1 Servidores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3.2 Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4 Tecnologías empleadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.4.1 Del lado del servidor . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.2 Del lado del cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.4.3 Comunicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Arquitectura del sistema 113.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2.1 Procesos de importación . . . . . . . . . . . . . . . . . . . . . . . 133.2.2 Bases de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

iii

iv ÍNDICE GENERAL

3.2.3 Sistema de cachés . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.4 Servidores de trabajos . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.5 API RESTful . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.6 Procesos de lógica de negocio . . . . . . . . . . . . . . . . . . . . 173.2.7 Aplicación de escritorio . . . . . . . . . . . . . . . . . . . . . . . . 17

4 Diseño e implementación del sistema 19

5 Gestión del proyecto 27

6 Resultados obtenidos 33

7 Conclusiones 41

Bibliografía 43

ÍNDICE DE FIGURAS

1.1 Estructura básica de Google Adwords. . . . . . . . . . . . . . . . . . . . . . . 2

3.1 Arquitectura general . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2 Conexión entre servidores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Procesos en ejecucuión en cada servidor. . . . . . . . . . . . . . . . . . . . . 13

4.1 Vista UML de las entidades de Google Adwords. . . . . . . . . . . . . . . . . 214.2 Visión global de los procesos importadores. . . . . . . . . . . . . . . . . . . . 244.3 Visión global de los procesos automátizadores. . . . . . . . . . . . . . . . . . 25

5.1 Diagrama Gantt 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295.2 Diagrama Gantt 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.3 Diagrama Gantt 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

6.1 Adwortissimo: Vista de agregación diaria por cada cuenta. . . . . . . . . . . 356.2 Adwortissimo: Vista agregada de todas las campañas de las cuentas selec-

cionadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.3 Keyword Suggest: Herramienta para encontrar nuevos trabajos y palabras

clave. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.4 AdGroup Creator: Creador de grupos de anuncios en las campañas seleccio-

nadas a través de trabajos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386.5 Campaign Creator: Sistema para crear campañas dado una provincia y

subcategoría. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

v

ÍNDICE DE CUADROS

vii

ACRÓNIMOS

PPC Pay Per Click

CPC Cost Per Click

QS Quality Score

ROI Return Of Investment

CPA Cost Per Adquisition

API Application Programming Interface

HTTP HyperText Transfer Protocol

JSON JavaScript Object Notation

XML eXtensible Markup Language

UTF Unicode Transformation Format

GB GigaBytes

MB MegaBytes

RAM Random Access Memory

WSGI Web Server Gateway Interface

SOAP Simple Object Access Protocol

URL Uniform Resource Locator

UX User eXperience

BDD Behavior-Driven Development

ix

RESUMEN

Gran parte de los clientes que se captan en Habitissimo es a través de los anunciosde pago de Google, por lo que es muy importante que estos anuncios sean lo másrelevantes posibles para el cliente y que además se pague lo menos posible.

La plataforma de anuncios de Google se llama Adwords y su arquitectura estábasada en campañas. Cada campaña está compuesta por un conjunto de grupos deanuncios y estos a su vez contienen anuncios y palabras clave.

En Google Adwords un técnico puede realizar diferentes acciones para asegurarun beneficio máximo, tales como crear nuevas campañas de marketing, modificar supresupuesto asociado, crear nuevos grupos de anuncios, modificar el coste máximopor click de cada uno de los grupos de anuncios y muchas otras tareas.

En el pasado todos los procesos del flujo de trabajo del departamento de marketingse realizaban de manera manual, por lo que el crecimiento de la empresa se veía limita-do por la capacidad del técnico en gestionar las múltiples cuentas.

El flujo de trabajo de un técnico en marketing de Habitissimo a lo largo de unajornada laboral consiste en detectar nuevas oportunidades y crear las campañas, mo-dificar el presupuesto o el coste máximo por click en aquellas campañas y grupos deanuncios que sea necesarios.

Actualmente, se han automatizado todos estos procesos y solo se requiere la actua-ción de un técnico para supervisar, controlar y monitorizar que las acciones, a granescala, son coherentes. Además, los técnicos también son los encargados de diseñar losnuevos procesos que deberán ser automatizados.

En un futuro cercano se pretende aplicar redes neuronales para el control total delas cuentas de Adwords.

xi

CA

PÍ

TU

LO

1INTRODUCCIÓN

1.1 Contexto del proyecto

1.1.1 Habitissimo

Habitissimo es una plataforma que conecta a personas con necesidad de algún serviciode hogar (reformas, construcción, mudanzas, limpieza, . . . ) con empresas y profesiona-les del sector.

Cada profesional registrado en Habitissimo debe pagar una cuota trimestral paratener el derecho de recibir posibles presupuestos de particulares que se encuentrendentro de su rango de acción.

Si el profesional está interesado en realizar ese presupuesto publicado por el particu-lar, deberá pagar un suplemento para poder ver sus datos de contacto. Este suplementovaría dependiendo de la categoría del servicio, la provincia y el tiempo que lleva publi-cado ese presupuesto dentro de la plataforma.

Cuando un profesional compra los datos de contacto de un particular, tiene hasta10 días para reclamar que el contacto comprado no era válido o no responde al teléfono.

Los particulares son aquellas personas con necesidad de algún servicio de hogary que publican esa necesidad dentro de Habitissimo completamente gratis. Esa ne-cesidad se convierte en un presupuesto que se vende hasta a un máximo de cuatroprofesionales.

1.1.2 Google AdWords

Google Adwords emplea el concepto de Pay Per Click (PPC) como modelo de negociode su plataforma de publicidad patrocinada tal y como se muestra en la figura 1.1

1

1. INTRODUCCIÓN

Figura 1.1: Estructura básica de Google Adwords.

Con el modelo PPC los anunciantes pagan a Google por cada clic que un usuariorealiza sobre alguno de sus anuncios.

El precio de cada clic es variable, y se establece mediante un sistema de subasta.Por tanto, el precio final del clic dependerá de la oferta y demanda, además de otrosfactores que determinan la calidad y la relevancia del anuncio.

El sistema por el cual Google posiciona en mejor o peor lugar un anuncio se basa enel ranking que tiene dicho anuncio. El ranking es la multiplicación del precio máximoque estás dispuesto a pagar y el nivel de calidad del anuncio.

La posición o ranking que adquiere un anuncio en los resultados de Google se basaen tres factores fundamentales:

• La puja establecida (Cost Per Click (CPC) máximo).

• El nivel de calidad de la palabra clave y anuncio (Quality Score (QS)).

• El impacto previsto de las extensiones y otros formatos de anuncios.

Posición = CPC máximo ∗ QS

El impacto previsto de las extensiones solo se tendrá en cuenta en caso de empatey Google no define en qué manera influye.

2

1.2. Entorno operacional del sistema

1.2 Entorno operacional del sistema

En el pasado, para conocer datos como el Return Of Investment (ROI) o la cantidad depresupuestos devueltos asociados a campaña los técnicos en marketing debían accedera un panel de administración local y enlazarlos con los datos históricos de GoogleAdwords. Esta tarea era necesaria para conocer si una campaña estaba resultandorentable o no.

Existía un proceso escrito en PHP que se encargaba de contabilizar todos los pre-supuestos, cuantas empresas se había apuntado a ese presupuesto y el coste de esepresupuesto que proviniese de alguna campaña de Google Adwords.

Toda esta información se almacenaba en una base de datos MySQL con la intenciónde mostrarla en un frontal web y que los técnicos de marketing pudiesen consultarfácilmente.Los datos podían ser agrupados por períodos de tiempo dados por un técnico de mar-keting. Agrupar los datos por período servía para poder comparar diferentes períodosy valorar si se está experimentando un incremento de beneficio, o al contrario, unapérdida.

El proceso de gestionar las campañas de esta manera consistía en tener dos venta-nas de un navegador web, una con Google Adwords y la otra con el frontal web, y en unmismo período de tiempo, comparar campaña a campaña la información de Adwordscontra la de Habitissimo.

Este proceso resultaba eficaz, pero poco eficiente.

1.3 Motivación / Necesidad

Un técnico en marketing es responsable de una gran multitud de tareas: Gestionarcampañas de marketing, realizar marketing de afiliados, seguimiento de usuarios, etc.

Gestionar campañas de marketing consiste en asegurarse que dichas campañasson rentables y que tienen buenas métricas.

Para alcanzar ese objetivo se deben realizar una serie de acciones:

• Crear campañas nuevas donde se encuentren oportunidades.

• Crear nuevos grupos de anuncios para abarcar nuevas subcategorías.

• Insertar nuevas palabras clave a través de los términos de búsqueda para incre-mentar el volumen de impresiones y clicks.

• Modificar el CPC máximo a los grupos de anuncio con el fin de maximizar el CostPer Adquisition (CPA) de ese grupo.

• Modificar el CPC máximo a las palabras clave si es necesario.

3

1. INTRODUCCIÓN

Actualmente, se tienen activas 12 cuentas de Google Adwords, con una media de900 campañas, 125.000 grupos de anuncios y 1.500.000 palabras clave por cuenta.

El tiempo medio que un técnico cualificado debe invertir en revisar una campañaes de 8 minutos, por lo que revisar una cuenta entera conlleva una inversión de 120horas.

Del mismo modo, debe dedicarle 30 minutos diarios a encontrar nuevas oportuni-dades, y el tiempo medio de creación de una campaña es de 45 minutos, por lo que demedia, un técnico debe dedicarle 1 hora y media a buscar oportunidades.

En resumen, para gestionar, supervisar y controlar una cuenta entera conlleva unainversión media de 122 horas. Por lo que se necesitarían 16 técnicos para gestionar unacuenta en una jornada laboral completa.

Como se necesitan gestionar las 12 cuentas, entonces se necesitaría una media de192 técnicos para realizar todo el trabajo.

Si un técnico en marketing le resulta a la empresa un coste fijo de 1800 € mensuales,entonces el equipo de marketing le costaría 345.600 € mensuales.

Teniendo en cuenta que la inversión media mensual en Google Adwords es de240.000 € y que no es viable mantener a 192 empleados gestionando la inversión enAdwords, es normal que se busquen fórmulas para automatizar todos estos procesos.

1.4 Objetivos

Los objetivos a cumplir son:

• Reducir o eliminar el tiempo que un técnico debe emplear para revisar unacampaña.

• Reducir o eliminar el tiempo que un técnico tarda en crear una campaña.

• Facilitar la tarea de encontrar nuevas oportunidades.

• Facilitar la búsqueda e inserción de nuevas palabras clave para aumentar volu-men.

• Solucionar posibles errores introducidos por error humano.

• Diseñar una aplicación intuitiva para que el técnico pueda realizar todas lasoperaciones.

4

CA

PÍ

TU

LO

2ANÁLISIS DEL PROBLEMA

Visto el problema, se requiere encontrar una solución para disminuir considerablemen-te el tiempo que invierten los técnicos de marketing en gestionar todas las campañasde Google Adwords.

Para ello, va a ser fundamental tener toda la información de campañas, grupos deanuncios, palabras clave y anuncios que se tiene en las cuentas de marketing parapoder cruzar esta información con los datos de negocio de Habitissimo.

La creación de nuevas campañas es un proceso tedioso pero fácilmente automatiza-ble, por lo que se deberá diseñar un sistema que dado una subcategoría, una provinciay una cuenta destino sea capaz de generar toda la estructura de la campaña y publicarlaen Google Adwords. Se deberá tener en cuenta que los técnicos deberán poder revisardicha estructura antes de publicarla.

Otro procedimiento que conlleva tiempo es la revisión manual de las campañas.Para intentar paliar la inversión de tiempo en este proceso, se deberá diseñar un sistemainteligente el cual sea capaz de decidir qué nuevo presupuesto, puja, modificador depuja móvil o modificador de puja horária es la más conveniente a cada una de lascampañas y grupos de anuncios. Todas las propuestas sugeridas por este sistema inte-ligente deberán ser luego revisadas por los técnicos y seleccionar aquellas que creanconvenientes y descartando aquellas que consideren erróneas, retroalimentando deesta manera al sistema inteligente con nueva información.

El último proceso al cual los técnicos dedican bastante tiempo es al de buscar nue-vas oportunidades o detectar aquellas campañas que han dejado de ser oportunidades.Por eso, se deberá diseñar un sistema inteligente que sea capaz de detectar aquellasoportunidades y aquellas campañas que han dejado de serlo y pueda mostrar al técnicocorrespondiente dicha situación.

5

2. ANÁLISIS DEL PROBLEMA

Toda la información que generan todos estos procesos automáticos debe ser revisa-do y aceptado por los técnicos. De esta manera, se propone el diseño de una interfazde usuario donde los técnicos puedan en todo momento conocer el estado de estosprocesos y revisar los cambios propuestos por estos mismos.

2.1 Requisitos no funcionales

2.1.1 Core

• Todos los procesos de importación de Google Adwords deben realizarse unmínimo de tres veces diarias con el fin de garantizar la redundancia.

• Los procesos deben poder configurarse para que se ejecuten a una hora específi-ca.

• Los procesos se deben poder configurar por país.

• Todos los procesos se deben poder ejecutar de manera manual.

• Se debe poder elegir en qué servidor se ejecutará cada proceso.

2.1.2 API RESTful

• La Application Programming Interface (API) debe cumplir la arquitectura REST-ful.

• Toda petición debe ser atendida en menos de 1 minuto.

• Siempre se debe obtener una respuesta por parte del servidor con la informaciónadecuada. En caso de error, debe responder con la información necesaria paratratarlo.

• Los códigos HyperText Transfer Protocol (HTTP) devueltos por la API deben serrepresentativos.

• Todas las llamadas deben estar convenientemente documentadas.

• Todas las llamadas devolverán la información en JavaScript Object Notation(JSON).

• La codificación de los caracteres debe ser Unicode Transformation Format (UTF)-8.

2.1.3 Aplicación

• La aplicación debe ser multiplataforma.

• La aplicación será compatible solamente con arquitectura de 64 bits.

• No podrá consumir más de 2 GigaBytes (GB) de Random Access Memory (RAM).

• Se debe poder especificar el correo del usuario.

6

2.2. Requisitos funcionales

• La aplicación debe quedar en un estado consistente después de cada llamada ala API.

• La aplicación no debe quedarse bloqueada por una petición.

2.2 Requisitos funcionales

2.2.1 Aplicación

• Un usuario debe poder ver qué importaciones están activas en ese momento yactivar aquellas que no estén en funcionamiento en ese momento.

• Todas las funcionalidades deben tener la posibilidad de realizar filtros sobre lainformación recibida.

• En caso de fallo por falta de información diaria causada por un mal funcionamien-to en alguna importación, el usuario no debe poder ejecutar la funcionalidad queinvolucra esa información.

2.3 Requisitos tecnológicos

2.3.1 Servidores

• Sistema Operativo Linux de 64 bits.

• Intérprete Python 2.7.

• Servidor de colas Beanstalk o RabbitMQ.

• Sistemas gestores de bases de datos PostgreSQL y MongoDB.

• Sistema de caché REDIS.

• Servidor Web Server Gateway Interface (WSGI) HTTP Gunicorn o uWSGI.

• Servidor HTTP nginx o lighttp.

• Servidor de correo Postfix.

2.3.2 Aplicación

• Sistema Operativo Microsoft Windows, MacOS X o Linux de 64 bits.

• RAM 2 GB.

• Disco duro 256 MegaBytes (MB) libres.

2.4 Tecnologías empleadas

Todas las herramientas y tecnologías se han escogido cautelosamente, ya que pue-den suponer el fracaso del proyecto o aumentar su complejidad. Además, todas lastecnologías empleadas son libres.

7

2. ANÁLISIS DEL PROBLEMA

2.4.1 Del lado del servidor

En lenguaje de programación principal es Python debido a que se trata de un lenguajede alto nivel, con un buen rendimiento y la facilidad de desarrollar en él. Además,genera un código fácil de leer y su biblioteca estándar es muy completa.

Colas de trabajo

Como colas de trabajo se pueden emplear Beanstalk o RabbitMQ como brokers. Estosse deben configurar en el archivo de configuración .env del proyecto.

Como clientes para estos brokers se emplean: beanstalkc o pika correspondiente-mente.

Se hace uso de colas para poder distribuir los diferentes procesos de importación ode trabajo entre múltiples servidores.

Sistemas gestores de bases de datos

Como base de datos principal se ha elegido PostgreSQL ya que es una base de datosrobusta y muy fiable. Además, se comporta realmente bien cuando se almacena muchacantidad de datos.

Como se tenía la necesidad de realizar agregados sobre los datos almacenados a unagran velocidad se decidió añadir una base de datos NoSQL segundaría que replicaríalos datos susceptibles a ser agregados.Se decantó por MongoDB como base de datos no relacional.

Sistema de caché

A la hora de realizar importaciones se encontró con un problema de rendimiento y sedecidió insertar un sistema de caché basado en REDIS.

API RESTful

Para la construcción de la API se ha empleado el framework Flask con el módulo flask-restful.

Para servir la API como WSGI HTTP se ha empleado uWSGI y como servidor HTTPse ha elegido nginx.

2.4.2 Del lado del cliente

El cliente ha sido desarrollado completamente empleando el lenguaje de programaciónPython y usando Qt 4.7 como framework en el diseño de la interfaz de usuario. Parainteractuar con Qt a través de python se ha empleado la librería PySide.

8

2.4. Tecnologías empleadas

2.4.3 Comunicación

En la comunicación se hace uso de JSON, un formato ligero para el intercambio dedatos, frente a su principal alternativa eXtensible Markup Language (XML).

La elección de JSON se debe a que resulta muy simple tanto para humanos comopara máquinas, a que está orientado a las estructuras de datos de los lenguajes deprogramación modernos y a que no se necesita validación mediante esquemas de lasrespuestas.

9

CA

PÍ

TU

LO

3ARQUITECTURA DEL SISTEMA

La arquitectura general del sistema queda reflejada en la figura 3.1, donde se puedever como los procesos importadores son los encargados de recoger la información deGoogle AdWords, mientras que los procesos actuadores, activados a petición de la API,son los encargados de realizar los cambios pertinentes a Google AdWords.

Figura 3.1: Arquitectura general

3.1 Hardware

La arquitectura hardware en la que se apoya toda la aplicación consta de dos servidorescasi idénticos. Uranus cuenta con un disco duro de estado sólido de 1 TB en compara-

11

3. ARQUITECTURA DEL SISTEMA

ción con Neptune, que solo dispone de 500 GB de disco duro sólido.

El servidor Neptune está conectado directamente con el servidor Uranus a través decable trenzado para que la latencia de comunicación entre ellos sea la mínima. Uranus,a su vez, es el encargado de proporcionar conexión a Internet a Neptune tal y como semuestra en la figura 3.2

La comunicación directa entre Neptune y Uranus es necesaria para asegurar eltiempo mínimo de consulta e inserción en las bases de datos.

Figura 3.2: Conexión entre servidores.

3.2 Software

Se puede dividir la aplicación en siete grandes paquetes:

• Procesos de importación.

• Bases de datos.

• Sistemas de caché.

• Servidores de trabajo.

• API RESTful.

• Procesos de lógica de negocio.

• Aplicación de escritorio.

12

3.2. Software

Figura 3.3: Procesos en ejecucuión en cada servidor.

3.2.1 Procesos de importación

Los procesos de importación están destinados a descargar la información necesariaproveniente de la base de datos de producción de Habitissimo y Google Adwords.

La necesidad de replicar la información de Habitissimo es la de poder tener unifica-da toda la información en un mismo lugar, además de poderla tener representada de lamanera más conveniente.

La información que se replica de Habitissimo es: las categorías, subcategorías y sub-subcategorías, provincias y poblaciones, presupuestos publicados y devueltos, cantidadde profesionales con packs profesionales comprados y demás información necesaria.

Esta información es necesaria para poder realizar algunos procesos que modificanlos presupuestos de las campañas o las pujas de los grupos de anuncios en función dela cantidad de profesionales que se tengan en esa zona o la cantidad de presupuestosque se están publicando para una determinada subcategoría y provincia.

Por otra parte, la información que se descarga de Google Adwords permite a losprocesos cruzar la información de Habitissimo con los datos de Google Adwords y deesta manera poder realizar cambios más ágilmente.

Existe la posibilidad de no realizar ninguna importación de Google Adwords y cadavez que se requiera algún dato se realice una petición directa a la API de Google paraobtenerlos, pero se deben tener en cuenta dos cosas: Rendimiento y coste.

Una petición a Google Adwords hace uso del protocolo de comunicación SimpleObject Access Protocol (SOAP) que, dada su naturaleza, la hace extremadamente lentocuando se debe transmitir una gran cantidad de datos, y si se necesita un gran rendi-miento, esta latencia no es admisible.

Además, cada petición que se realiza tiene un coste monetario asociado, por lo que

13

3. ARQUITECTURA DEL SISTEMA

cualquier petición que se duplique representa una pérdida en términos económicos.

Teniendo en cuenta los dos factores anteriores, se decidió replicar toda la base dedatos de Google Adwords en la base de datos propia de marketing.

Las importaciones, tanto de Habitissimo como de Google Adwords, no sé ejecu-tan secuencialmente, sino que están segmentadas por tipo y representan procesoscompletamente independientes. De esta manera, es posible que se esté realizandouna importación de palabras clave al mismo tiempo que una importación sobre laestadística diaria de los últimos 15 días en todas las campañas.

Así pues, la importación global de Habitissimo está formada por pequeñas impor-taciones tales como: árbol de categorías, árbol de provincias, presupuestos y profesio-nales.

La importación de Adwords comprende las importaciones de: campañas, gruposde anuncios, palabras clave, anuncios, extensiones de anuncio, estadística por día decampaña, estadística por día de grupos de anuncios y demás estructuras de GoogleAdwords.

Al tener las importaciones tan segmentadas, se tiene la posibilidad de distribuirestas importaciones entre diferentes servidores, tener control sobre qué importaciónestá consumiendo más recursos y poder actuar sobre ella, poder tener un horario deimportación más específico dependiendo del tipo, poder elegir la cantidad de vecesque se debe importar cada tipo y relanzar manualmente cada importación mucho másfácilmente.

Dada la naturaleza del negocio, muchas importaciones se deben realizar variasveces al día para asegurar que los datos disponibles son lo más actualizados posibles.En cuestión de horas puede notarse un incremento de profesionales en una zona y losprocesos de lógica de negocio deben ser capaces de reaccionar rápidamente ante estoscasos.

Además, el hecho de realizar múltiples importaciones, tanto de Habitissimo comode Google Adwords, garantiza que si una importación ha fallado por alguna razón, losdatos volverán a ser fiables en tiempo máximo de cinco horas.

3.2.2 Bases de datos

En el servidor Uranus se disponen de dos gestores de bases de datos distintos: Post-greSQL y MongoDB, cada uno con una funcionalidad específica.

PostgreSQL

El gestor de bases de datos PostgreSQL fue elegido sobre otros posibles gestores por lassiguientes razones:

14

3.2. Software

• Posee una gran escalabilidad. Es capaz de ajustarse al número de CPUs y a lacantidad de memoria que posea el servidor de forma óptima, haciéndole capazde soportar una mayor cantidad de peticiones simultáneas de manera correcta.

• Implementa el uso de rollbacks, subconsultas y transacciones por defecto, ha-ciendo su funcionamiento mucho más eficaz.

• Tiene la capacidad de comprobar la integridad referencias, así como también lade almacenar procedimientos en la propia base de datos.

• Mantiene latencia muy baja incluso con grandes bases de datos.

• Permite la creación de propios tipos de datos.

• Incorpora funciones propias de agregado de datos.

• Soporta el uso de índices, reglas, vistas y vistas materializadas.

Para gestionar los diferentes países, se ha elegido la opción de replicar la estructurade la base de datos por país. De esta manera, se obtienen tantas bases de datos comopaíses estén disponibles en Habitissimo con la misma estructura pero con los datospropios de cada país.

Las bases de datos tienen asociado un proceso que realiza una copia de seguridadde las bases de datos cada semana. Se podría recuperar la información de hace 6 meses.

MongoDB

Existen procesos que deben ser parametrizados por los técnicos de marketing, ya quedebe variar el funcionamiento dependiendo de varios factores que van variando. Parasolventar este inconveniente, se ha optado por realizar las configuraciones de los pro-cesos en MongoDB.

La duración de muchos procesos puede llegar a superar el tiempo razonable paraque un técnico de marketing esté esperando a visualizar los resultados, por lo que se haresuelto que estos procesos se ejecuten por la noche y su resultado se almacene en unacolección de MongoDB para que pueda consultarse rápidamente.

De esta manera, se tiene una base de datos por proceso y por cuenta de GoogleAdwords, que está formada por, al menos, una colección de configuración y las colec-ciones necesarias para almacenar la información devuelta por ese proceso.

Como no se requiere que ningún proceso vaya almacenando el resultado de suejecución diariamente, y la configuración de cada proceso es muy variable a lo largodel tiempo, no se necesita ninguna tarea que realice copias de seguridad de las basesde datos y colecciones de MongoDB.

15

3. ARQUITECTURA DEL SISTEMA

3.2.3 Sistema de cachés

Muchos procesos de importación necesitan consultar si el elemento a importar ya seencuentra en la base de datos para poder actualizarlo o crearlo en el caso de que noexista.

Cuando se requiere importar gran cantidad de datos, la consulta para conocer sidichos elementos están ya en la base de datos puede resultar muy costosa en términosde tiempo. Este problema se da principalmente cuando se requiere importar la es-tructura de Google Adwords: campañas, grupos de anuncios, palabras clave, anuncios,extensiones de sitio y toda su estadística diaria.

Para reducir el tiempo de acceso a esta información el sistema se apoya en unsistema de cachés basado en REDIS. Cada elemento de Google Adwords se encuentraalmacenado en la caché durante un período de doce horas, momento en el cual lacaché se refresca con los datos nuevos de la base de datos de PostgreSQL.

El período de expiración de un elemento dentro de la caché es necesario para ireliminando aquellos elementos que han sido eliminados de Google Adwords y, portanto, ya no se requiere tener en caché.

Para refrescar el sistema de cachés se tienen una serie de procesos que almacenanen la caché un elemento específico de Google Adwords, de esta manera, existe unproceso para almacenar en caché las campañas, otro proceso para almacenar los gruposde anuncios, las palabras clave, los anuncios y los enlaces de sitio.

3.2.4 Servidores de trabajos

Estos servidores son los encargados de recoger trabajos de distintas colas distribuidasde beanstalk y procesarlos.

Estos trabajos pueden ser muy variados, ya que pueden ser desde trabajos pararealizar cambios en Google Adwords, trabajos para guardar documentos en MongoDBo trabajos que provienen de algún proceso y que realizan diversas acciones.

Los servidores de trabajo se ejecutan como demonios en el sistema operativo ycada uno de ellos escucha su propia cola de trabajo.

3.2.5 API RESTful

La aplicación RESTful sirve para conectar la aplicación de escritorio con toda la infor-mación y todos los procesos de los servidores.

La API ha sido programada usando el framework Flask y hace uso de un servidorHHTP WSGI uWSGI.

16

3.2. Software

Desde esta API se puede consultar el estado de todos procesos activos, y ejecutarlos,se puede consultar el estados de todas las campañas y grupos de anuncios y realizarcambios directamente a Google Adwords.

3.2.6 Procesos de lógica de negocio

Estos procesos son los encargados de gestionar toda la lógica detrás del negocio y sedividen en procesos de creación, mantenimiento y corrección.

Los procesos de creación son los encargados de crear nuevas estructuras de GoogleAdwords y crear nuevos trabajos en la base de datos de marketing.

Los procesos de mantenimiento son aquellos que se encargan de mantener lascuentas dentro de los objetivos, conseguir nuevos elementos que puedan ser suscepti-bles a convertirse en nuevos elementos en Adwords y detectar nuevas oportunidadespara el negocio.

Los procesos de corrección son aquellos que tratan de resolver los problemas quese puedan haber generado por culpa de un proceso automático o por causas humanas.

Los procesos son los siguientes:

• Campaign Creator Es un proceso que crea campañas directamente en GoogleAdwords dada una provincia y una subcategoría de Habitissimo. En caso de queya existiera una campaña con esa provincia y subcategoría se mandaría un avisoal usuario.

• AdGroup Creator Este proceso crea grupos de anuncios en campañas existentesdados unos criterios. Además de crear el grupo, crea las palabras clave, listas denegativas y anuncios.

• Autobidding Es un sistema inteligente que cruza datos estadísticos de GoogleAdwords con los datos de Habitissimo y propone cambios de presupuestos,cambios de puja, cambios de modificadores de puja a nivel móvil y programaciónhoraria. Este es un proceso cron que se ejecuta automáticamente cada noche ypersiste su salida en una colección de MongoDB.

• Opportunizer Es un sistema inteligente que busca nuevas oportunidades o cam-pañas que ya no resultan rentables en base al número de clientes activos para lacombinación de subcategoría y provincia. Este es un proceso cron que se ejecutaautomáticamente cada noche y persiste su salida en una colección de MongoDB.

3.2.7 Aplicación de escritorio

La aplicación se basa en la API RESTful para poder realizar todas las acciones, ya quepor sí misma no puede acceder a ningún recurso del sistema.

La aplicación se divide en pestañas, donde cada pestaña representa un proceso oacción que un técnico de marketing puede realizar.

17

3. ARQUITECTURA DEL SISTEMA

Para poder acceder por primera vez a la aplicación un usuario debe introducir sucorreo electrónico, ya que muchos procesos avisan al usuario a través de un correoelectrónico de cualquier problema que se haya detectado en la ejecución de un proceso.

Este correo electrónico introducido por el usuario se guarda en un archivo de confi-guración en la raíz de la carpeta del usuario.

Para poder empaquetar y distribuir la aplicación a través de los diferentes ordena-dores y sistemas operativos, se ha empleado cx Freeze para empaquetar la aplicaciónpara sistemas operativos basados en Linux y py2exe para empaquetarlas en sistemasWindows.

18

CA

PÍ

TU

LO

4DISEÑO E IMPLEMENTACIÓN DEL SISTEMA

En este apartado de expondrán los pasos y decisiones que se han tomado para realizartodos los procedimientos anteriores.

En primer lugar, se decidió como se iba a estructur en la base de datos toda laestructura de Google Adwords. El resultado fue la creación de cinco tablas donde serepresenta la dicha estructura:

La entidad Account representa la información básica de una cuenta:

• uid: Identificador único de cuenta. Es un campo autodefinido UID.

• name: Nombre de la cuenta.

• gid: Identificador único de la cuenta que proporciona Google Adwords.

La entidad Campaign representa toda la información básica de una campaña ycomo se relaciona con Habitissimo:

• uid: Identificador único de campaña. Es un campo autodefinido UID.

• name: Nombre de la campaña.

• status: Estado de la campaña. Una campaña puede tener el estado habilitado,pausado o eliminado. Este estado se representa con un smallint.

• type: Tipo de campaña. Una campaña puede ser de diferentes tipos no excluyen-tes entre ambos: Red de búsqueda, Red de display, Youtube o APP. Este estado sereprensenta con un byte.

• gid: Representa el identificador de campaña proporcionado por Google Adwords.

• account_uid: Es la llave foránea que relaciona una campaña con una cuenta.

19

4. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA

• state_uid: Es la llave foránea que relaciona una campaña con una provincia deHabitissimo.

• scategory_uid: Es la llave foránea que relaciona una campaña con una subcate-goría de Habitissimo.

De igual manera que se ha definido como una campaña se relaciona con unacuenta, se tiene como un grupo de anuncios se relaciona con una campaña a través dela entidad AdGroup:

• uid: Identificador único de grupo de anuncios. Es un campo autodefinido UID.

• name: Nombre del grupo de anuncios.

• status: Estado del grupo de anuncios. Un grupo de anuncios puede tener el esta-do habitilitado, pausado o eliminado. Este estado se representa con un smallint.

• gid: Este campo representa el identificador de Google Adwords para este grupode anuncios.

• campaign_uid: Es la llave foránea que relaciona un grupo de anuncios con unacampaña.

A más bajo nivel dentro de la estructura de Adwords encontramos la entidadKeyword:

• uid: Identificador único de palabra clave. Es un campo autodefinido UID.

• text: El texto de la palabra clave.

• match_type: Una palabra clave puede tener ser de tres tipos diferentes: Amplia,frase o exacta. Este tipo se reprensenta con u smallint.

• status: Estado de la palabra clave. Una palabra clave puede tener el estado habili-tada, pausada o eliminada. Este estado se representa con un smallint.

• is_negative: Es un boolean donde se indica si la palabra clave es negativa opositiva.

• final_url: Representa una Uniform Resource Locator (URL) específica para esapalabra clave.

• gid: Es el identificador de Google Adwords para esta palabra clave.

• adgroup_uid: Es la llave foránea que relaciona una palabra clave con un grupode anuncios.

Al mismo nivel que las palabras clave se encuentra la entidad Ad:

• uid: Identificador único de anuncio. Es un campo autodefinido UID.

• headline: Es el texto que representa la cabecera del anuncio.

• desc1: Es el campo que representa la linea descriptiva uno del anuncio.

20

• desc2: Es el campo que representa la linea descriptiva dos del anuncio.

• display_url: Campo que representa el texto de la URL descriptiva.

• final_url: URL del anuncio.

• status: Estado del anuncio. Un anuncio puede tener el estado habilitado, pausadoo eliminado. Este estado se representa con un smallint.

• adgroup_uid: Es la llave foránea que relaciona un anuncio con su grupo deanuncios.

Figura 4.1: Vista UML de las entidades de Google Adwords.

Tal y como se muestra en el diagrama UML de la figura 4.1 se obtiene toda la estruc-tura básica de Google Adwords representada en la base de datos de marketing.

Además de la estructura base, también es necesaria toda la información diariade cuentas, campañas y grupos de anuncios. Esta información esta dividida en lassiguientes entidades: AccountStats, CampaignStats, AdGroupStats y KeywordStats ycontienen tanto la información diaria de Google Adwords como la de Habitissimo. Lainformación diaria que podemos esperar recoger de Google Adwords son los clicks, lasimpresiones, conversiones, el presupuesto o la puja, la posición media, el cpc medio yel porcentaje de conversión.

Una vez está definido el modelo de datos que se van a necesitar para todos losprocesos inciales, se decidió que el sistema gestor de bases de datos que mejor se amol-daba a las necesidades era PostgreSQL, ya que su rendimiento no se ve afectado por la

21

4. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA

cantidad de información almacenada y además, nos permite crear nuestros propiostipos de datos.

El siguiente paso que se dió en la implementación del sistema fue construir unadministrador regular de procesos en segundo plano de tal manera que se puede esta-blecer, por país, en que día, hora y minuto se debe ejectar una tarea específica. Estesistema se realizó empleando el módulo de Python APScheduler, que lee de un diccio-nario expresiones CRON y las ejecuta en el momento que han sido planificadas.

Al tener el administrador de procesos funcionando, se invirtió el tiempo en la pro-gramación de los procesos importadores que leen la información tanto de Habitissimocomo de Google Adwords a través de respectivas APIs. En este paso, se realizó un proce-so por cada tipo de importación diferente, de este modo, si una importación fallabapor alguna razón, no afectaba al buen funcionamiento las importaciones sucesivas.

En la figura 4.2 se puede observar como las diferentes importaciones van leyendola información de los diferentes sitios y almacenan dicha información en la base dedatos. Los procesos que almacenan toda la estructura de Google Adwords también seencargan de ir refrescando en el sistema de cachés la información que van obteniendosi dicha información difiere de la que tienen almacenada o si no se encuentra.

Los procesos de datos históricos de grupos de anuncios, palabras clave y segmenta-ción por dispositivo, también guardan parte de su información en MongoDB. Esto esdebido a que la cantidad masiva de datos que se almacenan hace imposible para Post-greSQL el poder realizar agregados de más de 14 días, por lo que se emplea MongoDBpara almacenar una ventana temporal de 6 meses de información diaria para poderrealizar de manera más rápida dichos agregados.

Después de contar con todos los datos necesarios, tanto de Adwords como de Habi-tissimo, se procedió al diseño de los procesos automáticos.

Estos procesos automáticos se pueden segmentar dependiendo de la forma enla cual son ejecutados. Existen procesos que se ejecutan de manera periódica y cuyasalida es almacenada en una base de datos en MongoDB y otros que son ejecutados enel momento en el cual un usuario lo requiere.

En la primera categoría entraría el proceso Autobiding y el proceso Opportunizer.Estos procesos se realizan periódicamente por dos razones, este es un proceso quedebe ejecutarse diariamente independientemente de si un técnico desea ejecutarlo ono, ya que parte de su algoritmo realiza cambios en Adwords sin intervención de unhumano y, además, sus tiempos de ejecución son muy elevados, por lo que un técnicono puede esperar a que termine su ejecución para poder trabajar.

En la segunda categoría están aquellos procesos que son ejecutados en el momentoen que un técnico lo requiere. En esta categoría se encuentran los procesos llamadosCampaign Creator y AdGroup Creator. Estos procesos tienen un tiempo de ejecu-ción corto y la aplicación en Google Adwords depende exclusivamente de que sea

22

validada por un técnico.

En la figura 4.3 se puede ver como los procesos ejecutados automaticamente y losprocesos que se ejecutan por petición de un técnico se interrelacionan.

Para que un técnico pueda validar todas estas salidas y aplicarlas directamente enAdwords, se planteó el diseño de una aplicación de escritorio que hiciera uso de APIRESTful. Dicha aplicación cuenta con un sistema de pestañas donde en cada pestañase puede encontrar la información y la manera de aplicar cada salida de los diferentesprocesos.

23

4. DISEÑO E IMPLEMENTACIÓN DEL SISTEMA

Figura 4.2: Visión global de los procesos importadores.24

Figura 4.3: Visión global de los procesos automátizadores.

25

CA

PÍ

TU

LO

5GESTIÓN DEL PROYECTO

Este proyecto ha sido gestionado empleando un modelo iterativo e incremental especi-ficado dentro de las metodologías ágiles.

En un desarrollo iterativo e incremental el proyecto se planifica en diversos bloquestemporales llamados iteraciones. En el caso de este proyecto se ha usado la metodologíaScrum por lo que los bloques temporales han sido de 3 semanas.

Las iteraciones se pueden entender como miniproyectos: en todas las iteraciones serepite un proceso de trabajo similar para proporcinar un resultado sobre un productofinal, de forma que se puedan observar beneficios de manera incremental.

En cada iteración se evoluciona el proyecto a partir de los resultados completos enlas iteraciones anteriores, añadiendo nuevos objetivos o mejorando los que ya han sidocompletados. Un aspecto fundamental en el desarrollo emplean metodología Scrum esla priorización de los objetivos en función del valor que aporta al negocio.

Una de las principales causas por las que se decantó en emplear esta metodologíafue que se pudo gestionar las expectativas del negocio de manera regular y tomar deci-siones en cada iteración. Esto es importante ya que no se conocía lo que se necesitabadesde un inicio, si no que se va descubriendo conforme se van viendo los resultadosdel proyecto y sobretodo porque el negocio necesitaba realizar cambios a corto plazo,ya que era crítico para no perder relevancia dentro de un mercado tan competitivo.

Al principio de cada iteración, se realizaba una reunión donde se priorizaban ydetallaban los requisitos de las nuevas funcionalidades. El equipo técnico traducíaestos requisitos en diagramas de flujo a un nivel más bajo y el equipo de User eXperien-ce (UX) realizaba un mockup de como debía ser la interfaz de usuario. Una vez se teníatoda la documentación necesaria se procedía con la codificación de los requisitos.

27

5. GESTIÓN DEL PROYECTO

Todas las importaciones de la estructura de Google Adwords han surgido de lanecesidad de disponer de estos datos en algún requisito priorizado.

El desarrollo de tests se basó en el proceso de desarrollo Behavior-Driven Deve-lopment (BDD) o desarrollo dirigido por comportamiento. Este proceso intenta llegara un acuerdo entre los intereses del negocio con los intereses del equipo técnico. Eldesarrollo guiado por el comportamiento señala que las pruebas de cualquier uni-dad de software deben ser especificadas en términos del comportamiento deseadode la unidad. El concepto de comportamiento deseado en este caso consiste en losrequerimientos definidos por el negocio.

La documentación del proyecto se realizaba cada vez que se terminaba un proceso.En la documentación se adjuntaba el diagrama de flujo y el mockup de la interfaz deusuario si se requería.

28

Figura 5.1: Diagrama Gantt 1.29

5. GESTIÓN DEL PROYECTO

Figura 5.2: Diagrama Gantt 2.30

Figura 5.3: Diagrama Gantt 3.31

CA

PÍ

TU

LO

6RESULTADOS OBTENIDOS

Durante el desarrollo del proyecto se han podido ir realizando pruebas de rendimientoy los resultados son realmente positivos.

Si se repasan las acciones que un técnico debía realizar a lo largo de su jornadalaboral se aprecia que una tarea principal es la de revisar las cuentas de Adwords pa-ra intentar alcanzar los objetivos propuestos. El tiempo medio que un usuario debíadedicar a una cuenta era de 120 horas. Gracias a la ayuda que proporciona el sistemainteligente Autobidding, se ha conseguido reducir ese tiempo a 2 horas, ya que ahorasolo debe validar las cambios propuestos de presupuesto y puja y pudiendo ver todaslas métricas necesarias desde un mismo lugar. Esto representa una mejora del 6.000%.

Otra tarea importante a realizar era la de buscar oportunidades. Un técnico le de-dicaba a esta tarea una media de una hora y media. Ahora mismo, gracias al procesoOpportunizer, no solo es capaz de detectar nuevas oportunidades sino además dedescubrir aquellas campañas que ya no lo son y pausarlas automáticamente. A esta ta-rea un técnico le dedica máximo 30 minutos haciendo uso de la aplicación de escritorio.

Se puede observar que, en total, se ha mejorado un 4.880% en cuanto a tiempoinvertido respecto a realizar las mismas acciones manualmente.

Esta mejora permite que los técnicos de márketing puedan gestinar y controlar máscuentas o incluso dedicarle tiempo a otros canales de captación como Bing, Facebooko Twitter.

Ahora mismo, las 12 cuentas de Habitissimo son controladas por solamente 4 per-sonas suponiendo un gasto fijo de 7.200 € mensuales respecto a los 345.600 € quesupondría realizar las tareas manualmente. Esto supone mejorar un 4.880% en gastode personal.

33

6. RESULTADOS OBTENIDOS

No solo se ha conseguido mejorar en tiempo y costes economicos, sino que ahoraresulta mucho más eficaz realizar revisiones a las cuentas de Adwords.

Si comparamos el mes de Abril del año 2015 con el mismo mes de este año, obser-vamos que se han creado 143 campañas más, se han pausado 73 campañas más, se hanrealizado 2.344 cambios de presupuesto, puja, modificadores de móvil y modificadoresde puja horaria más, el CPA ha descendido un 38% y, en general, las cuentas han mejo-rado 17% más en volumen y un 21% en ROI.

A continuación, se mostrarán capturas de pantalla de la aplicación desarrollada:

34

Figura 6.1: Adwortissimo: Vista de agregación diaria por cada cuenta.

35

6. RESULTADOS OBTENIDOS

Figura 6.2: Adwortissimo: Vista agregada de todas las campañas de las cuentas seleccio-nadas.

36

Figura 6.3: Keyword Suggest: Herramienta para encontrar nuevos trabajos y palabrasclave.

37

6. RESULTADOS OBTENIDOS

Figura 6.4: AdGroup Creator: Creador de grupos de anuncios en las campañas seleccio-nadas a través de trabajos.

38

Figura 6.5: Campaign Creator: Sistema para crear campañas dado una provincia ysubcategoría.

39

CA

PÍ

TU

LO

7CONCLUSIONES

Como se ha visto en el apartado anterior, el uso de un software de automatización estotalmente imprescindible cuando se habla de controlar un volumen muy grande.

La inversión que supone el desarrollo de plataformas propias o un modelo híbridoentre plataformas propias y soluciones empresariales está totalmente justificado siem-pre y cuando el volumen sea suficientemente grande.

Un punto importante de este tipo de plataformas y sistemas es la experiencia deusuario. La interpretación de los datos no puede, bajo ningún concepto, ser ambigua,ya que puede desencadenar una secuencias de acciones sobre Google Adwords o cual-quier otra plataforma de bidding que no eran las esperadas o las deseadas.

De esta manera, se han podido cumplir todos los objetivos que se habían propuestoy, además, superado las expectativas que se tenían sobre este producto.

A nivel personal este projecto ha sido un reto muy interesante, ya que abarca mu-chas areas de la informática tales como: Aplicaciones de escritorio, APIs RESTful, basesde datos relacionales y no relaciones y sistemas de caché. Además me ha abierto laspuertas al mundo del márketing digital y todas sus implicaciones sobre el impacto tangrande que tiene sobre el futuro de las nuevas startups.

Al empezar el proyecto desde cero, he podido aprender como se debe plantear unaarquitectura y los costes que conllevan cada una de las deciciones que se toman sobredicha arquitectura.

41

BIBLIOGRAFÍA

[1] Google AdWords, Publica tu anuncio en Google hoy mismo. [Online]. Available:https://www.google.es/adwords

[2] Habitissimo, Recibe hasta 4 presupuestos de profesionales de tu zona. [Online].Available: https://http://www.habitissimo.es

[3] PostgreSQL, The world’s most advanced open source database. [Online]. Available:https://www.postgresql.org/

[4] MySQL, The world’s most popular open source database. [Online]. Available:https://www.mysql.com

[5] Redis, Open source, in memory data structure store. [Online]. Available:http://redis.io/

[6] Beanstalk, Beanstalk is a simple, fast work queue. [Online]. Available: http://kr.github.io/beanstalkd/

[7] Qt, Cross-platform software development for embedded desktop. [Online].Available: https://www.qt.io/

[8] Wikipedia. (2015) Web application framework. [Online]. Available: http://en.wikipedia.org/wiki/Web_application_framework

[9] Python. [Online]. Available: https://www.python.org

[10] Flask, web development, one drop at time. [Online]. Available: http://flask.pocoo.org

[11] Flask-SQLAlchemy. [Online]. Available: https://pythonhosted.org/Flask-SQLAlchemy/

[12] SQLAlchemy, The Python SQL Toolkit and Object Relational Mapper. [Online].Available: http://www.sqlalchemy.org

[13] Wikipedia. (2015) JSON. [Online]. Available: http://es.wikipedia.org/wiki/JSON

43