Opciones de infraestructura para ofertantes de RTB (parte 4)

Este artículo se centra en las tareas principales que realiza la plataforma orientada a la demanda (DSP). Estas tareas incluyen el manejo de solicitudes de publicidad, el uso de datos inteligentes, las ofertas y el manejo de eventos. En general, todas estas tareas deben realizarse rápidamente (en aproximadamente cien milisegundos). La plataforma orientada a la venta (SSP) o un intercambio de anuncios establecen el plazo de la latencia. En el resto de este documento se utilizan 120 milisegundos como plazo estándar (el ANS más común de Google).

Este artículo forma parte de la siguiente serie:

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

Descripción general

Además de las ventas directas a los anunciantes, los publicadores tienen la opción de exponer su inventario a los compradores programáticos, que compran impresiones a través de un sistema de ofertas en tiempo real (RTB). Los publicadores pueden aprovechar esto para vender el inventario restante o para reducir la sobrecarga de administración. En las RTB, el inventario del publicador se subasta a los compradores que ofertan por impresiones de anuncios.

Para la subasta, los publicadores usan las SSP que funcionan con intercambios de anuncios y DSP para mostrar automáticamente el anuncio que ganó una subasta. Lee la sección sobre ofertantes en la descripción general para obtener más información.

En el siguiente diagrama, se muestra una posible arquitectura de un sistema DSP sin la publicación de anuncios integrada.

Posible arquitectura de un sistema DSP sin la publicación de anuncios integrada

Para obtener más detalles sobre frontends administrativos, como los administradores de campañas y ofertas, consulta frontend de usuario (en la Parte 1).

Principales diferencias entre esta arquitectura y la que se muestra para el servidor de anuncios que se describe en la Parte 3:

  • La predicción de aprendizaje automático ocurre sin conexión. Estas se copian en un almacén de la memoria con el uso del hashing sensible a la localidad para crear claves según las combinaciones de características únicas. Consulta otras opciones para la entrega rápida de aprendizaje automático en el artículo de entrega de anuncios (en la Parte 3).
  • Los datos que leerán los ofertantes se almacenan en una base de datos NoSQL agrupada en clústeres, en la memoria, para lecturas rápidas.

Consideraciones de la plataforma

La sección sobre consideraciones de la plataforma (en la Parte 1) aborda la mayor parte de lo que necesitas. Sin embargo, los ofertantes deben cumplir algunos requisitos, como se indica en esta sección.

Ubicaciones geográficas

Para minimizar la latencia de red, ubica a los ofertantes cerca de los intercambios de anuncios principales. La proximidad minimiza el tiempo de ida y vuelta durante la comunicación entre los ofertantes y los intercambios de anuncios. Los intercambios de anuncios a menudo requieren una respuesta en unos 120 milisegundos después de que se envía la solicitud de oferta. Agotar el tiempo de espera con tanta frecuencia podría afectar la capacidad de la DSP para ofertar:

  • A corto plazo, el ofertante se perderá la subasta específica.
  • En el medio a largo plazo, la SSP podría comenzar a regular la DSP y enviar menos solicitudes de ofertas.

Balanceo de cargas

Cloud Load Balancing incluye compatibilidad para más de 1 millón de solicitudes por segundo a latencia baja en más de 80 ubicaciones del mundo. El frontend estará disponible detrás de una sola dirección IP mundial, que permite una configuración de DNS más simple. Cloud Load Balancing también se integra en Cloud CDN.

Cuando usas Kubernetes, un balanceador de cargas distribuye el tráfico a las instancias de VM e iptables de los programas kube-proxy para distribuir el tráfico a los extremos. Este método puede afectar el rendimiento de la red. Por ejemplo, el tráfico podría llegar a un nodo que no contiene el pod adecuado, lo que agregaría un salto adicional. Google Kubernetes Engine (GKE) puede ahorrarse ese salto adicional si se usan clústeres nativos de la VPC con IP de alias y el balanceo de cargas nativo del contenedor.

Aunque nuestro enfoque recomendado es Cloud Load Balancing, es posible que necesites configurar tu propio balanceo de cargas en Compute Engine o GKE. Considera, por ejemplo, este caso práctico de limitación de frecuencia:

  • Un trabajador de frontend de DSP procesa una solicitud de anuncio.
  • Si la solicitud es para un usuario (único) conocido, se incrementan los contadores de frecuencia correspondientes a la frecuencia con la que se entrega un anuncio o una campaña a ese usuario.
  • Si el usuario alcanza el umbral máximo que especifica el límite, no se colocarán más ofertas para ese usuario (único) durante un tiempo.

Debido a que los ofertantes de RTB tratan con miles de millones de solicitudes al día, si no estableces la afinidad entre las solicitudes de ofertas para un usuario (único) y el trabajador de frontend de DSP que procesa estas solicitudes, debes centralizar los eventos entrantes por región para agregar los contadores por usuario (único). La arquitectura que se mostró antes en la descripción general representa este enfoque centralizado: los recopiladores transfieren eventos, Dataflow los procesa y, luego, los valores como los contadores se incrementan mediante un nodo principal de Redis.

Un enfoque con afinidad permite que el mismo trabajador de frontend procese todas las solicitudes de anuncios que pertenecen al mismo usuario (único). El frontend puede mantener una caché local de sus contadores; esto elimina la dependencia (para este caso práctico) del procesamiento centralizado. El resultado es menor sobrecarga y latencia.

Por lo general, la afinidad entre un solicitante y el procesador se establece en el balanceador de cargas mediante el análisis de los encabezados de la solicitud entrante. Sin embargo, por lo general, los intercambios de anuncios quitan los encabezados de la información de este usuario y, por lo tanto, debemos procesar la carga útil de la solicitud. Debido a que Cloud Load Balancing no admite esta operación, si planeas configurar tu propio balanceador de cargas, debes tener en cuenta un software como HAProxy.

Por último, debes tomar una decisión: puedes elegir un servicio administrado que ofrezca una infraestructura global o puedes optar por una compilación personalizada que pueda adaptarse a casos prácticos específicos.

Conectarse a los proveedores

Según la relación y la proximidad con los intercambios de anuncios y las SSP, ten en cuenta las siguientes opciones de conexión:

  • Configura una interconexión a través de uno de tus socios y haz que el intercambio de anuncios o la SSP hagan lo mismo con los mismos socios. Esta opción podría proporcionar un ANS para el tiempo de actividad, una reserva de capacidad de procesamiento y costos de salida reducidos.
  • Si el intercambio de anuncios o la SSP también son un cliente de Google Cloud, considera configurar el intercambio de tráfico entre redes de VPC ya que puede reducir los costos de red. Ten en cuenta que esta opción tiene consecuencias para la seguridad.

Si quieres reducir aún más la latencia, ten en cuenta las siguientes opciones:

  • Usa sockets de dominio Unix, cuando sean compatibles, para comunicarte con un almacén de datos local.
  • Usa protocolos como QUIC o UDP cuando sea posible.
  • Usa búferes de protocolo para que la serialización y la deserialización de datos estructurados entre transmisiones de datos sean más rápidas.

Maneja solicitudes de ofertas

Un frontend que tiene los mismos requisitos de escalamiento que se describen en la sección frontends recibe las solicitudes de ofertas.

Por lo general, las solicitudes de ofertas se serializan en formato JSON o protobuf y, a menudo, incluyen la dirección IP, el ID de bloque de anuncios, el tamaño del anuncio, los detalles del usuario, el usuario-agente, el tipo de subasta y el plazo máximo de la subasta. Muchas DSP y SSP funcionan con el estándar OpenRTB. Pero independientemente del estándar o la serialización que se utilice, el código de frontend necesita analizar la carga útil y extraer los campos y las propiedades obligatorios.

El frontend descartará la solicitud de oferta; para ello, contestará con una respuesta sin oferta (como un código de estado HTTP 204) o continuará con el siguiente paso.

Ofertas

Un ofertante realiza las siguientes tareas:

  • Realiza la concordancia de usuarios: identifica al usuario (único).
  • Selecciona segmentos: recupera y selecciona los segmentos de usuario (único) y su precio.
  • Decide si realizar una oferta: algunas ofertas son demasiado caras, y es posible que algunas solicitudes de anuncios no coincidan con ninguna campaña existente. Un ofertante debe ser capaz de rechazar una oferta. Este rechazo ahorra tiempo de procesamiento y recursos.
  • Selecciona anuncios relevantes:** **si el ofertante decide ofertar, debe seleccionar un anuncio. La selección del anuncio correcto puede mejorar las probabilidades de que un usuario haga clic, y posiblemente genere una conversión.
  • Optimiza las ofertas: Un ofertante siempre debe tratar de encontrar el precio mínimo de oferta que ganará la subasta.
  • Compila una respuesta de oferta: El uso de OpenRTB o una aplicación personalizada permite compilar y mostrar una respuesta a la oferta serializada en formato protobuf o JSON. La respuesta debe incluir información como la URL del anuncio, la oferta y el extremo de la URL ganadora a los que se puede llamar si gana la oferta.

El aprendizaje automático suele facilitar estas tareas de ofertas. Por ejemplo, el AA puede utilizarse para predecir el precio óptimo y si la oferta podría ganarse antes de tomar una decisión sobre la oferta. Sin embargo, este artículo se centra en las decisiones de infraestructura. Para obtener más información sobre cómo entrenar y entregar modelos del AA, consulta las siguientes secciones:

Realiza la concordancia de usuarios

Existen dos formas comunes para identificar a un usuario (único):

  • Para la publicidad en dispositivos móviles, puedes usar un identificador de dispositivo reiniciable. Las aplicaciones nativas creadas en plataformas Android o iOS tienen acceso a un identificador de dispositivo reiniciable.
  • Para la publicidad en la Web, las plataformas de publicidad pueden utilizar cookies para almacenar un identificador de usuario reiniciable. Sin embargo, solo el dominio que creó las cookies puede leerlas, lo que dificulta el uso compartido del identificador en las plataformas. Los especialistas en tecnología de anuncios pueden diseñar tablas para combinar cookies independientes y obtener una visión más amplia de un cliente.

Pueden usarse tablas de concordancia entre las SSP, las DSP, las DMP y los servidores de anuncios. Cada asociación implementa un proceso diferente, incluso si todos los procesos son bastante similares.

En las ofertas en tiempo real, el proceso de coincidencia de cookies suele ocurrir mucho antes de que la DSP reciba una solicitud de oferta. La DSP inicia una solicitud de coincidencia de cookies con la SSP desde otra impresión de anuncios, o la SSP inicia una coincidencia de cookies con la DSP (“envío de píxel”) en una impresión de anuncios no relacionada. Con mayor frecuencia, la DSP inicia la sincronización que no necesariamente se produce en la propiedad de un publicador, sino en la propiedad de un anunciante. La forma en que funciona la concordancia de cookies en las ofertas en tiempo real se explica en el sitio web de Google Ad Manager y de forma bastante amplia en la Web.

Las SSP y las DSP deben acordar en quién aloja la tabla de concordancias. En este artículo, se supone que la DSP aloja el almacén de datos de concordancia de usuario. Este almacén de datos debe hacer lo siguiente:

  • Recuperar la carga útil para una clave específica en menos de diez milisegundos
  • Contar con alta disponibilidad dentro de una región
  • Estar presente en todas las regiones orientadas para minimizar la latencia de herramientas de redes.
  • Controlar mil millones de lecturas por día.
  • Controlar escrituras rápidas cuando se actualizan los contadores actuales.

Las bases de datos NoSQL son adecuadas para esa carga de trabajo ya que pueden escalarse de manera horizontal para admitir cargas pesadas y pueden obtener filas individuales de manera extremadamente rápida.

Si quieres un servicio completamente administrado que pueda obtener valores con el uso de una clave específica en milisegundos de un dígito, ten en cuenta Cloud Bigtable. Proporciona alta disponibilidad, y su QPS y capacidad de procesamiento se escalan de manera lineal con la cantidad de nodos. A nivel conceptual, los datos se almacenan en Bigtable con un formato similar al siguiente:

key internal_id created
ssp_id#source_id dsp_id 123456789

Seleccionar segmentos

Hasta este punto del proceso de ofertas, el sistema recibió una solicitud de anuncio, la analizó para extraer el ID de usuario de la SSP y la combinó con el ID de usuario interno de la DSP.

Con otra búsqueda, el sistema puede extraer los segmentos de usuario del almacén de perfil de usuario (único), ordenar los segmentos por precio y filtrar por el segmento más apropiado. El siguiente ejemplo muestra el resultado de una búsqueda. (El ejemplo está simplificado para mayor claridad).

key segments updated
dsp_id [ {‘dmp1':{‘segment':'a',‘type':‘cpm',‘price': 1}} {‘dmp1':{‘segment':'b',‘type':‘cpm',‘price': 2}} {‘dmp2':{‘segment':'c',‘type':‘cpm',‘price': 1.5}} ] 1530000000

Según la lógica de orden y filtrado, es posible que desees ascender algunos campos discretos (como el nombre del proveedor de datos) dentro de la clave. Un diseño de clave eficiente te ayudará a escalar y a reducir el tiempo de consulta. Para obtener asesoramiento sobre cómo abordar el diseño de la clave, consulta Elige una clave de fila en la documentación para el diseño de esquema de Cloud Bigtable.

Si bien en este artículo se usa Cloud Bigtable como servicio de ejemplo para leer segmentos y realizar la coincidencia de ID de usuario, los almacenes en memoria como Redis o Aerospike pueden ofrecer un mejor rendimiento, aunque a un costo operativo adicional. Para obtener más información, consulta los patrones de almacenamiento con alto nivel de lectura (en la Parte 1).

Para obtener acceso a los datos del usuario externos adicionales, las DSP suelen trabajar con plataformas de administración de datos (DMP) con las que implementan técnicas de concordancia de usuarios similares a las que se usan con la SSP.

Una DSP utiliza dos fuentes principales de datos para generar el perfil del usuario:

  • Información propia del usuario: una DSP puede haber reconocido a un usuario antes en la propiedad de un anunciante. Es posible que la DSP haya recopilado información sobre el usuario, como una cookie o el ID de dispositivo que la DSP puede usar para generar el perfil al usuario.
  • Información del usuario de terceros: si una DSP no funciona con muchos anunciantes, la DSP puede identificar usuarios (únicos) mediante datos de las DMP que funcionan con muchas propiedades en Internet o a través de aplicaciones. La coincidencia de usuario se realiza a través del ID de usuario proporcionado por el publicador, compartido por la DSP y la DMP, o de forma directa entre las DMP y las DSP. En el último caso, la DSP carga de forma recurrente datos sin conexión de las DMP con las que la DSP también mantiene una tabla de coincidencias.

Los datos de terceros pueden cargarse de forma recurrente desde una ubicación externa a Cloud Storage y, a continuación, cargarse en BigQuery. O bien, pueden cargarse en tiempo real en el extremo expuesto, que actúa como un sistema de mensajería.

Controla eventos

En la sección Administración de eventos, se aborda cómo transferir y almacenar eventos. En las RTB, también se recopilan los siguientes eventos adicionales:

  • Solicitudes de ofertas: son similares a las solicitudes de anuncios y se envían al extremo que proporcionas a la SSP o al intercambio de anuncios.
  • Adjudicación de la subasta: Cuando se gana una subasta, la SSP o el intercambio de anuncios envían una notificación al extremo ganador, que la DSP define con anterioridad dentro de la respuesta a la oferta.
  • Pérdida de la subasta: Las SSP o los intercambios de anuncios pueden notificar a todas las DSP si la oferta no resultó ganadora, pero rara vez ofrecen otra información. Determinadas SSP, como el intercambio de Google, comunican esta información en la solicitud de oferta posterior.

Estos eventos se utilizan en varios servicios de la plataforma para realizar las siguientes actividades:

  • Actualizar contadores: al igual que con el proceso de selección de anuncios, algunos contadores, como los límites o los presupuestos restantes, ayudan a filtrar las campañas o los anuncios irrelevantes.
  • Tomar decisiones relacionadas con la oferta: con el uso de los datos y los precios históricos de adjudicaciones o pérdidas de ofertas, el sistema mejora la decisión de ofertar o no ofertar y optimiza los precios de la oferta.
  • Proporcionar datos para los informes: de forma similar a la entrega de anuncios, los usuarios quieren saber cómo funcionan las ofertas y los anuncios.

Une los datos de la subasta y los datos posteriores a la adjudicación

Tu ofertante debe tomar decisiones para cada solicitud de oferta. Esto es diferente de la publicación de anuncios, en la que los precios se calculan para un lote de anuncios. Por este motivo, unir los datos lo antes posible puede mejorar las decisiones sobre las ofertas.

Cuando se manejan la solicitud de oferta y los eventos de subasta, debes tener en cuenta lo siguiente:

  • La entrega de anuncios encuentra diferencias de varios órdenes de magnitud entre la cantidad de impresiones, clics y conversiones. En las RTB, una solicitud de oferta, a diferencia de una solicitud de anuncios, no garantiza una impresión (el ofertante tiene que ofertar y ganar esa oferta).
  • El tiempo entre una solicitud de oferta ganadora y una impresión se mide en milisegundos.
  • El tiempo entre una impresión y un clic es de unos segundos como máximo.
  • El tiempo antes de la conversión puede ser de minutos, días o incluso semanas.

Estos patrones pueden provocar algunos problemas cuando unes datos, ya que es posible que el sistema tenga que esperar a que suceda algo que podría no pasar nunca (como un clic después de una impresión). Es posible que el sistema también tenga que esperar un día o una semana para que se produzca un evento; por ejemplo, para que se realice una conversión después de un clic, o una conversión no vinculada a un clic (denominada conversión posimpresión). Por último, el sistema podría haber ganado una oferta que no dio lugar a una impresión procesada y facturable.

Cuando diseñas el sistema, debes suponer lo siguiente:

  • Los datos se transfieren en tiempo real a través de un sistema de mensajería como Pub/Sub.
  • Tu herramienta de procesamiento de datos, como Dataflow, puede administrar la espera durante algunos milisegundos o incluso segundos para que se produzca una impresión o un clic después de una solicitud de oferta ganadora.
  • El sistema debe poder unir todas las solicitudes de ofertas, las respuestas de ofertas, las ofertas ganadoras, las impresiones, los clics y las conversiones.
  • El ID de subasta es común a todos los eventos.
  • Los clics y las conversiones que ocurren después de un período predefinido se pueden descartar; por ejemplo, cuando ha pasado demasiado tiempo para estar seguro de que el clic o la conversión se debe a la subaste específica.

Cuándo se realiza la unión, en la canalización de datos o después de que se almacenaron los datos, se determina según si deseas unir los datos de manera inmediata o si el proceso de unión puede esperar. Si decides unir los datos de inmediato, puedes implementar un proceso similar al que se menciona a continuación:

  1. Lee el evento desde Pub/Sub o Apache Kafka.
  2. Analiza y extrae la información, incluido el ID de subasta.
  3. Realiza una búsqueda de clave en Bigtable con el fin de ver si todavía existen eventos para el ID de subasta.
  4. Escribe el evento en Bigtable si no hay ningún evento preexistente.
  5. Une el evento con los datos existentes si hay eventos preexistentes.
  6. Escribe el evento en BigQuery para las estadísticas históricas.
  7. Escribe el evento directamente en un almacén de datos rápido si el receptor existe, o escribe el evento en un sistema de mensajería que, a su vez, permita que un grupo de colectores lea el almacén de datos rápido y escriba en ese almacén.

En el siguiente diagrama, se describen estos pasos.

Arquitectura distribuida para manejar eventos y solicitudes de ofertas

Ten en cuenta lo siguiente cuando implementes esta solución:

  • Debido a la naturaleza distribuida de Dataflow y Pub/Sub, es posible que los datos no estén ordenados. Sin embargo, eso no importa porque el objetivo es realizar una unión completa lo antes posible.
  • Debes realizar tu propia recolección de elementos no utilizados en BigQuery mediante una instrucción delete (simplificada en el diagrama). Esto se puede programar con Cloud Composer o mediante trabajos cron.
  • Usa la función de vencimiento de Bigtable para descartar los clics o las conversiones que tienen lugar después de un tiempo predefinido.

También puedes mejorar el flujo de trabajo con la funcionalidad de procesamiento oportuno y con estado que se ofrece en Apache Beam. Luego, puedes obtener eventos ordenados y no usar Bigtable.

Si decides usar uniones sin conexión porque puedes tolerar una demora, el proceso se parecerá al que se menciona a continuación:

  1. Lee el evento desde Pub/Sub o Apache Kafka.
  2. Analiza y extrae la información, incluido el ID de subasta.
  3. Agrega los registros procesados a un almacén de datos, como BigQuery.
  4. Une los datos con el ID de subasta y las marcas de tiempo más recientes cada N intervalos; N es un número predefinido de segundos, minutos, horas o días. Puedes usar Cloud Composer o los trabajos cron para esta tarea.
  5. Con Cloud Composer o los trabajos cron, borra los datos obsoletos (los datos con la marca de tiempo más antigua por ID de subasta y tipo de evento) cada N intervalos.

Exporta datos cerca de los ofertantes

Para ver las opciones de infraestructura sobre la entrega de datos, consulta Patrones de almacenamiento con alto contenido de lectura.

Si bien los conceptos para exportar datos son similares a la publicación de anuncios, los ofertantes deben mostrar la respuesta de la oferta dentro de un plazo predefinido. Por este motivo, es posible que algunos ofertantes prefieran utilizar almacenes que puedan manejar lecturas y escrituras en menos de milisegundos, incluso si estos almacenes requieren una mayor sobrecarga operativa. Por lo general, los ofertantes usan Redis con esclavos locales o Aerospike regional. Obtén más información sobre las opciones de infraestructura para exportar datos desde agregaciones en tiempo real o estadísticas sin conexión.

Próximos pasos