Ad Exchange como parte de Real-Time Bidding (RTB) es una de las soluciones de AdTech que están transformando el mercado publicitario en línea. Su función principal es acoplar una gran cantidad de SSP y DSP que no tienen integración directa entre sí, así como revender una variedad de tráfico publicitario entre ellos.
Gracias a un pedido para el mercado estadounidense, nos sumergimos de lleno en los detalles específicos de la construcción de la plataforma Ad Exchange. Y en este artículo presentamos algunas ideas y resultados.
Declaración del problema.
Las ofertas en tiempo real (RTB) ofrecen la venta de espacios publicitarios en sitios en tiempo real para mostrar anuncios relevantes al público objetivo.
En resumen, el diagrama del proceso es el siguiente:
- el usuario final solicita una página web o aplicación móvil donde se reserva un lugar para un banner (el código para la plataforma de venta de inventario publicitario está incorporado: SSP, plataforma de suministro lateral);
- Para garantizar el precio de venta máximo del inventario, el SSP organiza licitaciones entre los diversos DSP (plataforma del lado de la demanda) a través de Ad Exchange, cuyo objetivo es comprar el inventario lo más barato posible;
- después del anuncio del ganador de la subasta, el DSP ganador envía un código de banner SSP, que se muestra al usuario;
- Otro aspecto del proceso es DMP, un sistema de terceros que proporciona a DSP información detallada sobre el usuario final (más allá de lo que puede transmitir SSP en forma de cookies, etc.) para justificar la conveniencia de la compra y el costo propuesto.
Hay bastantes intercambios de Ad Exchange hoy. Además, muchos SSP implementan sus propias ofertas (en realidad cierran la funcionalidad de Ad Exchange). Pero nuestro cliente estaba seguro de que, debido a algunas ideas nuevas, podría ingresar rápidamente al mercado y resistir la competencia.
Los intercambios funcionan según diferentes principios: alguien ofrece un margen mayor, alguien menos, alguien vende equipos únicos, otros se centran en bienes de consumo condicionales. El mercado es bastante joven y se está desarrollando activamente, por lo tanto, no hay modelos de negocio probados a lo largo de los años: todo se basa en hipótesis y experimentos audaces. La mayoría de los jugadores trabajan de acuerdo con un esquema simple: reciben una solicitud de uno de varios SSP con los que pudieron ponerse de acuerdo y la envían a todos los DSP integrados en anticipación de una mejor apuesta. Ingresos de Ad Exchange: la diferencia entre el precio de compra y venta del inventario publicitario en SSP y DSP menos los costos operativos.
Nuestro cliente sugirió optimizar este esquema distribuyendo correctamente las solicitudes de SSP al DSP, no enviando deliberadamente solicitudes "perdidas", reduciendo así los costos operativos. Debido a esto, puede reducir la comisión del intercambio sin perder ingresos y hacer que su oferta sea más atractiva en el contexto de Ad Exchange compitiendo en la lucha por SSP y DSP. Y conectar más socios dará ingresos y estabilidad en el mercado.
Para implementar esta estrategia en el mercado de EE. UU., Se nos asignó la tarea de realizar Ad Exchange con una distribución inteligente de las solicitudes, que debía proporcionar un buen porcentaje de recompra. En teoría, para dicha distribución, puede usar mucha información que acompaña a la solicitud, incluso datos de los sistemas de terceros (DMP) mencionados anteriormente. Sin embargo, el análisis complejo requiere recursos, por lo que la tarea es encontrar un equilibrio entre los costos de la distribución inteligente y la ganancia (en comparación con otros actores del mercado) de su implementación. En un mercado inmaduro relativamente nuevo, construir soluciones muy complejas, exprimir décimas de optimización, simplemente no tiene sentido.
Una característica importante del proyecto, además de las altas cargas esperadas, fue el cumplimiento de los requisitos no funcionales para la velocidad de la subasta presentada por SSP. En este segmento del mercado, es adecuado el tiempo de espera para esperar una respuesta del SSP a 300 ms, que tuvo que cumplirse junto con las llamadas a sistemas externos (DSP).
El proyecto comenzó en el otoño de 2016. Gracias a la experiencia del equipo en esta área, después de tres meses hicimos el primer prototipo y después de tres MVP (Producto mínimo viable) más listo, lo que nos permitió recopilar los primeros análisis para comenzar la distribución inteligente de solicitudes dentro de Ad Exchange.
El lanzamiento de MVP mostró que la hipótesis sobre el éxito comercial del proyecto es correcta: Ad Exchange comenzó a ganar dinero para el cliente. Los planes de desarrollo iniciales para Ad Exchange incluyeron un estudio más profundo de los datos, conectando la información del usuario final desde sistemas externos a análisis. Pero en la etapa de MVP, se decidió usar solo los datos que tiene el SSP. Esto fue suficiente para obtener el beneficio esperado.
Arquitectura de soluciones
La solución se basa en la plantilla de la Cadena de responsabilidad, que permite no corregir la ruta de las solicitudes dentro del sistema, agregando fácilmente procesadores y diversos servicios, desde la subasta misma hasta las herramientas de filtrado.
El cliente no nos limitó en la pila de tecnologías utilizadas. Por lo tanto, cuidando el desarrollo futuro y el soporte del proyecto, creamos una solución escalable horizontalmente usando Postgres y Hadoop.
Ad Exchange en sí está escrito en Java; al mismo tiempo, no utilizamos ningún marco para no hundirnos en la carga (trabajamos en un nivel bajo).
Para mantenernos dentro del tiempo de espera de SSP mencionado, seleccionamos los parámetros del recolector de basura (se usó G1) y elaboramos un trabajo sincrónico con una gran cantidad de solicitudes: utilizamos un cliente HTTP que no bloquea el flujo, así como una extensión del protocolo HTTP Keep-Live que permite enviar varias solicitudes dentro Una conexión TCP.
Los componentes de software se implementan en el hardware arrendado del host, como Las condiciones de la tarea no permitieron el uso de la nube debido a la superposición de recursos de máquinas virtuales en la nube (la asignación de los recursos necesarios puede llevar tiempo, pero no la tenemos). Por el momento, Ad Exchange utiliza cuatro servidores físicos, uno de los cuales es redundante (para actualizaciones integradas, etc.).
El código abierto Apache Kafka se utiliza como intermediario de mensajes; está idealmente integrado en nuestro modelo de "un solo suscriptor: muchos editores", aunque tuvo que estar ligeramente torcido para que no llegaran mensajes repetidos.
Cada uno de los servidores proporciona en el modo normal el procesamiento de aproximadamente 10 mil solicitudes por segundo (estos parámetros se establecieron durante el desarrollo de la solución). Ahora, la carga promedio es de 15-20 mil solicitudes por segundo, y en el pico el flujo de solicitudes alcanzó 40 mil por segundo durante varias horas, y Ad Exchange hizo un gran trabajo al respecto.
La distribución de solicitudes entre servidores se realiza mediante el equilibrador de carga de software nginx, que está configurado para nuestra tarea. En nuestra experiencia, en nginx puede mantener hasta 60-70 mil solicitudes por segundo, sin asignar un equilibrador de hardware por separado. Si en el futuro la carga en Ad Exchange supere este umbral, planeamos comprar un equilibrador de hardware que distribuirá las solicitudes entre varios del mismo tipo nginx.
Supervisa lo que está sucediendo, sujeto a un aumento constante de la carga, un sistema de supervisión, que forma parte del Ad Exchange creado.
Almacenamiento
Dada la dependencia del análisis durante la distribución de consultas, la base de datos es una parte integral de nuestro Ad Exchange. El sistema almacena información sobre ofertas, participantes en subastas y transacciones.
No tiene sentido recopilar ese volumen de datos durante todo el período de Ad Exchange, por lo que el almacenamiento tiene una arquitectura de varios niveles. Todos los datos de la subasta se almacenan por semana. En base a ellos, se construyen unidades intermedias de nivel superior, que se almacenan durante varios meses. Y sobre la base de los intermedios, se utilizan los agregados finales, que se utilizan en análisis a largo plazo y para conciliaciones con SSP y DSP. Entre otra información en estas unidades, hay datos sobre cuántas apuestas se han realizado y cuánto dinero pagará el intercambio SSP o esperará recibir de DSP.
Los puntos finales se almacenan durante toda la duración de Ad Exchange.
La recopilación de análisis y la formación de agregados proporcionan servicios separados.
Para que el almacenamiento correspondiera a la velocidad del sistema en sí, también tuve que trabajar con él. En particular, por algún tiempo peleamos con el hoster, porque los datos de la transacción simplemente no tuvieron tiempo de escribir en la base de datos. Resultó que la falla era un problema de hardware con la matriz RAID. Después de reemplazarlo, pudimos exprimir 90,000 solicitudes por segundo en Postgres (insertando datos en la base de datos).
El resto de Ad Exchange no tiene estado, lo que proporciona una escala horizontal fácil en el futuro. No almacena ningún dato sobre solicitudes: la información máxima recibida sobre qué DSP debe seleccionarse. Para que podamos agregar nuevos servidores para procesar las solicitudes según sea necesario.
Filtrado de tráfico
Un elemento clave del sistema que le permite reducir la carga y mantenerse dentro de los tiempos de espera indicados por el cliente es el filtrado de tráfico.
Según la tarea en cuestión, cualquier Ad Exchange:
- acepta solicitudes del SSP;
- realiza una subasta (envía solicitudes a varios DSP, compara los precios ofrecidos, identifica al ganador);
- está de acuerdo con la victoria del SSP (informa el precio del ganador menos su comisión, espera una respuesta con el precio final del espectáculo);
- completa la transacción (informa al DSP necesario sobre su victoria, conduce el tráfico de usuarios).
La distribución de solicitudes inteligentes en nuestro Ad Exchange se incluye en la etapa inicial de la subasta.
Cuando recibimos una solicitud del SSP con cierta información (IP, agente de usuario), la detallamos utilizando la información acumulada en el sistema: información de usuario conocida, una lista de DSP a los que se enviaron solicitudes similares, sus respuestas, etc. Esto es necesario para seleccionar la combinación más ventajosa de DSP para cada solicitud. Gracias a la selección de tal combinación, el sistema le permite no enviar solicitudes a aquellos DSP que no ofertan o lo hacen, pero son demasiado bajos. Para hacer esto, un servicio separado en tiempo real compila un mapa de cómo el DSP responde a las solicitudes (estas tarjetas se almacenan en Redis).
Paralelamente, verificamos el estado del DSP: si la proporción de respuestas dentro del tiempo de espera disminuye, el sistema reduce automáticamente el número de solicitudes a este DSP. Tan pronto como se reduce la carga en el DSP (y aumenta la proporción de respuestas correctas en un tiempo aceptable), el número de solicitudes vuelve gradualmente a su nivel anterior.
Entre los DSP que respondieron a tiempo, realizamos una subasta interna: seleccione la mejor oferta y envíela al SSP. Desde el momento de la solicitud del SSP hasta nuestra respuesta, no pasan más de 300 ms, de acuerdo con los requisitos de la industria.
Dado que enviamos los datos al SSP, donde se realiza nuestra subasta, debemos considerar las ofertas ganadas allí. El servidor de subastas ya está realizando su registro en la siguiente etapa, cuando procesa el tráfico de usuarios. Gracias a él, el mapa de respuesta DSP se enriquece con nuevos datos (junto con la información recopilada sobre el usuario final).
Una comparación de los datos obtenidos en la etapa de subasta y los parámetros conocidos del tráfico de usuarios nos permite filtrar los bots (clickers publicitarios, bots de búsqueda, etc.). DSP no canjea dicho tráfico y, en ausencia de su propio sistema de filtrado, se convierte en pérdidas para el cliente, que deberán cubrirse con margen.
Cabe señalar que el filtrado de tráfico de bot no se inició de inmediato. Pero después de la inclusión de bloqueos simples, la ganancia de margen fue de aproximadamente el 50%.
Por cierto, además de las herramientas automáticas de filtrado de tráfico en nuestro sistema, es posible que el cliente cambie manualmente los valores de umbral de varios parámetros, ajustando así el margen.
El tráfico de usuarios en sí mismo es crítico para nosotros, pero cuando se procesa, ya no es necesario encajar en 300 ms. Utiliza un sistema de procesamiento separado, que puede contener un poco al usuario, pero no permitirá perder esta solicitud.
Para garantizar la estabilidad de la solución, se introdujo un subsistema que, al comprender la carga actual de Ad Exchange, "corta" las solicitudes de subastas, que físicamente no puede procesar. Por lo tanto, el sistema está protegido del crecimiento de carga incontrolado del SSP.
Perspectivas
Hasta la fecha, el Ad Exchange que creamos funciona y genera buenas ganancias. Y brindamos soporte e integración de nuevos socios (DSP / SSP) según sea necesario. En total, varias docenas de sistemas ya se han integrado. Cada integración de este tipo implica no solo una conexión de software, sino también pruebas exhaustivas del servicio, ya que bajo cargas pesadas los problemas del servicio conectado pueden afectar a otros socios.
En general, el mercado se está moviendo hacia el hecho de que SSP y DSP se conectarán directamente, lo que hará innecesarios los intercambios. Pero la integración se basa en las capacidades de SSP y DSP. A pesar de la existencia de la API abierta descrita (protocolo OpenRTB), todavía no se reconoce universalmente en el mercado. Por ejemplo, un jugador importante como Appnexus ha integrado recientemente el soporte para OpenRTB.
Esencialmente, Ad Exchange es un proveedor de liquidez. Por lo tanto, es poco probable que la decisión en el futuro cercano pierda relevancia. Además, el modelo de intercambio solo está ganando popularidad en el resto del mercado publicitario.
Autor del artículo: Nikolay Eremin
PD: publicamos nuestros artículos en varios sitios de Runet. Suscríbase a nuestras páginas en
VK ,
FB o
Telegram-channel para conocer todas nuestras publicaciones y otras noticias de Maxilect.