La configuración de Header Bidding para Accelerated Mobile Pages (AMP) requiere una arquitectura específica centrada en el componente amp-ad y la función Real-Time Config (RTC). A diferencia de los entornos web estándar, AMP restringe la ejecución arbitraria de JavaScript, lo que significa que debe utilizar el marco de proveedor compatible para comunicarse con los socios de demanda. Al configurar sus etiquetas de Google Ad Manager (GAM) para incluir RTC, permite que el navegador obtenga pujas de múltiples intercambios de anuncios simultáneamente antes de que se finalice la solicitud de anuncio.
Esta estrategia de implementación garantiza que su sitio mantenga un alto rendimiento mientras participa en pujas competitivas. Dado que las páginas AMP a menudo se sirven desde la caché de Google AMP, el flujo de solicitud de anuncios debe estar altamente optimizado para evitar la latencia. Los editores que hacen esto correctamente ven mejores tasas de relleno, ya que el servidor de anuncios recibe más contexto sobre el inventario disponible antes de seleccionar el creativo final.
¿Cómo funciona el Header Bidding en AMP?
En un sitio tradicional, el Header Bidding a menudo se gestiona a través de un script contenedor como Prebid.js. En AMP, el entorno está controlado para garantizar el rendimiento. El proceso se basa en RTC, que permite que el tiempo de ejecución de AMP envíe solicitudes a un conjunto de puntos finales definidos en su configuración de anuncios. Una vez que llegan las respuestas, los datos se pasan al servidor de anuncios, que luego decide el creativo ganador en función de la puja más alta.
El tiempo de ejecución de AMP actúa como orquestador. Cuando se carga la página, el tiempo de ejecución identifica la configuración de RTC dentro de la etiqueta del anuncio. Luego, dispara solicitudes paralelas a los socios de demanda especificados. Estos socios devuelven una respuesta JSON que contiene claves de segmentación que se inyectan en la solicitud de anuncio final a GAM. Todo este proceso ocurre en segundo plano, manteniendo la experiencia del usuario limpia y rápida.
En una implementación típica, puede tener tres o cuatro postores compitiendo. El tiempo de ejecución de AMP gestiona estas solicitudes con límites de tiempo estrictos. Si un postor no responde dentro de la ventana definida, el tiempo de ejecución continúa sin su puja para garantizar que el espacio publicitario no quede vacío. Esta priorización de la experiencia del usuario sobre la finalización de la puja individual es lo que hace que el marco de anuncios de AMP sea único.
¿Cuáles son los requisitos básicos para la configuración?
- Una cuenta de Google Ad Manager en funcionamiento con las unidades de anuncios adecuadas definidas.
- Una lista de proveedores de Header Bidding compatibles que proporcionen un punto final compatible con RTC.
- Acceso al HTML de su página AMP para modificar las configuraciones de la etiqueta amp-ad.
- Archivos de configuración JSON válidos para los puntos finales de RTC.
- Alojamiento HTTPS seguro para todos los puntos finales de los postores para evitar errores de contenido mixto.
Antes de comenzar, asegúrese de que sus unidades de anuncios estén asignadas correctamente en Google Ad Manager. Si los ID de las unidades de anuncios no coinciden con lo definido en su configuración de RTC, las señales de puja no llegarán al inventario correcto. También debe verificar que los postores elegidos admitan el protocolo AMP, ya que no todos los socios de demanda tienen una integración compatible con RTC.
La documentación es clave aquí. Mantenga un registro de qué postor corresponde a qué URL de punto final. Si gestiona varios sitios, mantenga un archivo maestro de sus configuraciones. Esto evita la trampa común de usar puntos finales obsoletos que podrían resultar en solicitudes fallidas o un rendimiento degradado durante las horas de mayor tráfico.
¿Cómo implementar la configuración de RTC?
Para comenzar, debe agregar el atributo rtc-config a sus etiquetas amp-ad. Este atributo contiene un objeto JSON que enumera los proveedores que desea consultar. Cada proveedor proporciona una estructura de URL de solicitud específica. Asegúrese de que su servidor que aloja estas configuraciones siga las estrictas políticas de seguridad requeridas por AMP, específicamente con respecto a los encabezados CORS y los formatos de respuesta.
La estructura JSON para el atributo rtc-config generalmente sigue un esquema específico. Usted define los proveedores y sus respectivas URL de solicitud dentro del objeto de configuración. Es importante mantener el objeto ligero. Agregar demasiados postores puede aumentar el tamaño de la solicitud y potencialmente ralentizar la llamada de anuncio, lo que puede afectar negativamente el rendimiento general de carga de su página.
Una vez que la configuración se agrega al HTML, el tiempo de ejecución de AMP se encarga del resto. No necesita escribir JavaScript personalizado para activar estas llamadas. Simplemente asegúrese de que su página cumpla con los requisitos de validación de AMP después de agregar las etiquetas. Un pequeño error en la sintaxis JSON hará que el componente de anuncio falle silenciosamente, así que valide siempre su código utilizando la herramienta de validación oficial de AMP.
Google AMP Cache es una red de entrega de contenido basada en proxy que sirve páginas AMP válidas para mejorar la velocidad de carga.
Google Search Central
Cómo aplica esta tecnología Alien Road
En Alien Road, seguimos un ciclo de vida de implementación estricto para nuestros clientes. Comenzamos auditando la pila de anuncios actual para identificar qué socios de demanda ofrecen el mejor rendimiento para su perfil de tráfico específico. Luego, creamos un entorno de prueba para validar los tiempos de respuesta de RTC, ya que las respuestas lentas de los postores pueden afectar negativamente las métricas de carga de su página. Una vez verificado, enviamos la configuración a las páginas AMP de producción y monitoreamos las tasas de relleno dentro del panel de Google Ad Manager.
En un compromiso típico, a menudo encontramos que los clientes tienen demasiados postores configurados. Trabajamos para simplificar esto seleccionando solo los socios que brindan resultados consistentes. Luego, configuramos alertas de monitoreo en Google Ad Manager para detectar si algún postor específico comienza a devolver errores o alta latencia. Al mantener la configuración ágil, nos aseguramos de que los ingresos publicitarios se mantengan altos sin sacrificar la velocidad que hace que AMP sea valioso.
¿Cuáles son los errores comunes que se deben evitar?
Un error frecuente es no gestionar la configuración de tiempo de espera para los postores. Si un postor tarda demasiado en responder, retrasa toda la entrega de anuncios, lo que perjudica la experiencia del usuario y potencialmente sus puntuaciones de velocidad de página. Otro problema es la configuración incorrecta de CORS en el lado del proveedor, lo que hace que el navegador bloquee la solicitud. Verifique siempre que sus puntos finales sean accesibles y devuelvan un JSON válido.
Otro error común es ignorar el impacto de los bloqueadores de anuncios en su configuración. Si bien RTC ocurre a nivel de servidor a servidor o de tiempo de ejecución a postor, algunos usuarios aún pueden bloquear las solicitudes de anuncios ellos mismos. Pruebe siempre su implementación en un entorno de navegador limpio sin extensiones para asegurarse de que la unidad de anuncio base se cargue incluso si las señales de Header Bidding fallan por alguna razón.
¿Cómo verificar sus datos de rendimiento?
Después de la implementación, su enfoque principal debe ser el informe de participación en la puja en Google Ad Manager. Este informe le mostrará con qué frecuencia sus postores devuelven una señal de precio válida. Si nota una gran discrepancia entre el número de solicitudes y el número de pujas devueltas, es posible que deba ajustar la configuración de tiempo de espera o revisar su lista de postores.
- Utilice la herramienta AMP Validator para asegurarse de que sus nuevos atributos amp-ad no rompan la validez de la página.
- Compruebe la consola del navegador para ver las solicitudes de red a sus puntos finales RTC definidos.
- Revise los informes de participación en la puja dentro de Google Ad Manager.
- Ejecute una prueba A/B comparando la nueva configuración con los datos de rendimiento de anuncios anteriores.
- Monitoree Core Web Vitals para asegurarse de que la configuración de anuncios no cause cambios de diseño.
Por dónde empezar esta semana
Comience identificando una página de destino con mucho tráfico para probar su nueva configuración de RTC. No aplique cambios a todo el sitio a la vez. Verifique que las unidades de anuncios se representen correctamente en la herramienta de vista previa de Google Ad Manager, luego monitoree sus métricas de ingresos durante 48 horas para confirmar que la configuración de Header Bidding está dando los resultados esperados antes de escalar a todo el inventario de su sitio.