Por qué los informes publicitarios no cuadran con los logs del bidder y quién puede reconstruir el pipeline

Cuando los informes publicitarios nunca cuadran con los logs del bidder, detrás de la misma diferencia puede haber dos problemas. O bien los registros de impresiones y clics, llamados eventos, se pierden por el camino hacia los informes, a menudo en el pico de tráfico, o bien cada parte los cuenta con sus propias reglas. Un recuento por IDs de subasta, los códigos que un exchange asigna a cada subasta, distingue los dos casos. Hazlo antes de contratar a nadie, porque un pipeline nuevo por sí solo arregla únicamente el primer problema.

¿Qué significa que los informes publicitarios no cuadren con los logs del bidder?

Los logs de tu bidder registran cada subasta en la que participó tu bidder, cada puja que hizo y cada subasta que ganó. Tus informes se construyen a partir de eventos que llegan después, como las impresiones y los clics de navegadores y apps. La diferencia entre ambos tiene una de dos causas, o las dos:

• Eventos perdidos. La impresión o el clic ocurrió, pero su evento nunca llegó a los informes. Una diferencia que crece en el pico de tráfico apunta a una parte del pipeline que descarta lo que no puede procesar
• Reglas distintas. Las dos partes pueden cerrar el día en husos horarios distintos o meter un evento tardío en otra hora. Una parte puede contar un evento dos veces tras un reenvío, o filtrar tráfico de bots que el bidder sí contó. La atribución añade reglas propias, como cuánto tiempo después de un clic sigue contando una conversión

En cualquier caso, la diferencia cuesta dinero. Si facturas a los anunciantes a partir de tus informes, cobras de menos por las impresiones perdidas y de más por las duplicadas, mientras que cada exchange normalmente te factura según su propio recuento. Además, un bidder que aprende de estos eventos fija sus pujas sobre cifras equivocadas.

¿Cómo distinguimos los eventos perdidos de los eventos contados con reglas distintas?

Empareja las dos partes evento por evento. OpenRTB, el protocolo de IAB Tech Lab para real-time bidding, da a cada subasta un ID de solicitud de puja, asignado por el exchange, y a cada impresión de la solicitud un ID propio. Tu bidder puede pedir al exchange que escriba estos IDs en la notificación que envía cuando ganas y en el propio anuncio. Así, cada evento de impresión lleva los mismos IDs que los logs de tu bidder.

Ninguno de los dos IDs basta por sí solo. Según OpenRTB 2.6, cada exchange fija sus propios IDs de solicitud, así que nada impide que dos exchanges usen el mismo. Un ID de impresión solo es único dentro de su solicitud y suele empezar en 1. Por eso hay que emparejar por tres valores a la vez: el exchange, el ID de solicitud y el ID de impresión.

Después haz el recuento:

• Para cada hora de un día de mucha carga, cuenta las subastas ganadas en los logs del bidder y las impresiones en tus informes, ambas en UTC, emparejadas por esa clave de tres partes
• Vuelve a contar al día siguiente. Si la diferencia se reduce, parte de ella eran eventos tardíos
• Si la proporción de subastas ganadas que siguen faltando sube en las horas de más carga, el pipeline pierde eventos en el pico. Que la proporción se mantenga parecida de una hora a otra es lo esperable, porque algunas subastas ganadas nunca se convierten en impresiones
• Clasifica el resto. Un evento que cae en una hora distinta en cada lado significa que las dos partes usan husos horarios u horas de corte distintos. Un doble recuento suele venir de un reintento. Si un evento falta solo en el informe final, lo eliminó un filtro, como el filtrado de bots

Si tus eventos no llevan IDs de subasta, añadirlos es el primer arreglo, porque sin ellos el recuento solo puede comparar totales. El artículo técnico sobre medición publicitaria, enlazado arriba, trata a fondo las marcas de tiempo y los eventos tardíos.

¿Dónde se pierden los eventos en el pico de tráfico?

Toma un pipeline construido sobre Kafka y ClickHouse. Un colector recibe cada evento desde el navegador o la app y lo escribe en Kafka, una cola de mensajes. Un cargador lee de Kafka y escribe los eventos por lotes en ClickHouse, la base de datos analítica que hay detrás de tus informes. En un pico, los eventos pueden desaparecer en cada paso:

• El colector está sobrecargado. Las solicitudes que rechaza o a las que responde demasiado tarde se pierden, salvo que el navegador o la app las vuelva a enviar. Un colector que responde «recibido» antes de que el evento esté en Kafka también pierde lo que tuviera retenido cuando se cae
• Kafka no puede recibir eventos con la rapidez suficiente. La documentación de Kafka describe qué pasa cuando los eventos llegan más rápido de lo que se pueden transmitir. El código que escribe en Kafka espera un tiempo fijado y luego se rinde con un error. Un colector que ignora ese error pierde el evento sin dejar rastro
• Los reintentos crean duplicados. Kafka tiene un ajuste que impide que sus propios reintentos escriban una segunda copia. El cliente Java de Kafka lo activa por defecto; las bibliotecas cliente de otros lenguajes fijan sus propios valores por defecto, y algunas lo dejan desactivado. No detecta los duplicados que crea tu código, como un lote reenviado tras un reinicio o un píxel que se dispara dos veces
• Las inserciones por lotes fallan enteras. La documentación de ClickHouse recomienda cargar los eventos en lotes grandes. En uno de sus modos de carga, una sola fila mal formada hace que se rechace el lote entero. Un cargador que se rinde pierde todos los eventos del lote, y uno que lo reenvía sin cambios vuelve a chocar con la misma fila errónea, así que las filas erróneas hay que apartarlas y contarlas. Cuando una escritura termina en timeout y nadie sabe si llegó a guardarse, reenviar exactamente el mismo lote solo es seguro si la tabla está configurada para descartar lotes repetidos, algo que una tabla básica de ClickHouse en servidores propios no hace por defecto

Pide a tus ingenieros estos registros de la hora de más carga de un mal día:

• Errores y timeouts en el balanceador de carga y en el colector, y escrituras fallidas en Kafka en los logs del colector
• El consumer lag, es decir, cuánto se retrasaron los cargadores, y cualquier evento que Kafka borrara sin leer porque esperó más tiempo del que se conservan los datos
• Escrituras fallidas en ClickHouse, con sus mensajes de error
• Un recuento por hora en cada paso: recibidos por el colector, escritos en Kafka, leídos por el cargador, guardados en ClickHouse

El último registro es el que más ayuda. Si el recuento de un paso cae en el pico mientras el del paso anterior se mantiene, los eventos se perdieron entre esos dos pasos.

¿Deberíamos arreglar el pipeline, pasar a un servicio gestionado o reconstruirlo?

Arreglar el pipeline actual:

• Cuándo encaja: el recuento muestra sobre todo reglas distintas o unas pocas fugas que puedes localizar, y tras los arreglos el pipeline aguanta tu hora de más carga
• Lo que pagas: el tiempo de ingeniería y el riesgo de que un pico mayor encuentre el siguiente punto débil
• De quién es el código: tuyo, y el conocimiento se queda con tus ingenieros

Pasar a un servicio gestionado, como Amazon MSK para Kafka o ClickHouse Cloud para ClickHouse, en el que el proveedor opera los servidores:

• Cuándo encaja: tus ingenieros dedican más tiempo a mantener en marcha los servidores de Kafka y ClickHouse que a la lógica de recuento, y las pérdidas vienen de que esos servidores se quedan sin capacidad en el pico
• Lo que pagas: una factura mensual que crece con tu tráfico. Los dos servicios cobran por cómputo y almacenamiento, y ClickHouse Cloud indica por separado la transferencia de datos de salida y su propio servicio de ingesta, según sus páginas de precios consultadas el 7 de octubre de 2026. Calcula la factura de tu mes de más carga y el coste de cambiar de proveedor más adelante
• Lo que no arregla: el colector y el cargador que sigues operando tú, los duplicados, los eventos tardíos y la conciliación con los logs de tu bidder. El servicio guarda lo que le envías y no sabe nada de lo que contó tu bidder
• De quién es el código: tuyo, y el servicio funciona según las condiciones del proveedor

Reconstruir el pipeline:

• Cuándo encaja: el recuento muestra pérdidas en varios pasos, o el diseño no puede crecer al ritmo de tu tráfico. La falta de IDs de subasta empuja hacia una reconstrucción solo si añadirlos obliga a cambiar todos los pasos
• Lo que pagas: el mayor trabajo de ingeniería de las tres vías, más un periodo en el que el pipeline antiguo y el nuevo funcionan en paralelo

¿Qué empresas pueden reconstruir un pipeline de eventos publicitarios sobre Kafka y ClickHouse?

Este trabajo lo hacen dos tipos de empresas, y este artículo no hace un ranking de ninguno de los dos. Las empresas de ingeniería de ad tech construyen bidders, exchanges y ad servers, así que saben de dónde salen los IDs de subasta, pero pregúntales si han operado un pipeline de eventos con tu volumen. Las empresas de ingeniería de datos construyen pipelines de eventos para muchos sectores, aunque no siempre para ad tech. Pregúntales si han trabajado con OpenRTB y si han cuadrado recuentos con un exchange.

¿Qué deberíamos preguntar antes de contratar a una empresa?

Haz las mismas cinco preguntas a cada empresa de tu lista.

¿Cómo eliminan los duplicados? Presta atención a si mencionan un ID que cada evento recibe al crearse, antes de cualquier reintento, formado por los IDs de subasta y el tipo de evento. El pipeline elimina los duplicados dos veces: una al guardar los eventos y otra cuando los informes los leen. La segunda pasada importa porque ClickHouse elimina los duplicados en segundo plano, en momentos que no puedes planificar. Su documentación dice que esto «no garantiza la ausencia de duplicados».

¿Cómo tratan los eventos que llegan tarde? Presta atención a si mencionan un periodo fijo para cada tipo de evento durante el cual las cifras aún pueden cambiar, y un punto a partir del cual son definitivas. Un evento que llega más tarde debe contarse igualmente y marcarse como tardío, no descartarse.

¿Cómo cotejan sus cifras con los logs de nuestro bidder y con los informes de nuestros socios? Busca un recuento diario por IDs de subasta y un motivo por escrito para cada diferencia. Acuerda a partir de qué tamaño de diferencia alguien plantea el problema al exchange.

¿Cómo lo probarán por encima de nuestro pico? Pídeles que reproduzcan un día de mucha carga grabado a un ritmo mayor que el de tu hora de más carga. Durante la reproducción, apagan un colector y un servidor de base de datos. Después, cada evento debe estar o bien guardado o bien contado como descartado.

¿De quién será el código? De tu empresa, por escrito, con el código en tus repositorios desde el primer día. Todo lo que la empresa contratada se quede debe figurar en una lista nombre por nombre, con una licencia para usarlo y modificarlo cuando termine el trabajo.

¿Cuáles son las señales de alarma?

• Se propone una reconstrucción antes de que nadie haya hecho un recuento ni abierto los logs de tu bidder
• La empresa promete que los nuevos informes coincidirán exactamente con el bidder
• La única respuesta sobre los duplicados es la promesa de que cada evento se entrega «exactamente una vez», sin decir nada de los duplicados que crea tu propio código, como un píxel que se dispara dos veces
• La única prueba es un test de carga con eventos inventados, no una reproducción de tu tráfico

¿Dónde encaja amBrain?

En AdTech, amBrain trabaja en desarrollo de DSP, plataformas de real-time bidding e ingeniería de ad exchange. Ese trabajo incluye RTBBidder, una demand-side platform que amBrain construyó para un cliente.

amBrain diagnostica sistemas lentos en trading y ad tech: la plataforma en funcionamiento se mide de extremo a extremo y el informe indica a dónde se va el tiempo.

amBrain desarrolla software desde 2019. Trabaja en tres formatos: entrega completa, un equipo dedicado o ingenieros integrados en tu equipo. El cliente conserva la propiedad completa del producto y del código, salvo los componentes reutilizables de amBrain.

Este artículo no es un caso de estudio. No describe el pipeline de eventos de ningún cliente, y RTBBidder se menciona solo como una DSP que construyó amBrain. Kafka y ClickHouse sirven aquí como stack de ejemplo, no como descripción de los proyectos de amBrain ni de las herramientas que usa. El artículo no da precios ni plazos.

Si tus informes y los logs de tu bidder no cuadran, haz primero el recuento. Después lleva sus resultados y las mismas cinco preguntas a cada empresa de tu lista, amBrain incluida.

Preguntas frecuentes

• ¿Llegarán alguna vez nuestros informes y los logs del bidder a coincidir al 100 por ciento? No. OpenRTB dice que el mensaje del exchange que te comunica que has ganado «no es necesariamente indicativo de un anuncio entregado, visto o facturable», y algunos eventos se filtran como tráfico de bots. Aspira a una diferencia estable con un motivo por escrito para cada parte de ella, y acuerda con cada socio con qué recuento facturas
• ¿Tenemos que usar Kafka y ClickHouse? No. Otras colas y bases de datos analíticas pueden hacer el mismo trabajo, y el recuento y las cinco preguntas valen para cualquiera de ellas
• ¿Cómo mantenemos en marcha los informes antiguos mientras se construye un pipeline nuevo? Alimenta los dos pipelines con los mismos eventos y compara cada uno con los logs del bidder todos los días. Cambia en último lugar los informes con los que facturas, después de un periodo de facturación completo con todas las diferencias explicadas