Arquitectura de seguimiento de píxeles sin servidores

En esta solución, se presenta una arquitectura de seguimiento de píxeles sin servidores para publicidad.

Como anunciante o agencia de publicidad, un objetivo principal es lograr que tu marca o la de tu cliente tenga visibilidad. Una forma de hacerlo es mediante la publicidad en línea. Si haces un buen trabajo, los anuncios se publican en espacios publicitarios en la propiedad de un publicador. Pero las tareas no terminan allí.

Una parte clave de una arquitectura publicitaria es recopilar datos para aprovechar al máximo el presupuesto y comprender cómo responde el público. Una forma común de hacerlo es mediante el seguimiento de píxeles. Sin embargo, configurar esos servidores de seguimiento de píxeles a menudo requiere una sobrecarga técnica, como tener que lidiar con los costos, la latencia, el escalamiento y la alta disponibilidad, por mencionar algunos. En esta solución, aprenderás a compilar una plataforma de este tipo y, a su vez, a mitigar la inversión técnica.

La seguridad siempre es importante cuando se trabaja con datos publicitarios. Google Cloud ayuda a mantener los datos más seguros y privados de varias maneras. Por ejemplo, todos los datos se encriptan durante la transmisión y cuando están en reposo, y Google Cloud cumple con las normas ISO 27001 y SOC3, FINRA y PCI.

Para obtener más información sobre cómo implementar esta solución, puedes seguir el instructivo.

Conceptos

Por lo general, el proceso de seguimiento de píxeles sigue estos pasos:

  1. Se agrega una parte del código al material creativo o la página web para llamar a una URL que apunta al backend de la red de publicidad. Por ejemplo:

    <img src=”AD_SERVER_URL?parameters”>
    
  2. En el backend, los servidores reciben esa solicitud, la procesan y muestran un píxel invisible de 1 x 1. Por lo general, este píxel se crea de manera programática. Mostrar un píxel en lugar de una respuesta HTTP 200 o 304 ayuda a garantizar que el navegador no muestre una imagen faltante.

Como se muestra un solo píxel, los requisitos de red siguen siendo muy pequeños. El píxel de 1 x 1 se puede hacer transparente con facilidad, tiene poco impacto en las redes y permite el registro de todo tipo de datos, por ejemplo:

  • Parámetros personalizados, como el nombre de la página en la que se muestra o el ID de usuario
  • Un entorno basado en el usuario, como el navegador, el SO o si el anuncio se ve en un dispositivo móvil

Requisitos y arquitectura

Aunque el proceso puede parecer bastante simple, requiere la configuración de algunos elementos. En este ejemplo, se hacen las siguientes suposiciones:

  1. Se produce un promedio de 100,000 impresiones por segundo, pero este porcentaje puede variar.
  2. Las impresiones pueden ocurrir en todo el mundo.
  3. Se deben registrar todas las impresiones y, cuando se agregan, esos registros pueden representar terabytes de datos por día.
  4. Todos los registros se pueden analizar a diario.

Estas suposiciones generan algunos requisitos de implementación:

  1. Ser capaz de aumentar o disminuir la escala de forma automática según la demanda
  2. Tener una latencia de milisegundos a nivel mundial entregada por un dominio
  3. Tener un almacenamiento escalable para registros con escrituras asíncronas
  4. Tener una opción de almacenamiento fácil de consultar

En el siguiente diagrama, se muestra la arquitectura. Ten en cuenta la ausencia de servidores reales para escribir en la plataforma de estadísticas y entregar píxeles.

Arquitectura para la entrega de píxeles sin servidores

Frontends

La primera idea que se considera, y suele implementarse en la industria de la tecnología publicitaria, es usar servidores de frontend como los grupos de instancias de Google Compute Engine o un clúster federado de Google Kubernetes Engine junto con un escalador automático que escriba los registros en un almacén de objetos mediante un agente fluentd. Si bien estas herramientas son bastante comunes, esta opción requerirá que configures instancias, plantillas, grupos, reglas de escalamiento y secuencias de comandos de implementaciones. Esto puede implicar mucho trabajo.

En esta solución, se detalla una alternativa más fácil de implementar, mediante algunos de los productos completamente administrados de Google Cloud:

  • Google Cloud Storage: Un almacén de objetos global o regional que ofrece opciones como Standard, Nearline y Coldline, con varios precios y ANS según tus necesidades. En este caso, usarás Standard, que ofrece una latencia de milisegundos baja.
  • Balanceador de cargas de HTTP(S) de Google: Un servicio global de balanceo de cargas de IP anycast que puede escalar a millones de QPS y se integra a Cloud Logging. Google Cloud CDN también puede aprovecharlo para evitar el acceso innecesario a Cloud Storage mediante el almacenamiento en caché del píxel más cercano al usuario en las cachés perimetrales de Google.

En la siguiente imagen, se muestra una configuración del balanceador de cargas de HTTP(S) de Google Cloud en Cloud Console:

La interfaz de usuario muestra la configuración del balanceador de cargas de HTTP.

Recopilación de registros

La integración del balanceador de cargas de Cloud con Cloud Logging facilita el registro de todas las solicitudes al balanceador de cargas con una configuración mínima. Los registros se guardan directamente en los backends de Cloud Platform y, desde allí, se pueden exportar a Cloud Storage, Google Cloud Pub/Sub o Google BigQuery. Con este enfoque, puedes hacer lo siguiente:

  • Supervisar el comportamiento del sistema mediante Cloud Monitoring y crear métricas y alertas personalizadas
  • Exportar los registros a varios productos, según tus necesidades:

    • Copia de seguridad: Exportar a Cloud Storage o BigQuery
    • Análisis: Exportar a BigQuery
    • Transmisión de procesamiento en tiempo real: Exportar a Cloud Pub/Sub

Un registro en Cloud Logging debería ser similar a la siguiente imagen, en la que puedes ver algunos resultados:

  • El píxel se entregó desde la CDN: cacheHit: true.
  • Los parámetros de URL que se configuraron en el código HTML son visibles.

El registro de Cloud Logging muestra el acierto y los parámetros de caché.

En esta solución, se exportan registros directamente a BigQuery mediante la API de transmisión. También es posible aprovechar Google Cloud Dataflow. Para obtener más información, consulta Pasos siguientes.

Un registro exportado directamente a BigQuery es similar a la siguiente imagen, en la que las columnas coinciden con las claves de los datos similares a JSON que encuentras en Cloud Logging. En la siguiente imagen, hay una consulta que muestra todos los datos de un registro específico, según el campo insertID creado por Google.

Google BigQuery muestra todos los datos de un registro.

Estadísticas de registros

Después de que se carguen en BigQuery, puedes ejecutar consultas ad hoc en tus datos. Debes tener en cuenta los siguientes aspectos:

  • Usar una tabla de particiones para cada día ofrece algunas ventajas, como reducir la cantidad de bytes que procesaron todas las consultas.
  • Dividir las tablas para cada grupo de anunciantes también puede ayudar a que los datos sean más fáciles de administrar, aunque no sea un requisito. Siempre puedes ejecutar una unión en esas tablas mediante los comodines de tablas.
  • BigQuery también es una excelente herramienta para trabajos básicos de ETL. Cuando le das una tabla de salida a una consulta, puedes procesar los datos según sea necesario y transformarlos en un formato más presentable. Por ejemplo, es posible que desees agregar los datos diarios en una tabla semanal.

En el siguiente código de ejemplo, se muestra un subconjunto de los campos que puedes encontrar en BigQuery para cada impresión de píxeles, en el que tu parámetro es la lista de pares clave-valor personalizados que agregas y podrás extraer.

 {
    [...]
    "resource_type": "http_load_balancer",
    "resource_labels_url_map_name": "lb-pixel-tracking",
    "resource_labels_zone": "global",
    "httpRequest_requestMethod": "GET",
    "httpRequest_requestUrl": "YOUR_DOMAIN/pixel.png?YOUR_PARAMETERS",
    "httpRequest_requestSize": "972",
    "httpRequest_status": "200",
    "httpRequest_responseSize": "1320",
    "httpRequest_userAgent": "Go-http-client/1.1",
    "httpRequest_remoteIp": "1.2.3.4",
    "httpRequest_cacheHit": "true",
    [...]
}

Una vez que los datos se almacenan en BigQuery, puedes comenzar a comprender el comportamiento de los usuarios. Mediante la IU de BigQuery, los analistas con conocimientos de SQL pueden ver los resultados en gigabytes a terabytes de datos en cuestión de segundos.

BigQuery muestra los resultados de las solicitudes de seguimiento de píxeles.

Pruebas de carga

Para asegurarte de que esta solución se pueda usar en producción, puedes configurar un entorno de prueba de carga distribuida, basado en Vegeta. Para obtener más información, consulta el instructivo. Como puedes ver en los resultados a continuación, esta arquitectura puede administrar 100,000 RPS con facilidad.

Gráficos de resultados de pruebas de carga

Próximos pasos

En esta solución, se presentó una arquitectura de alto nivel para la entrega de píxeles sin servidores. Para llevar la arquitectura más lejos, puedes aprovechar otras funciones de Google Cloud Platform, como las siguientes:

  • DNS: Esta solución usó directamente la IP global del balanceador de cargas, pero también puedes conectar el nombre de tu dominio mediante Google Cloud DNS. Un balanceador de cargas puede tener varios backends de distintos tipos, como Cloud Storage o Compute Engine.
  • Métricas personalizadas: Como se mencionó antes, puedes usar Cloud Logging a fin de crear métricas personalizadas que Cloud Monitoring pueda usar para alertas o supervisión.
  • Google Cloud Bigtable: Agregar Cloud Bigtable a la canalización de Cloud Dataflow ayuda a que algunos de los servidores de anuncios accedan a datos actualizados casi en tiempo real. Si bien Cloud Dataflow aún puede cargar datos en BigQuery para estadísticas sin conexión, también podría escribir en Bigtable, que ofrece lecturas de latencia de un solo dígito cuando se usa SSD. Esta puede ser una buena forma de obtener tu perfil de usuario, por ejemplo.
  • Google Data Studio: Si bien BigQuery ofrece una IU para ejecutar consultas de SQL, a veces una imagen vale más que mil palabras. Data Studio puede ayudarte a visualizar tu análisis mediante paneles que se pueden compartir y análisis a través de una fuente de datos.
  • Procesamiento de registros: Esta solución propuso centrarse en el análisis por lotes con una arquitectura que puede evolucionar hacia decisiones en tiempo real. Un buen enfoque para compilar esta arquitectura sería usar los siguientes servicios:
  • Cloud Pub/Sub: Un sistema de mensajería global completamente administrado. Los publicadores pueden publicar una gran cantidad de mensajes en un tema a través de varios clientes. Esos mensajes pueden ser procesados por trabajadores que pueden extraer o recibir los mensajes. Está disponible como opción cuando se exporta desde Cloud Logging.
  • Cloud Dataflow: La evolución de Google de MapReduce que ofrece capacidades de transmisión y por lotes en el mismo SDK, que es de código abierto en Apache Beam. Cloud Dataflow facilita la compilación de canalizaciones con algunas líneas de código y proporciona muchas funciones excelentes en lo que respecta al procesamiento de transmisión, incluidas las marcas de agua, los cronómetros y los sistemas de ventanas. También ofrece varios receptores, como BigQuery (consultas completas ad-hoc) o Bigtable (lecturas y escrituras de baja latencia).

    Esta arquitectura sería similar a la que se muestra en el siguiente diagrama:

    Arquitectura avanzada

Consulta los instructivos