Los profesionales del marketing de aplicaciones móviles necesitan acceder a datos cada vez más granulares para medir con precisión el ROI de sus aplicaciones, lo que inevitablemente requiere procesar grandes volúmenes de datos sobre la marcha. Esto puede ralentizar drásticamente los tiempos de consulta a las bases de datos, creando cuellos de botella para los profesionales del marketing e impidiéndoles optimizar con la rapidez y frecuencia deseadas. Se trata del dilema del marketing móvil actual: una necesidad cada vez mayor de velocidad en medio de un flujo de datos cada vez mayor.
En Singular, el problema surgió antes de nuestra última solución analítica para marketers, Publisher ROI. Publisher ROI permite a los marketers exponer rápidamente un desglose del inventario de ad network’s por publicador y determinar los sitios y apps individuales que impulsan el mejor rendimiento.
Las pruebas iniciales de la función mostraron que las consultas de los clientes a datos a nivel de editor requerían un aumento enorme de potencia de cómputo — de 50-100X los datos que normalmente se ingieren y procesan para consultas en Singular. Al ver que los tiempos de consulta se disparaban durante las pruebas, quedó claro que habíamos alcanzado un hito importante: habíamos superado nuestras tecnologías de base de datos.
Para lanzar nuestra última innovación y continuar ofreciendo a los vendedores de aplicaciones móviles un acceso rápido y flexible a datos de marketing cada vez más granulares, necesitaríamos introducir un nuevo canal de datos y un nuevo almacén de datos, uno que fuera capaz de permitir consultas ad hoc en mil millones de filas con un rendimiento inferior a un segundo.
En esta publicación, describiremos cómo reconstruimos ciertos componentes de nuestras tecnologías de bases de datos y aumentamos drásticamente la velocidad de las consultas de nuestros clientes — en algunos casos por un factor de 150X.
Pero antes de profundizar en cómo aceleramos las consultas de nuestros clientes, vale la pena brindar algunos antecedentes sobre las necesidades cambiantes de los especialistas en marketing de aplicaciones móviles y la magnitud de los desafíos de datos que enfrentamos al brindarles una plataforma de análisis tan flexible como Singular.
Desde los inicios de Singular, supervisamos de cerca los tipos de consultas que nuestros clientes realizaban en Singular. Intentamos identificar patrones para crear sistemas que anticiparan las dimensiones que un profesional de marketing podría usar en sus consultas. Sin embargo, pronto descubrimos que existía una gran diversidad en los informes y consultas que realizaban los clientes, con innumerables combinaciones de diferentes dimensiones y métricas.
Piénsalo en términos de filas en una tabla. Supongamos que te anuncias en una red publicitaria que publica tus anuncios en 100 editores diferentes. Podrías consultar el ROI general de la red; con Singular, eso es solo una línea de datos. Para luego exponer un desglose del rendimiento individual de cada editor y así segmentar a los editores de alto rendimiento de los de bajo rendimiento, necesitarías renderizar 100 filas de datos. Ahora, supongamos que estás ejecutando 4 campañas multipaís y quieres ver si ciertos editores tienen un rendimiento particularmente bueno en ciertas áreas geográficas; ahora estás viendo 400 filas. ¿Quieres un desglose de los datos por iOS y Android? Eso son 800 filas.
Este tipo de complejidad nos llevó a nuestra primera conclusión sobre la arquitectura de base de datos que podría satisfacer nuestras necesidades. Dado que el uso de Singular es tan diverso, con innumerables combinaciones de dimensiones de consulta, necesitábamos admitir consultas ad-hoc, es decir, consultas que no se pueden determinar antes de su emisión. Como saben la mayoría de los ingenieros de datos, las bases de datos verdaderamente optimizadas para consultas ad-hoc no suelen actualizar los datos después de su ingesta. Por lo tanto, necesitábamos ingerir los datos en nuestra base de datos en su formato final.
Ingesta de datos en Singular
En Singular, realizamos alrededor de 10 000 de recopilación de datos de marketing al día. Cada tarea recopila datos de un cliente específico de uno de nuestros proveedores de marketing externos en un periodo de entre 1 y 30 días. Nuestro flujo de ingestión se distingue por el volumen de datos que recopila cada tarea (las estadísticas granulares de Facebook de 30 días son enormes) y porque recopilamos datos de proveedores que suelen actualizarlos retroactivamente con regularidad, lo que obliga a Singular a sustituir constantemente las estadísticas antiguas por datos actualizados.
Nuestro pipeline de ingesta cargaba previamente los datos en MySQL y ejecutaba diversas lógicas de ingesta mediante consultas y actualizaciones. Una vez disponibles los datos, las consultas activadas por nuestro panel y API también se dirigían a MySQL.
Esto nos había funcionado bien, al menos hasta que introdujimos la recopilación y consulta a nivel de editor. Con el gran aumento del volumen de datos, la carga a MySQL se ralentizó, lo que generó cuellos de botella en nuestro flujo de trabajo. Además, ejecutar consultas analíticas en este volumen de datos era simplemente demasiado lento.
Diseño de una nueva canalización de ingestión
Para soportar un número infinito de tareas, con un tamaño de datos ingeridos en constante crecimiento, buscamos construir una canalización escalable horizontalmente (a diferencia de MySQL). La elección de Amazon Simple Storage Service (S3) para soportar estas dependencias fue obvia. Ya habíamos usado S3 para respaldar nuestros datos antes de insertarlos en MySQL. Además, es escalable horizontalmente, no requiere operaciones y ofrece una alta velocidad de descarga y carga al trabajar con Amazon Web Services.
Por lo tanto, nuestra nueva arquitectura de ingesta se basa en S3 y solo los metadatos se almacenan en MySQL. En lugar de consultar y actualizar MySQL, cada componente de nuestra canalización recibe un archivo S3 como entrada y envía otro archivo S3 que contiene los datos recibidos junto con la nueva información generada por el componente.
El final de nuestro pipeline envía los datos a un bucket de S3 que contiene las estadísticas más actualizadas por cliente, fuente de marketing y fecha. Esto permite ejecutar tareas de recopilación de datos en paralelo y convierte a este bucket en la fuente de información de nuestro sistema.
Hacia un nuevo almacén de datos
Con nuestros datos en su formato final, listos para ser consultados en S3, nuestra elección de almacén de datos fue sumamente flexible. Previamente, habíamos creado una pequeña capa de abstracción entre nuestra API y MySQL, adaptable para cualquier lenguaje de consulta o esquema. Por lo tanto, al evaluar nuevas bases de datos, sabíamos de antemano que la decisión no era definitiva, ya que los costos de cambio eran muy bajos. Finalmente, elegimos Druid, un almacén de datos de código abierto desarrollado para la necesidad específica de consultas agregadas sobre datos de análisis de marketing.
Una vez implementado, quedamos encantados con los resultados: con Druid, las consultas que antes duraban 60 segundos tardaban entre 1 y 2 segundos, mientras que las que antes tomaban 30 segundos tardaban menos de un segundo. En algunos casos, vimos mejoras en los tiempos de consulta de la base de datos de hasta 150 veces en comparación con el sistema anterior.
Todos estos avances nos llevan a principios de este año, cuando comenzamos a implementar el ROI a nivel de editor para clientes selectos en una prueba beta cerrada de la función. Esta beta serviría como la prueba de resistencia definitiva para nuestra nueva arquitectura.
Granularidad y velocidad para ganar
Para repasar el ROI a nivel de editor y su impacto innovador, presentamos algunos antecedentes del sector. Las redes publicitarias suelen adquirir inventario compuesto por espacios publicitarios en cientos, a veces miles, de sitios y aplicaciones. Estos sitios y aplicaciones, conocidos individualmente como "editores", son donde se publican los anuncios de los profesionales del marketing.
En los últimos años, los profesionales del marketing de aplicaciones móviles han exigido mayor visibilidad del rendimiento a nivel de editor para identificar segmentos de su tráfico más valioso. Las redes han respondido proporcionando identificadores de editor en los datos de rendimiento que exponen a los profesionales del marketing. Estos, a su vez, utilizan estos identificadores de editor o sitio para optimizar, aumentando la inversión en editores de alto rendimiento y disminuyendo la inversión o eliminando a los de bajo rendimiento.
Históricamente, sin embargo, la optimización de editores en múltiples redes ha sido un proceso arduo y propenso a errores, que obliga a los profesionales del marketing a alternar entre múltiples paneles y actualizar manualmente archivos de Excel complejos. El proceso es especialmente complejo para los profesionales del marketing que desean analizar el rendimiento de los editores no solo por las tasas de clics o el número de instalaciones, sino por la calidad real de esos usuarios, medida a través del ROI.
Singular automatiza el proceso de recopilación de todos sus datos de marketing bajo un mismo techo, antes de limpiar y combinar los datos con los ingresos y eventos recuperados de los enlaces de seguimiento para exponer el ROI de la aplicación y otras métricas comerciales de embudo completo.
Pero, como hemos demostrado aquí, una vez ingeridos, enriquecidos y combinados, agilizar y flexibilizar los datos a nivel de editor es una tarea completamente distinta. Precisamente por eso invertimos tanto en nuestro nuevo pipeline y almacén de datos. Los profesionales del marketing de aplicaciones móviles necesitan granularidad y velocidad, y nos enorgullece decir que los resultados hablan por sí solos.
A medida que implementamos el ROI a nivel de editor para nuestros clientes de prueba beta que ahora utilizan nuestro nuevo sistema basado en Druid, los clientes informaron tiempos de carga increíblemente rápidos, incluso con el aumento masivo en el volumen de datos.
Y las mejoras de rendimiento no están limitadas a la consulta a nivel de editor. Con Singular, consultas intensivas en datos — para exponer Campaña, País, Creativo y Nivel de Usuario rendimiento — ahora es más rápido que nunca gracias a estos avances en nuestras nuevas tecnologías de bases de datos.