Un solo tag para gobernar tus anuncios: anatomía del SDK one-tag
El patrón SDK one-tag reduce la integración publicitaria a 1 script en el head: todo lo demás (slots, subastas, reglas) se controla en remoto. Estos 6 puntos describen la arquitectura tal como la documentan las plataformas AdTech modernas.
1. Instalación única: 1 script en el head
En el modelo clásico, cada slot exigía pegar 3 a 5 fragmentos de código por página y redeployar el CMS ante cada cambio. El SDK one-tag invierte la carga con 1 tag asíncrono instalado una vez, que luego descarga su configuración JSON en menos de 200 ms por página vista.
El script usa async para no bloquear el
render: la página alcanza LCP en menos de 2.5 segundos aunque el SDK aún esté resolviendo
slots.
2. El loop de 4 etapas: de la consola al viewport
Los stacks con SDK describen un circuito de 4 etapas: configuración central (inventario + GAM), SDK cliente (inyección de ads y eventos), subasta (Prebid.js + demanda) e inteligencia de datos (series temporales + reportes). Cada etapa se comunica por APIs en ciclos de minutos, no de semanas.
La consola central define sitios, slots, bidders, geo-targeting y paywalls; el SDK solo ejecuta. Cambiar un timeout de 1,000 a 800 ms se propaga por invalidación de caché en minutos sin tocar código.
3. Inyección de slots y protección de CLS
El SDK inyecta los contenedores de anuncio por JavaScript, pero reserva sus dimensiones con aspect-ratio antes de que cargue la creatividad. Esa reserva mantiene el CLS bajo 0.1, el umbral que Google exige para Core Web Vitals en el 75% de las visitas.
La práctica estándar limita a 3 a 5 slots por página de artículo, con lazy-load bajo el pliegue y formatos responsivos de 2 a 4 tamaños por slot.
4. Refresh inteligente por viewability
En vez de recargar cada 30 segundos por temporizador, el SDK renueva el slot solo cuando está visible según el estándar IAB/MRC (50% de píxeles por 1 segundo). Ese refresh por viewability eleva el CTR entre 15 y 30% y evita impresiones no vistas que diluyen el eCPM.
Los interruptores operativos (pausar slots, activar bidders, excluir URLs o filtrar tráfico inválido) se aplican desde el dashboard con efecto en minutos.
5. Orquestación Prebid + GAM en 1 llamada
El SDK coordina la secuencia completa en cada slot: subasta Prebid.js con 5 a 10 bidders en
800 ms, envío de key-values (hb_pb, hb_bidder, hb_adid) y llamada a GAM, que decide entre
demanda programática y directa en 100 ms.
El caché local del SDK evita viajes repetidos a la infraestructura: la configuración se guarda por 15 a 60 minutos y los eventos se envían en batch cada 10 segundos.
Referencias
- Prebid.org — Documentación oficial
- Google — Google Publisher Tag (GPT)
- Google — Ayuda de Ad Manager
- web.dev — Core Web Vitals