1
Download Estándar para la entrega de publicidad en vídeo digital
Transcript
ELEMENTO VideoClicks ATRIBUTOS Ninguno VALORES REQUERIDO URL No ClickTracking URL No CustomClick URL No ClickThrough Estándar para la entrega de publicidad en vídeo digital Id MediaFiles MediaFile String No URL Sí Sí Id String No Delivery Streaming, progres- Sí sive String Sí Type Video Ad Serving Template; VAST Versión 2.0 No Bitrate Integer NOTAS URL a abrir como página de destino cuando el usuario hace clic en el vídeo. URL a pedir para propósitos de tracking cuando el usuario hace clic en el vídeo. URLs a pedir en eventos personalizados tales como conflictos de vídeo Identificador opcional Situación del archivo lineal Identificador opcional Método de entrega de la publicidad Tipo MIME. Los populares tipos MIME incluyen, no estando limitados a “video/x-ms-wmv” para windows media, “video/x-flv” para Flash Video. Bitrate del vídeo codificado en Kbps Width Integer Yes Dimensiones del vídeo en píxeles. Height Integer Yes Dimensiones del vídeo en píxeles. Scalable Boolean No Si permite escalar la imagen MaintainAspectRatio Boolean No ApiFramework String No Si la publicidad debe mantener su aspecto en relación a cuando sea escalada. El apiFramework define el método a emplear para establecer comunicación si el MediaFile es interactivo. Comisión de Vídeo publicitario - IAB Spain Marzo de 2011 1 Este estándar ha sido desarrollado por la Comisión de Vídeo publicitario de IAB Spain. Se trata de una adaptación del documento de IAB USA, VAST 2.0. Acerca de la Comisión de Vídeo publicitario de IAB Spain: La Comisión de Vídeo de IAB Spain se formó en noviembre de 2010 con el fin de crear un conjunto de guías, medidas y opciones creativas para la publicidad interactiva de vídeo. La Comisión trabaja para educar a los profesionales del marketing y agencias en las fortalezas del vídeo digital, al tiempo que tiene como misión la estandarización de las prácticas del sector. Las empresas integrantes de la subcomisión técnica responsable del presente documento han sido: Atres Advertising, Eyewonder, Google, Kewego, MediaMind, Publimedia Gestión, Publipress Media, Smartclip, Telefónica, Vivaki y Weborama. ÍNDICE Resumen y enfoque..................................................................................................... 1 Definiciones................................................................................................................. 2 Recomendaciones adicionales.................................................................................... 3 Introducción................................................................................................................. 4 Métodos de Ad Serving............................................................................................... 5 Tracking de impresión.................................................................................................. 7 Wrapper ads................................................................................................................ 8 Respuesta publicitaria en VAST. ................................................................................. 9 Clic tracking................................................................................................................ 20 Usando extensiones................................................................................................... 20 Apéndice A: Recomendación de formato de tag publicitario...................................... 21 RESUMEN Y ENFOQUE El enfoque de este proyecto es el de desarrollar estándares de respuesta publicitaria basados en XML para vídeo “in-stream”, así como la definición del esquema XML (XML Schema Definition o en sus siglas XSD) para desarrolladores. Esta plantilla para servir publicidad en vídeo (denominada de manera coloquial según las siglas VAST) está llamada a adecuar la mayoría de las prácticas actuales dentro del negocio de publicidad online. Este documento está diseñado para su aplicación a cualquier reproductor de vídeo bajo demanda donde la respuesta publicitaria es analizada antes de la reproducción del vídeo. Por ejemplo, el uso de este estándar sería apropiado en un reproductor flash de Adobe donde la respuesta publicitaria fuera solicitada y analizada en ActionScript, pero no sería apropiada en el caso de que contuviera una lista de reproducción SMIL enviada, directamente, al reproductor. Además, será posible usar el formato XML para aplicaciones distintas de vídeo bajo demanda, como por ejemplo para streaming de vídeo en directo, reproductores descargables de vídeo, set-top boxes, etc, pero esas aplicaciones están explícitamente fuera del enfoque del presente documento. El objetivo de estas especificaciones es el de favorecer un estándar compatible con cualquier reproductor de vídeo que sea “codificable”. Será responsabilidad de cada servidor de publicidad secundario, desarrollar su propia implementación del estándar, y también será responsabilidad de cada editor o vendedor, implementar el estándar de su servidor de publicidad primario y de sus reproductores de vídeo Este documento pretende soportar tanto publicidad lineal de vídeo (conocida como “pre-rolls”) como publicidad de vídeo no lineal (conocida como “overlays”) y anuncios acompañantes según lo definido en el documento “Estándares de formatos publicitarios interactivos; Formatos de Vídeo”. Muchos de los anuncios no-lineales incluyen interacciones complejas dentro del reproductor de vídeo, y por ello el estándar VAST no debería ser por sí mismo suficiente como para implementar dichos anuncios a lo largo de los servidores de publicidad en este momento. Es también importante mencionar que el estándar VAST no especifica la sincronización de los anuncios dentro de un reproductor de vídeo; se deja al propio reproductor la responsabilidad de gestionarlo una vez que comprenda el contexto en el cual aparecerá el anuncio. 1 DEFINICIONES Anuncio acompañante (Companion Ad). Usualmente texto, publicidad gráfica, rich media o entornos gráficos (skins) que rodean la experiencia de visualización del vídeo. Estos anuncios pueden tener múltiples tamaños y apariencias y, típicamente, se ejecutan junto al reproductor de vídeo o a su alrededor. Anuncio InLine. Documento tipo VAST que incluye todos los elementos necesarios para desplegar la experiencia visual del anuncio. Anuncio de vídeo lineal. El anuncio es presentado antes, en mitad o después de que el contenido de vídeo sea consumido por el usuario, de manera muy similar a un anuncio comercial de televisión tradicional que puede ir antes, durante o después del programa elegido. Anuncio de vídeo no-lineal. El anuncio es reproducido de manera concurrente al contenido de vídeo de manera que el usuario sólo ve el anuncio mientras se reproduce el contenido. Servidor de Publicidad Primario. Primer servidor publicitario llamado por el reproductor de vídeo u otro entorno de ejecución. Es asumido que en la mayoría de los casos en los que un editor realiza peticiones publicitarias, éstas se hagan a través del servidor de publicidad primario (bien sea propio o de un tercero) y a continuación se procederá a redirigir a otros servidores secundarios. Servidor de Publicidad Secundario. Servidor de publicidad utilizado por una red publicitaria o por el comprador de los anuncios para servir creatividades, resultados y optimizar un sistema más allá del servidor primario. VAST (Video Ad Serving Template). Formato de documento XML que describe el anuncio que se mostrará dentro, alrededor o encima del reproductor de vídeo o anuncio wrapper (ver definición) que apunta hacia otro documento VAST que será solicitado posteriormente. Reproductor de vídeo. Entorno en el cual el contenido de vídeo es reproducido. El reproductor de vídeo debe ser desarrollado por el editor o provisto por el proveedor. Anuncio Wrapper (redirección). Documento VAST que dirige a otro documento VAST de un servidor diferente. 2 RECOMENDACIONES ADICIONALES Además de la respuesta XML estandarizada que se detalla más adelante, es recomendable atender a las siguientes recomendaciones adicionales para la entrega satisfactoria de publicidad en vídeo: 1. Se puede añadir un conjunto de parejas de valores clave a la petición del tag publicitario para reducir errores como consecuencia de respuestas publicitarias incorrectas. Por ejemplo, si un editor solo desea recibir anuncios de vídeo con formato Windows Media o de una duración determinada, deberá definir el tag publicitario de forma que solo provea anuncios con esas especificaciones. Debido a que la sintaxis de los diferentes tags publicitarios varía significativamente entre servidores, este es un aspecto opcional recomendado del proyecto y no un requerimiento formal. Esta recomendación está incluida en el documento como Apéndice A. 2. El método de comunicación entre el propio anuncio y el reproductor de vídeo en el cual se despliega. Esta comunicación es importante debido a que tanto los anuncios lineales como no lineales pueden ser interactivos, y tal interacción con el usuario afectará generalmente a la actividad del reproductor de vídeo. Por ejemplo, cuando un usuario hace clic sobre un overlay se le presenta al usuario información extra acerca del anunciante y, mientras, el contenido de vídeo se mantiene pausado. Actualmente, editores y proveedores han implementado este tipo de comunicación de una forma no estandarizada, resultando en un trabajo adicional para todas las partes al implementar campañas. Esta recomendación, llamada VPAID, ha sido publicada también por IAB Spain en un documento separado y disponible aquí. 3 INTRODUCCIÓN El desarrollo de un método común para servir publicidad in-stream es necesario para que los editores de publicidad acepten el estándar. La ausencia de un modelo estandarizado está causando dos tipos de ineficiencias: los editores nos son capaces de usar fácilmente redes publicitarias como salida a inventario invendido, y los compradores no son capaces de usar sus propias herramientas de medición y optimización para la publicidad in-stream. GRUPO BENEFICIOS ESPERADOS • Incrementar el rendimiento usando redes publicitarias para vender inventario invendido. Editores • Reducir fricción entre compradores al permitir tags publicitarios de terceros. • Integrar fácilmente nuevos editores sin la necesidad de integración técnica. Redes de publicidad • Reducir fricción entre compradores al permitir tags publicitarios de terceros. • Utilizar inversión existente para publicar publicidad y usar herramientas de medición y optimización para controlar los procesos de publicación. Agencia / Anunciantes • Construir un estándar único en lugar de múltiples estándares propietarios. Proveedores de tecnología 4 MÉTODOS DE AD-SERVING Los editores permitirán uno o dos métodos para servir publicidad in-stream: • Codificación interna de vídeo y URIs dentro del reproductor del servidor de publicidad primario. • Redirección dinámica desde sus servidores de publicidad hacia otros servidores (uno o más). Este proyecto está solo centrado en el método dinámico. El método de codificación puede ser fácilmente configurado por los responsables de tráfico basándose en requerimientos individuales de los editores, y no requiere una estandarización. Petición de publicidad El siguiente gráfico muestra la secuencia de petición de publicidad de un reproductor de vídeo en el explorador de un usuario. 5 Descripción genérica de publicación de publicidad por terceros para in-stream 1. El sistema de un editor (ejemplo: servidor de publicidad, reproductor de vídeo en el site del cliente u otro mecanismo) hace una petición publicitaria al servidor de publicidad secundario. El tag publicitario hacia el servidor publicitario secundario debe estar presente dentro de una lista de reproducción, codificado internamente en el entorno del player, devuelto por el servidor publicitario como una redirección o derivado. Si es devuelto desde un servidor publicitario primario, la petición hacia el servidor secundario no generará una impresión de manera inmediata, ya que la guía propuesta por IAB para impresiones de vídeo especifica “tracking post-buffering”. 2. El servidor de publicidad secundario puede tanto responder con un Wrapper XML (redirección) señalando hacia otro servidor secundario, o responder con un XML tipo VAST que describe el anuncio que deberá mostrarse. Tanto el Wrapper XML como el XML VAST están descritos más adelante. Será responsabilidad del editor determinar las reglas de negocio que especifiquen el máximo de saltos entre servidores secundarios que son permitidos para optimizar la experiencia de los usuarios. En cada cadena de servidores de secundarios el tamaño total de los datos transmitidos y la latencia incrementará. De esta forma muchos editores restringirán el número de redirecciones a dos o menos. Opcionalmente, el reproductor de vídeo podrá validar reglas de negocio relacionadas con la respuesta XML y elegir si mostrar o no el anuncio devuelto. Por ejemplo, si el reproductor sólo acepta 15 segundos de espacio de vídeo y el servidor publicitario secundario envía un anuncio de 30 segundos, puede ser denegado y generar un error. Tal y como se discutirá más adelante en este documento, los servidores de publicidad deberán tratar de adoptar convenciones estandarizadas para poder reducir la frecuencia de este tipo de errores. 3. Basado en la respuesta XML, el reproductor de vídeo solicitará un conjunto de URIs de seguimiento para la generación de informes. Por consiguiente, los servidores publicitarios y reproductores de vídeo deberán soportar múltiples tipos de métricas y, por tanto, diferentes combinaciones de informes. 4. Tanto el servidor publicitario primario como todos los secundarios deberán registrar impresiones. La sección “registro de impresiones” de este documento detalla este punto. 6 TRACKING DE IMPRESIÓN Para favorecer la adecuada impresión del tracking recomendada por IAB, las peticiones de publicidad para los vídeos necesitan retrasar la impresión del track hasta que el vídeo se haya almacenado en el buffer por completo. De cualquier forma, el método estándar de redireccionamiento entre ad servers que usan respuestas HTTP 302, no permite a cada ad server comunicar al player de vídeo la adecuada impresión de la URL que requiere. Por ejemplo cuando el player de vídeo hace una petición al ad server primario, se devuelve un 302 al tag de publicidad del ad server secundario. El ad server secundario responde con un XML que incluye una URL para la impresión del track. El player de vídeo pide esta URL tras el almacenamiento en buffer, por lo que el ad server secundario almacena la correspondiente impresión de vídeo IAB. Pero ¿cómo sabe el ad server primario cuándo almacenar una impresión? Existen tres métodos posibles para solventar esta limitación: 1. Guardar cada redirect de respuesta del ad server en un XML adicional incluyendo las URLs de tracking más destacables (“XML Wrapper Method”). 2. Emplear una sintaxis basada en tags para incluir la impresión y el clic tracking en la petición de una forma similar a como se funciona a día de hoy en multimedia (“Rich Media Method”). 3. Solicitar que todos los ad servers secundarios incluyan campos en sus interfaces de trafficking para la inclusión de un número de reportes URL´s de medios y redes (“Multiple URL Method”). Aunque cualquiera de estos tres métodos es aceptable, la especificación VAST incluye soporte directo para el XML Wrapper Method a través del elemento <wrapper>. XML Wrapper es el método preferido debido a su poder y su capacidad de extensión. Dependerá de cada medio determinar qué políticas aplicar para evitar un excesivo redireccionamiento o un gran tamaño de archivo en las respuestas del XML. 7 WRAPPER ADS El flujo del método XML Wrapper es muy similar al diagrama simplificado que se indica arriba, con algunas diferencias importantes: ción. 1. El ad server primario o el sistema de administración de contenido es el primero en recibir una peti- 2. El ad server primario responde con un documento VAST XML, con un Wrapper Ad (información complementaria) que incluye la impresión URI, otros tracking URIs, y clic tracking URIs que serán pedidos por el player de video, a través del tag de publicidad, al ad server secundario desde el cual se servirá la publicidad. 3. El player de vídeo pide el tag de publicidad desde el ad server secundario. 4. El ad server secundario devuelve el documento VAST que contiene un anuncio (anuncio lineal) o, de manera alternativa, puede devolver un documento VAST que contenga un segundo bloque de información complementaria (Wrapper Ad). Potencialmente, puede haber una tercera o cuarta configuración de URIs como en el caso que el servidor de publicidad redireccione a un servidor de agencia. Esto implica que el player de vídeo necesita mantener el track de múltiples tracking URI´s por evento y por pieza publicitaria. 5. Las URls del servidor secundario se solicitan cuando tienen lugar ciertos eventos. 6. Las URls del ad server primario se solicitan cuando tienen lugar ciertos eventos. Estas URIs se determinan por el primer Wrapper Ad devuelto. El Wrapper Ad incluye un subconjunto de elementos descriptivos y de seguimiento de los anuncios, junto con un elemento extra para el tag de publicidad del servidor de publicidad de streaming. 8 RESPUESTA PUBLICITARIA EN VAST El objetivo de este proyecto es la definición del XML estandarizado en la respuesta. Es necesario considerar las siguientes especificaciones acerca del XML de respuesta: 1. El elemento primordial en la definición del XML en VAST es el <Ad>. Un “Ad” contiene una combinación de vídeo, acotaciones y unidades no lineales para un único anunciante. 2. Una sola respuesta VAST puede incluir múltiples anuncios de múltiples anunciantes. Dependerá del reproductor de vídeo la determinación del orden, tiempos, localización, etc… para múltiples anuncios. De cualquier modo, el player debería, generalmente, respetar el orden secuencial de los elementos publicitarios incluidos en una respuesta VAST. 3. La respuesta VAST no contiene información del emplazamiento o tiempos de los elementos. Dependerá del player de vídeo determinar la óptima inclusión de puntos en los anuncios. 4. Un Ad puede ser tanto del tipo <InLine>, que quiere decir que contiene todos los elementos necesarios para reproducir la experiencia visual, como del tipo <Wrapper>, que indica a un documento downstream VAST que debe ser pedido desde otro servidor. 5. La respuesta XML puede indicar que ningún anuncio de ningún tipo está disponible. Esto debería ser indicado por la ausencia de Ad. 6. Un Ad puede incluir uno o más elementos <Creative>, que son parte de una única ejecución en un contenedor <Creatives>. Por ejemplo, un Ad puede incluir un elemento lineal de vídeo con una configuración del complemento de banners; esto sería reflejado en dos elementos Creative. 7. Tres tipos de Creatives son soportados y mostrados en elementos <Linear>, <NonLinearAds>, y <CompanionAds>. El elemento Creative toma un atributo “secuencia” opcional que indica el orden sugerido en el que los Creatives deberían ser mostrados. Si dos elementos Creative tienen por objeto ser mostrados a la vez deben compartir el mismo número secuencial. 8. Un Ad incluye un único elemento <Impression> requerido que debería ser pedido tan pronto como algún elemento creativo en el Ad sea mostrado en pantalla. 9. Cuando hay múltiples elementos Creative sería deseable realizar un seguimiento a lo mostrado en pantalla por cada elemento de forma separada. Un elemento de tracking adicional está incluido en elementos creativos y debe ser pedido tan pronto como el respectivo elemento sea mostrado. Por ejemplo, suponga que un Ad incluye un vídeo lineal y un overlay no lineal y el vídeo es reproducido en primer lugar. Cuando el vídeo es reproducido el player debe pedir ambas impresiones URL y el tracking creativeView URL para el vídeo. El player debe por tanto requerir el tracking creativeView URL para el overlay tan pronto como ése elemento sea visible. 10. El elemento lineal define un vídeo, imagen, o elemento interactivo que va a ser reproducido dentro del área de visión de vídeo. 9 11. Los elementos CompanionAds pueden incluir uno o varios complementos de banners de diferentes dimensiones en pixel o tecnologías. Si el grupo de banners va a ser mostrado en diferentes momentos en la reproducción, entonces se deben emplear múltiples Creatives con opción a distintas posibilidades secuenciales. 12. Los elementos NonLinearAds pueden incluir uno o más elementos no lineales que representan un único concepto creativo. Si la intención es mostrar diferentes objetos no lineales en distintos puntos de la reproducción, entonces se deben usar múltiples Creatives. 13. Los medios deben elegir diferentes niveles de soporte VAST en sus players de vídeo. Por ejemplo, un medio puede elegir permitir el seguimiento con un ad server secundario, en cuyo caso sólo la sección tracking del XML sería importante. 14. Por motivos de latencia o infraestructura, algunos medios pueden no querer permitir que los ad servers secundarios sirvan los vídeos por sí mismos. El documento XML puede ser usado en este escenario con archivos de reproducción URLs apuntando a localizaciones del servidor almacenadas en la infraestructura del editor. 15. Es necesario habilitar una alerta para que varios ad servers puedan ser informados si la publicidad no se lanzó por algún motivo. Hay que tener en cuenta que la mayoría de ad servers no tiene en cuenta, actualmente, la funcionalidad de notificaciones de soporte de este tipo, pero está incluida en futuras actualizaciones. 16. Todos los ad servers necesitan abastecer, como mínimo, de una única impresión de tracking URL. Múltiples elementos de impresión pueden aparecer en función de sus respectivas secciones. Por ejemplo, InLine Ad puede contener dos elementos secuenciales de Impression, uno para el ad server y el otro para una tercera parte afiliada con la campaña. 17. El documento XML soporta un amplio tracking si está disponible desde el Video Player. El tracking está basado en el documento de IAB Estándares de Formatos Publicitarios Interactivos; Métricas. 18. El Wrapper Ad debe incluir la URL de una respuesta VAST del Ad Server secundario. 19. El Wrapper Ad puede incluir de manera separada Companion y NonLinear Creatives servidos tanto desde el ad server primario como del secundario. Por ejemplo, en lugar de poner todos los ajustes en una única respuesta VAST, un ad server secundario puede proveer un ad tag para una respuesta InLine para el vídeo publicitario lineal, y un ad tag separado apuntando a un banner publicitario estándar para un Companion. 20. El Wrapper Ad puede incluir varios Tracking URLs para permitir Companions servidos desde una respuesta InLine pero con seguimiento separado desde la Impression. También puede incluir elementos de Tracking separados para vistas o eventos lineales o no lineales. El servidor que provee la respuesta Wrapper Ad puede no conocer, exactamente, qué elementos creativos van a ser servidos para descarga en publicidades InLine; en este caso, el Wrapper debería incluir marcadores de posición para un máximo ajuste de Creatives que podrían ser reproducidos en el player de vídeo. 10 21. Se espera un sencillo clic a lo largo de la publicidad, pero muchos de los llamados click tracking URLs (CustomClick) pueden ser abastecidos para permitir una adaptación para cada medio. En definitiva, se pueden habilitar distintas URLs para hacer un seguimiento al clic (ClickTracking) y para que la página de destino sea abierta mediante un clic (ClickTrough) 22. Se pueden facilitar diferentes URLs para un único vídeo publicitario dentro de una sección de fichero de vídeo devuelta, pero se asume que todas las versiones del vídeo representan la misma unidad creativa con la misma duración, Ad-ID (código ISCI), etc. El ancho de banda es indicado por el fichero de vídeo usando el atributo bitrate. Dependerá de los players de vídeo el determinar qué fichero y con qué bitrate es apropiado para sus usuarios. Las imágenes publicitarias o anuncios interactivos pueden ser incluidos en la sección MediaFiles con los apropiados tipos Mime. Si se desean múltiples conceptos lineales (como pre-roll y post-roll) entonces se pueden usar múltiples Creatives. 23. Los elementos publicitarios pueden especificar un elemento AdParameters para tener los parámetros especificados pasados a ellos desde el player. Por ejemplo, un no lineal puede requerir que la información del tracking sea pasada en tiempo de reproducción. 24. El elemento apiFramework indica el método mediante el cual el player de vídeo puede comunicarse con varios activos publicitarios. Valores comunes para este elemento son “VPAID” y “clickTag”. Para soluciones ad hoc se pueden usar otros valores. 25. Elementos de extensión son adecuados para la personalización o características específicas del ad server (por ejemplo, geo data, indentificadores únicos). 26. Es preferible que en la entrega del ad server, el Wrapper Ad rompa con la caché en el parámetro AdTagURL mediante la inclusión de un número de serie en la URL en el momento de la entrega. 27. La mayoría de los ad servers secundarios soporta la inclusión de un parámetro en sus ad tags (generalmente “click=”) que redireccionará todos los clics a través del ad server primario para habilitar el conteo. En el caso de VAST, el valor de este parámetro (que es ajustado por el ad server primario) debería ser emplazado en los elementos VideoClicks-ClicksTracking del elemento de la respuesta Wrapper Ad como interpretación de los tags de publicidad contenidos en la respuesta InLine. 28. Todas las URLs deberían ser envueltas en bloques CDATA. 11 Resumen XML para la respuesta del Ad server VAST ELEMENTO VAST ATRIBUTOS VALORES Nodo root REQUERIDO Sí Versión String Sí Ad Id String Sí InLine Ninguno Ninguno No AdSystem Ninguna String Sí Version String No AdTittle Ninguno String Sí Description Ninguno String No Survey Ninguno String No Error Ninguno URL No Impression Ninguno URL Sí Creatives Ninguno Ninguno Sí Id String No Secuencia Integer No AdID String No Creative 12 NOTAS La actual versión es 2.0 Elemento de alto nivel, envuelve a cada anuncio en la respuesta. Elemento de segundo nivel que incluye todos los datos publicitarios para una única publicidad. Indica el ad server fuente. Versión interna usada por el sistema publicitario. Nombre común del anuncio Descripción extensa del anuncio URL de petición para reconocer al proveedor URL para obtener si la publicidad no se reproduce debido a un error URL para el track de impresión Contenedor para uno o más elementos Creative Abarca cada elemento creativo Identificador opcional El orden preferente en el que múltiples Creatives deberían ser mostrados. Ad-ID para la creatividad (anteriormente ISCI) ELEMENTO Linear Duration ATRIBUTOS VALORES REQUERIDO NOTAS No Ninguno Time Sí TrackingEvents Duración, en formato de tiempo estándar hh:mm:ss No Tracking URL Event AdParameters No URL para el track de varios eventos durante la reproducción CreativeView, start, midpoint, firstQuartile, thirdQuartile, complete, mute, unmute, pause, Sí rewind, resume, fullscreen, expand, collapse, acceptInvitation, close El nombre del evento a seguir para el elemento Linear. El CreativeView debería siempre ser requerido cuando está presente. String Datos a ser pasados en el vídeo publicitario. No VideoClicks ClickThrough Ninguno URL No ClickTracking URL No CustomClick URL No String No Id 13 URL a abrir como página de destino cuando el usuario hace clic en el vídeo. URL a pedir para propósitos de tracking cuando el usuario hace clic en el vídeo. URLs a pedir en eventos personalizados tales como conflictos de vídeo Identificador opcional ELEMENTO MediaFiles ATRIBUTOS VALORES REQUERIDO NOTAS Sí MediaFile URL Sí Id String No Delivery Streaming, progresSí sive Type String Sí Bitrate Integer No Width Integer Yes Height Integer Yes Scalable Boolean No MaintainAspectRaBoolean tio No ApiFramework No String 14 Situación del archivo lineal Identificador opcional Método de entrega de la publicidad Tipo MIME. Los populares tipos MIME incluyen, no estando limitados a “video/x-ms-wmv” para windows media, “video/x-flv” para Flash Video. Bitrate del vídeo codificado en Kbps Dimensiones del vídeo en píxeles. Dimensiones del vídeo en píxeles. Si permite escalar la imagen Si la publicidad debe mantener su aspecto en relación a cuando sea escalada. El apiFramework define el método a emplear para establecer comunicación si el MediaFile es interactivo. ELEMENTO CompanionAds ATRIBUTOS VALORES Companion No Id String No Width Integer Sí Height Integer Sí ExpandedWidth Integer No expandedHeight Integer No ApiFramework String No URL No CreativeType String Sí Ninguno URL No StaticResource IframeResource REQUERIDO 15 NOTAS Cualquier número de complementos en la dimensión deseada, en píxeles. Identificador opcional Dimensiones del complemento en píxeles. Dimensiones del complemento en píxeles. Dimensiones en píxeles de la publicidad del complemento expansible cuando está expandida. Dimensiones en píxeles de la publicidad del complemento expansible cuando está expandida. El apiFramework define el método a emplear para establecer comunicación con el complemento. URL a un archivo estático, como una imagen o un archivo SWF. Tipo Mime de recurso estático URL fuente del Iframe que muestra el elemento del complemento. ELEMENTO HTMLResource ATRIBUTOS Ninguno VALORES CDATA REQUERIDO No TrackingEvents No Tracking URL No CreativeView Sí CompanionClicNinguno kTrough URL No Texto alternativo Cadena No Cadena No Event Adparametros NOTAS HTML para mostrar el elemento del complemento. Ninguno 16 URL para hacer seguimiento de la vista del complemento. El CreativeView debería siempre ser pedido en el momento. Para Complementos, CreativeView es el único evento soportado. URL a abrir como página de destino cuando el usuario hace clic en el complemento. Texto alternativo que se mostrará cuando el companion se representa en un entorno HTML Los datos deberán ser introducidos en los anuncios companion ELEMENTO Anuncios no lineales ATRIBUTOS VALORES No lineales REQUERIDO No Id Cadena No Ancho Entero Si Alto Entero Si Ancho expandido Entero No Alto expandido Entero No Escalable Boolean No Mantener el ApecBoolean tRatio No Duracion sugerida Tiempo No Cadena No URI No Cadena Si minima ApiFramework Recursos estaticos Tipo de creatividad 17 NOTAS Cualquier numero no-linear activos en las dimensiones deseadas en pixel. Identificador opcional. Dimensiones del pixel de companion Dimensiones del pixel de companion Dimensiones en pixeles cuando el anuncio esta expandido. Dimensiones en pixeles cuando el anuncio esta expandido. Es aceptable para escalar la imagen El anuncio debe mantener el aspect ratio cuando se amplía. La duración sugerida de anuncios no lineales, se expresa hh:mm:ss, esperando a que finalice el anuncio El ApiFramework define el método de comunicación con los elementos/ anuncios no lineales URI es un tipo de archivo estático, como una imagen o como un archivo SWF Mime es un recurso estático. ELEMENTO ATRIBUTOS VALORES Recursos Iframe Ninguno URI Recursos Html Ninguno CDATA REQUERIDO No Tracking events NOTAS URI es el origen de un Iframe para mostrar elementos no lineales El html se utiliza para no mostrar el elemento no lineal No Tracking URI Event No Ver creativos, comienzo, punto medio, primer cuartil, tercer cuartil, completado, silencio, desactivar silencio, pause, rebobinar, reanudar, pantalla completa, colapso, aceptar invitacion, cerrar. URI de seguimiento de varios eventos durante la reproducción. El nombre del evento para el seguimiento, Para ver la creatividad siempre hay que solicitarla. ClickThrough no liNinguno neal URI No Parametros Ad Cadena No URI se utiliza cuando para abrir la pagina de destino cuando el usuario hace clic Los datos hay que introducirlos en el video del anuncio Extensiones Extension Tipo Alguno No Wrapper Ninguno Ninguno No AdSystem VASTAdTagURI Cualquier XML valido puede ser incluido en las extensiones del nodo. Elemento de segundo nivel que depende de Igual que en la sección anterior en línea. Ninguno URI Si 18 URI de tags inferiores del anuncio. Adserver secundario ELEMENTO Error Impresión Creativos Creativo Lineal TrackingEvents VideoClicks CompanionAds Companion ATRIBUTOS VALORES Igual que en la sección anterior en línea. Igual que en la sección anterior en línea. Igual que en la sección anterior en línea. Igual que en la sección anterior en línea. Igual que en la sección anterior en línea. Igual que en la sección anterior en línea. Igual que en la sección anterior en línea. Igual que en la sección anterior en línea. Igual que en la sección anterior en línea Anuncios no linea- Igual que en la sección anterior en línea. les Igual que en la sección anterior en línea. TrackingEvents No lineal Extensiones Igual que en la sección anterior en línea. Igual que en la sección anterior en línea. 19 REQUERIDO NOTAS CLIC TRACKING El componente vídeo solo permite un único click through URI (Uniform Resource Identifier) primario con click throughs adicionales y opcionales para ellos. De esta manera, cada ad server secundario puede proveer su propio URI para el clic tracking, y estos URIs pueden ser pedidos por el player como cualquier otro tracking URI. La publicidad tipo companion y Non Linear tiene un parámetro click through URI opcional. El que esto sea necesario depende del tipo de publicidad companion de la que se trate. Por ejemplo, una imagen companion, generalmente, requerirá un click through, ya que estará escrito en la página por el editor. Un companion basado en un script HTML, generalmente, incluirá su propio click through cuando esté en la página. Es importante que los vídeo players que den soporte para VAST tengan en cuenta estas diferencias, para poder evitar el no registro de clics o el no permitir que un elemento sea clicable. En la manera de servir anuncios estándar los editores contabilizan clics incluyendo un redirect URI como un parámetro extra en el tag del ad server secundario. De todos modos como el tag companion en el vídeo está dentro del documento XML, esta inclusión debe de ser dinámica cuando se haga el análisis (time of parsing). Para que el vídeo player reconozca en qué parte del tag companion tienen que incluir la cadena de clic, se recomienda añadir un clic de prueba en los URIs. USANDO EXTENSIONES La respuesta de VAST (Video Ad Serving Template) permite cualquier XML válido dentro de los elementos de extensión. El uso de las extensiones requerirá, necesariamente, de coordinación online entre el emisor y receptor VAST. Para simplificar los usos esperados sugerimos alguna nomenclatura para el tipo de atributos de los elementos de extensión. Tipos de elementos de extensión Adserver Tracking a medida Valor Uso Cualquier información específica del ad server VAST Elementos de tracking a medida Los datos sobre el valor económico o de prioridad relativa de los anuncios 20 APÉNDICE A: RECOMENDACIÓN DE FORMATO DE TAG PUBLICITARIO Para minimizar el tamaño de la respuesta XML de los ad servers y reducir la posibilidad de que los vídeos sean devueltos al incumplir las especificaciones del editor, se recomienda que los ad servers implementen ciertos parámetros predefinidos en sus tags. La utilización de valores comunes entre los tags permitirá a los servidores primarios y a los reproductores de vídeo simplificar y automatizar las ejecuciones. Es preferible que los ad servers devuelvan el XML y que incluyan información relevante a la llamada. De todas formas, no hay ningún requisito acerca de qué información ajena es preciso eliminar. Por ejemplo, si un vídeo player devuelve un video flash, la respuesta puede incluir nodos tanto para video flash o wmv. Algunos servidores pueden no tener la capacidad de responder de forma dinámica a estos parámetros. • Los parámetros recomendados se muestran en el cuadro de debajo. • Parámetros abreviados para minimizar la extensión del URI • Los parámetros son sensibles a mayúsculas y minúsculas Se pueden asignar valores múltiples, separados por comas, a un parámetro (e.g. VMaxd= 15,30). Los valores múltiples se tienen que tratar como una petición en la que cualquiera de los valores indicados es aceptable. Parámetros Vmaxd Valores aceptados Cualquier valor entero VPI WMV,FLV, RA VHt Cualquier valor entero VWd Cualquier valor entero VBw Cualquier valor entero Vstrm 0o1 21 Notas Duración máxima aceptada del vídeo, en segundos Se acepta recuadro de player. Estos valores no reflejan una extensión de fichero vídeo específica, sino que más bien son abreviaciones de los tres tipos de player que soporta. Según se vaya extendiendo o aplicando el documento VAST a otra clase de players adicionales es posible que se añadan abreviaciones adicionales. Altura del vídeo esperada, en píxeles Ancho del vídeo esperada, en píxeles Ancho de banda máximo de vídeo, en bits por segundo 0 para progresivo, 1 para streaming A continuación se muestran ejemplos de un ad server ficticio. La sintaxis real de estas solicitudes es probable que difiera según los anuncios. Ejemplo de tag http://ad.server.com/site/content?random=1234 http://ad.server.com/site/ content?Vmaxd=30;random=1234 http://ad.server.com/site/content?VMaxd=30;V Pl=WMP,FLV;random=1234 Explicación Tag de base con un número al azar insertado. Este tag devolverá cualquier vídeo a través del ad sever sin tener en cuenta lo que el vídeo player espera. La duración del vídeo esta especificada en 30 seg y el vídeo player espera que el ad sever devuelva un documento xml especificando un spot de 30 segundos. Como el player y el ancho de banda el ad server secundario puede responder con anuncios que respondan a cualquier criterio. Además de pedir un spot de 30 segundos el vídeo player indica que quiere o bien un video xml compatible con un player wmv o un video xml compatible con flash Para realizar comentarios o sugerencias acerca del presente documento pueden dirigirse a comunicacion@iabspain.net 22
