Opciones de infraestructura para servidores de anuncios (parte 3)

En este artículo, se describen las funciones y los productos de Google Cloud que puedes usar cuando compiles la plataforma de publicación de anuncios.

Este artículo forma parte de la siguiente serie:

Consulta la descripción general sobre la terminología de tecnología publicitaria que se aplica en toda esta serie.

La publicación de anuncios es el proceso de mostrar un anuncio (generalmente, el más relevante) de uno de varios anunciantes a un cliente en la propiedad de un publicador. La propiedad puede ser un sitio web, una aplicación o un juego.

La complejidad de un servidor de anuncios depende de las características que ofrece. En términos industriales, un servidor de anuncios es una herramienta para publicadores y anunciantes que permite administrar campañas, anuncios y tráfico de anuncios. Un servidor de anuncios no solo los muestra de la forma en que un billboard muestra un anuncio estático en la carretera. Mostrar anuncios es la función principal, pero las plataformas de tecnología publicitaria como Google Ad Manager tienen más funciones y ofrecen más beneficios que solo mostrarles a los clientes un anuncio único.

Este artículo analiza cómo abordar la compilación de una plataforma sólida de publicación de anuncios que incluye las siguientes funciones principales:

  • Administrar campañas, cuentas, informes y facturación
  • Seleccionar el anuncio más relevante
  • Mostrar el anuncio al usuario objetivo
  • Administrar eventos como impresiones, clics o conversiones
  • Publicar operaciones relevantes en almacenes de datos estadísticos

Los servidores de anuncios generalmente procesan decenas de miles de solicitudes de anuncios por segundo y cada respuesta se envía en unos pocos milisegundos. Ser capaz de responder a tantas solicitudes con rapidez significa que la disponibilidad, la escalabilidad y la latencia baja son los requisitos clave para una solución de publicación de anuncios. Y como ninguna solución de servidor puede cumplir con todos estos requisitos, en este artículo se tratan las implicaciones de diseñar un sistema distribuido.

Hay dos tipos diferentes de servidores de anuncios:

  • Orientados a la venta: Estos servidores permiten a los publicadores maximizar sus ingresos por anuncios, ya que administran a los anunciantes directamente desde la IU del servidor de anuncios. Un servidor orientado a la venta suele alojar anuncios, pero también puede alojar referencias de anuncios. Algunos servidores de anuncios también proporcionarán una IU de autoservicio para los compradores.
  • Orientados a la compra: estos servidores permiten a los anunciantes, departamentos de marketing o agencias de anuncios que administren sus actualizaciones de anuncios. En lugar de proporcionar a los publicadores los anuncios reales, estos usuarios de la plataforma proporcionan un fragmento de código que se comunica con el servidor de anuncios orientado a la compra para recuperar el anuncio.

En el siguiente diagrama, se muestra la arquitectura de un sistema de servidor de anuncios posible.

Posible implementación de un sistema de servidor de anuncios

Cloud Load Balancing entrega los puntos de entrada principales de la plataforma del servidor de anuncios:

  • Para solicitar el anuncio
  • Para buscar la creatividad. Los anuncios se obtienen de la caché más cercana de Cloud CDN
  • Para realizar un seguimiento de eventos como impresiones o acciones/clics del usuario (únicos)

Las solicitudes al balanceador de cargas se registran a través del registro y la supervisión del balanceo de cargas de HTTP(S) o el código personalizado que se ejecuta en los recopiladores; luego, se publican en Pub/Sub antes de que las procese Dataflow para las estadísticas y la creación de perfiles de los usuarios.

Los trabajadores que entregan las solicitudes usan lo siguiente:

  • Información acerca del presupuesto
  • Perfiles de usuario (únicos)
  • Detalles de la campaña
  • Contadores
  • Modelos entrenados para hacer selecciones

Algunas de las opciones mencionadas deberán adaptarse a tus requisitos específicos:

  • Es posible que no desees varias bases de datos diferentes para la selección de anuncios y que prefieras bases de datos jerárquicas o relacionales por cuestiones prácticas. En ese caso, puedes usar Cloud Bigtable o Cloud Spanner.
  • Es posible que necesites una latencia de lectura inferior a milisegundos para procesar una solicitud de oferta y poder aceptar una sobrecarga operativa adicional. En ese caso, podrías usar bases de datos regionales en la memoria de terceros con replicación local siempre que sea posible.
  • Se recomienda usar recopiladores de eventos configurados en VM interrumpibles para minimizar los costos. Si no necesitas realizar ningún procesamiento en línea, puedes capturar los eventos mediante Cloud Logging y analizarlos con BigQuery.

Administra campañas

Para administrar las campañas, los anunciantes necesitan un frontend de usuario que consista en un frontend web y una interfaz de usuario (IU), como mínimo. Los anunciantes también deben proporcionar algunas funciones de generación de informes. Para ver las opciones recomendadas, consulta Frontend de usuario (en la parte 1).

La jerarquía compartida de recursos configurada a través de esta IU incluye anunciantes, campañas, presupuestos, creatividades y facturación. Cuando creas esta jerarquía, el sistema registra un conjunto de reglas que forman parte del proceso de decisión de la selección de anuncios. Estos datos se almacenan en el almacén de administración de metadatos (en la parte 1).

La mayoría de los servidores de anuncios manejan miles de millones de solicitudes de anuncios por día. No es recomendable tener esta carga directamente en la base de datos que almacena los metadatos que se aplican a estas reglas de anunciante (a menos que decidas usar Cloud Spanner). En cambio, considera una de las opciones que se incluyen en los patrones de almacenamiento con alto nivel de lectura (en la parte 1).

Selecciona el anuncio más relevante

Recibir y analizar las solicitudes de anuncios

Las solicitudes se envían a través de una etiqueta que se coloca en la propiedad del publicador. Las etiquetas de anuncios se ven de la siguiente manera:

<script src="[URL_TO_YOUR_AD_SERVER]?key=value"></script>

Cuando se carga la etiqueta, se activa una solicitud de anuncio al servidor de anuncios. La solicitud contiene información como los encabezados HTTP, el usuario-agente, el contexto de página, la dirección IP, la información de orientación, quizá un identificador de usuario y, también, detalles del anuncio, incluido su tamaño.

El servidor de anuncios debe proporcionar un extremo HTTP de [URL_TO_YOUR_AD_SERVER] para recibir y procesar estas solicitudes. Las opciones recomendadas se detallan en Maneja solicitudes (en la parte 1).

Genera el perfil del usuario

Los diferentes servidores de anuncios tienen sus propias formas de seleccionar anuncios. Esta lógica queda fuera del alcance de este artículo. Sin embargo, entender al usuario es clave para mostrar anuncios relevantes. Esta solución supone que una taxonomía de usuario avanzada es un requisito.

Es probable que un servidor de anuncios que trabaje con muchos publicadores reconozca al mismo usuario en diferentes propiedades. El identificador de usuario (único) podría ser una cookie web o un ID de dispositivo móvil que el usuario puede reemplazar.

El servidor de anuncios puede enriquecer la información proporcionada por la solicitud de anuncios (IP, información de la página) con este identificador de usuario para buscar un almacén de datos. El servidor de anuncios debe poder buscar un ID de usuario a través de millones de filas en, posiblemente, terabytes de datos. El servidor de anuncios debe mostrar una respuesta en milisegundos y minimizar la sobrecarga de administración.

En Almacén de perfil de usuario (único) (en la parte 1), se brinda una descripción general. Si bien puedes usar cualquiera de las opciones mencionadas en ese artículo, te recomendamos usar Cloud Bigtable para la publicación de anuncios debido a las siguientes razones:

  • Es una base de datos NoSQL de columna ancha que puede almacenar petabytes de datos.
  • Recupera filas en milisegundos de un solo dígito.
  • Admite la replicación regional.
  • Está totalmente administrado.

Selecciona campañas y anuncios

El proceso de selección de anuncios se realiza en pocos pasos, como se describe en Selección de anuncios (en la parte 1):

  1. Genera el perfil del usuario mediante el almacén de perfil de usuario (único) (en la parte 1).
  2. Selecciona las campañas y los anuncios coincidentes mediante el uso de una copia de los datos del almacén de administración de metadatos (en la parte 1). Las copias se realizan mediante uno de los patrones de almacenamiento con alto nivel de lectura (en la parte 1).
  3. Filtra las campañas y los anuncios relevantes mediante los almacenes de contexto (en la parte 1).
  4. Elige un anuncio.

Una vez que el servidor de anuncios selecciona las campañas y los anuncios que coinciden con los segmentos de usuarios, los valida en función de los valores de datos del almacén de contexto. Por ejemplo, limitación de frecuencia, listas negras o presupuesto agotado. El servidor de anuncios selecciona el mejor anuncio de las campañas y anuncios restantes. La lógica de esa selección final depende totalmente de ti. Por ejemplo, puedes ponderar campañas seleccionando la que tenga el CPM más alto o la que tenga el mayor presupuesto restante. También puedes calcular el potencial de CTR del anuncio o combinar parámetros para realizar una ponderación combinada.

Algunos de los sistemas de selección más avanzados usan el aprendizaje automático para recomendar anuncios por usuario o por segmento. Los flujos de trabajo del aprendizaje automático no se detallan en este artículo, pero puedes obtener más información si consultas Compila funciones de aprendizaje automático (en la parte 2).

Entrega el anuncio seleccionado al usuario objetivo

Hasta este punto, los pasos detallados podrían considerarse como pertenecientes a la carga de trabajo de publicación de anuncios del lado del publicador. Sin embargo, después de seleccionar el anuncio, el servidor de anuncios muestra un vínculo o un fragmento de código HTML, que puede apuntar a cualquiera de las siguientes opciones:

  • Una ubicación en el servidor de anuncios del publicador.
  • Una ubicación externa que podría pertenecer al anunciante. Este servidor de anuncios se considera un servidor de anuncios orientado a la compra que implementa un modelo conocido como publicación de anuncios de terceros (3PAS). Con esta ubicación, los anunciantes pueden actualizar sus anuncios sin tener que ponerse en contacto o comunicarse con el servidor de anuncios del publicador. Esta ubicación también les permite administrar su propio seguimiento.

Ya sea que los especialistas en marketing prefieran alojar sus propias creatividades o que se alojen en el servidor de anuncios de un publicador, los procesos que llevan a la publicación del anuncio siguen siendo los mismos.

Almacenar creatividades

Las creatividades son archivos multimedia como videos o imágenes. El almacenamiento de estos elementos requiere un depósito de objetos escalable y con alta disponibilidad.

Cloud Storage es el almacén recomendado. Está construido para alojar petabytes de datos sin procesar o no estructurados. También ofrece opciones para crear copias de seguridad y archivar. Con Cloud Storage, puedes administrar el ciclo de vida de las creatividades; para esto, debes moverlas del almacenamiento en caliente al almacenamiento en frío a fin de reducir los costos de Nearline, Coldline y Archive.

Entrega creatividades

Aunque el almacenamiento de objetos, como Cloud Storage, está disponible globalmente, tiende a agregar latencia de red debido a la distancia. Además, el almacenamiento de objetos puede ser más costoso que publicar anuncios a través de una red de entrega de contenido (CDN).

Debido a que las creatividades y los píxeles de los anuncios son a menudo contenido público, puedes usar una de las siguientes soluciones de GCP para almacenar en caché el contenido en Cloud Storage:

  • Hacer que los objetos sean públicos: Con el control de caché, Cloud Storage puede usar la infraestructura existente de Google para almacenar el contenido en caché, pero con funciones similares a CDN limitadas y sin la posibilidad de forzar a una creatividad a expirar de forma global.

  • Vincular Cloud Load Balancing con Cloud Storage: El contenido alojado en Cloud Storage puede usar Cloud Load Balancing con Cloud CDN habilitado. En comparación con la salida de Cloud Storage, Cloud CDN ofrece precios de red con descuento y asistencia de URL firmadas, invalidación y claves de caché.

    En el siguiente diagrama, se ilustra esta segunda solución.

    Vinculación de Cloud Load Balancing y Cloud Storage

Para obtener comparaciones de rendimiento con otros proveedores, consulta estos informes de Cedexis de terceros.

Administrar los eventos de anuncios

Los diferentes tipos de eventos son útiles para el sistema, como en los siguientes ejemplos:

  1. Solicitud de anuncios: Cuando se recibe una solicitud de anuncio desde un sitio web de cocina de user_ABC, el sistema puede mejorar los segmentos de user_ABC si agrega algo como Cocina > Gastronomía india, o alguna otra información que refleje el interés del usuario.
  2. Impresión de anuncios: En un modelo de CPM, un anuncio se muestra a un usuario objetivo. El sistema registra la impresión para que el presupuesto restante pueda actualizarse.
  3. Clic en el anuncio: un usuario hace clic en un anuncio. Esta acción puede influir en los resultados de optimización de anuncios, especialmente si varios usuarios (únicos) hacen clic en el mismo anuncio dentro de un período establecido.
  4. Conversión: un usuario hace clic en un anuncio y realiza una acción esperada en la propiedad del anunciante, como comprar algo o registrarse.

Cuando se manejan eventos, es importante encontrar el equilibrio adecuado entre precio, actualización de datos y sobrecarga operativa en cada paso del proceso, especialmente cuando se realiza lo siguiente:

  • Recopilar y transferir grandes volúmenes y velocidades de eventos que provienen de impresiones, clics, conversiones y solicitudes de anuncios
  • Procesar eventos en tiempo real o sin conexión para extraer valores y calcular contadores como presupuestos, límites y tasas de clics
  • Exportar resultados a varias tiendas en tiempo real o sin conexión para conciliar la facturación o aplicar las operaciones de servicio adecuadas

Para obtener más detalles, consulta el ciclo de vida del evento (en la parte 2).

Recomendamos la siguiente arquitectura para capturar y procesar eventos en tiempo real:

Arquitectura para capturar y procesar eventos en tiempo real

Con esta arquitectura, ocurre lo siguiente:

  • Las impresiones y los clics envían solicitudes a un extremo HTTP a un código estático alojado en Cloud Storage o a un recopilador de servidores web alojado en Google Kubernetes Engine᠎ (GKE).
  • Los eventos de solicitud se registran mediante los registros HTTP del balanceador de cargas, o los eventos que capturan los recopiladores se publican en Pub/Sub.
  • Dataflow se suscribe al tema de Pub/Sub y procesa los eventos.
  • Luego, Dataflow exporta los eventos procesados o sin procesar a BigQuery para fines estadísticos y a la base de datos de inteligencia (contexto) a fin de actualizar los presupuestos restantes.

La elección entre el alojamiento de código estático en Cloud Storage o los recopiladores de GKE depende de tus requisitos:

  • Si debes realizar acciones de backend adicionales, usa GKE.
  • Si te preocupa la sobrecarga operativa, usa Cloud Storage.
  • Si estás de acuerdo con que cada tanto se reintenten las solicitudes, pero necesitas reducir los costos que implica ejecutar los recopiladores de GKE o Compute Engine, usa VM interrumpibles, como se muestra en la sección Plataforma de procesamiento (en la parte 1).

Próximos pasos