Definición profesional
El wrapper es una biblioteca de código (típicamente JavaScript) que un publisher instala en su sitio para orquestar simultáneamente las solicitudes de puja hacia múltiples SSP y exchanges, recopilar las respuestas dentro de un tiempo límite especificado, normalizar las pujas a un formato común y enviarlas al ad server. Reemplaza el modelo secuencial del waterfall, donde cada SSP competía solo si el anterior no vendía la impresión, por un modelo paralelo donde todos compiten al mismo tiempo sobre cada inventario disponible.
Explicación sencilla
Imagina que tienes cinco compradores dispuestos a pagar por un espacio publicitario en tu sitio. Un wrapper les pregunta el precio que ofertan todos a la vez, espera un tiempo corto (máximo 2 segundos), recopila las ofertas que llegaron a tiempo y se las pasa ordenadas a tu sistema de publicidad. Sin wrapper, tendrías que preguntarles uno por uno, en fila, donde el primer comprador ofrece un precio y, si lo rechazas, recién ahí le preguntas al segundo. Muchas veces ni llegas a preguntarle al tercero o al quinto porque ya vendiste el espacio a uno de los primeros.
¿Por qué existe este concepto?
Hasta 2013, los publishers vendían su inventario en cascada. El primer SSP o exchange recibía la oportunidad de pujar. Si rechazaba o no respondía a tiempo, el flujo bajaba al siguiente y al siguiente. Este modelo beneficiaba a quien ocupaba la primera posición en la configuración, con independencia de si su oferta era la más alta. Un SSP conectado en la posición 5 casi nunca competía realmente porque los primeros acaparaban el inventario.
El header bidding llegó para resolver eso, pero creó un problema nuevo. Los publishers que integraban tres, cuatro o más SSP en el header terminaban con líneas de código acumuladas de cada proveedor, cada una con su propia sintaxis, tiempos de respuesta y formato de datos. El mantenimiento se volvía complejo y costoso. El wrapper unificó ese caos bajo un solo contenedor, un solo tiempo de espera y un formato común.
¿Cómo funciona?
El flujo ocurre en cinco pasos dentro de milisegundos, cada uno con una función específica.
- Solicitud inicial. Cuando el navegador carga la página, el wrapper detecta que hay espacios publicitarios disponibles y necesita pujas de los SSP.
- Envío paralelo. Genera solicitudes individuales para cada SSP conectado y las envía todas en el mismo momento en lugar de enviarlas una tras otra, que es como opera el waterfall.
- El tiempo límite. Define un timeout común, típicamente entre 1000 y 2000 milisegundos. Cuando ese tiempo se agota, el wrapper detiene la espera y procede, independientemente de cuántos SSP respondieron. Las respuestas que llegan después se descartan.
- Normalización. Las pujas que llegaron a tiempo llegan en formatos distintos, según cada proveedor. El wrapper traduce todas a un formato estándar que el ad server entiende.
- Envío al ad server. El ad server recibe las pujas ordenadas por precio, decide cuál gana considerando también su demanda directa y ordena la descarga del anuncio correspondiente.
¿Quién lo utiliza?
- Publishers y equipos de ad ops. Instalan y configuran el wrapper una sola vez, luego agregan o remueven SSP sin tocar código. Controlan los tiempos de espera, el orden de prioridad y el monitoreo de desempeño.
- Proveedores de wrapper. Prebid.org desarrolla Prebid.js, el estándar open source. Google, Amazon y otros SSP también ofrecen wrappers propietarios. Todos mantienen el código, lo actualizan según cambios en el protocolo y aseguran compatibilidad hacia atrás.
- Desarrolladores front-end del sitio. Integran el wrapper en el HTML de cada página y optimizan su impacto sobre la velocidad de carga.
- SSP y exchanges conectados. Reciben las llamadas estandarizadas que el wrapper genera en cada carga de página y compiten por la impresión disponible.
Caso práctico
Un publisher que operaba con waterfall y varios SSP conectados en cascada notaba que solo los proveedores en las primeras posiciones llegaban a competir con regularidad. Al reemplazar el waterfall por un wrapper con timeout fijo, todos los SSP conectados empezaron a recibir la solicitud de puja en cada carga de página, sin importar su posición en la configuración. El equipo de ad ops reportó una mejora sostenida en el eCPM promedio, atribuible a que el inventario ahora se subastaba entre todos los compradores conectados y no solo entre los que ocupaban las primeras posiciones del orden anterior.
Error frecuente
Confundir el wrapper con el ad server. El wrapper organiza las pujas de header bidding. El ad server toma la decisión final, comparando esas pujas contra la demanda directa y los line items configurados manualmente. Sin ad server detrás, el wrapper solo recopila datos.
Otro error frecuente es esperar que un timeout más largo atraiga más demanda. Ocurre lo contrario, porque los timeouts largos retrasan la carga de la página y los usuarios se van antes de que el anuncio llegue a mostrarse. La ventana de 1000 a 2000 milisegundos es el punto de equilibrio que la industria usa como referencia.
¿Qué no es?
El wrapper no es un SSP. El SSP es la plataforma del lado de la oferta que subasta el inventario ante compradores, mientras que el wrapper es la capa técnica que organiza y envía las solicitudes hacia varios SSP a la vez.
No es el ad server. El ad server toma la decisión final sobre qué anuncio se sirve, considerando pujas de header bidding, demanda directa y reglas de line items, mientras que el wrapper solo recolecta y normaliza las pujas antes de enviarlas.
Tampoco es sinónimo de Prebid. Prebid.js es la implementación open source más usada de wrapper, pero existen wrappers propietarios de otros proveedores con la misma función general.
Términos relacionados
Evolución histórica
El wrapper surgió como solución técnica poco después de la aparición del header bidding. Los primeros publishers que adoptaban header bidding integraban manualmente el código de cada SSP en el header de sus páginas, un proceso lento de mantener conforme crecía el número de integraciones.
A comienzos de 2015, AppNexus lanzó Prebid.js como wrapper de código abierto, lo que estandarizó el proceso bajo un solo container y lo puso a disposición de cualquier publisher sin costo de licencia. En 2017 Rubicon Project se sumó como colaborador del proyecto bajo licencia Apache y en 2018 AppNexus presentó Prebid Server como versión del wrapper que ejecuta las subastas del lado del servidor en vez del navegador, lo que redujo la carga sobre el dispositivo del usuario y permitió sumar más demand partners sin afectar la velocidad de carga de la página.
Desde entonces el wrapper client-side y el wrapper server-side coexisten como dos arquitecturas distintas para resolver el mismo problema de orquestación.
Estándares relacionados
| Estándar | Organización | Relevancia |
|---|---|---|
| OpenRTB | IAB Tech Lab | El wrapper server-side traduce las solicitudes y respuestas de puja al formato OpenRTB para comunicarse de manera estandarizada con SSP y exchanges, lo que facilita la interoperabilidad entre proveedores. |
| TCF (Transparency and Consent Framework) | IAB Europe | Los wrappers modernos integran el TCF para pasar la señal de consentimiento del usuario a cada SSP conectado antes de enviar la solicitud de puja, requisito para operar en mercados con regulación de privacidad como GDPR. |
Empresas y tecnologías asociadas
El wrapper de código abierto más extendido es Prebid.js, mantenido por Prebid.org bajo licencia Apache con contribuciones de publishers, SSP y consultoras de ad tech.
- Google Ad Manager ofrece su propia integración de header bidding con soporte nativo para wrappers de terceros y su propio mecanismo Open Bidding.
- Amazon Publisher Services distribuye Transparent Ad Marketplace, un wrapper propietario orientado a publishers que ya operan con las herramientas de Amazon Ads.
- Index Exchange, PubMatic y otros SSP publican sus propios adapters compatibles con Prebid.js, lo que permite a cada publisher decidir qué combinación de wrapper y demand partners se ajusta mejor a su stack.
Pregunta frecuente
¿Es obligatorio usar Prebid.js para implementar un wrapper?
No. Prebid.js es la opción open source más común porque elimina el costo de licencia y cuenta con soporte de la comunidad, pero existen wrappers propietarios ofrecidos por ad servers, SSP individuales o proveedores de gestión de header bidding que cumplen la misma función de orquestar subastas en paralelo.