Explicación de los pares clave-valor (KVP) de PubGuru

Esta publicación se actualizó por última vez el 21 de marzo de 2022

En MonetizeMore, utilizamos numerosos pares clave-valor (KVP) para transmitir información para la orientación y el seguimiento en la pila de anuncios. Esto es lo que significa cada KVP:

• m2_bidder : código de postor para el ganador de la subasta de header bidding para esa impresión
• m2_pb : valor de oferta superior del ganador de la subasta de header bidding para esa impresión. PubGuru admite moneda internacional, por lo que la moneda es la que el editor esté usando en DFP.
• m2_size : tamaño de la creatividad del ganador de la subasta de header bidding para esa impresión.
• m2_config : representa la versión del código HB, así como el nombre de configuración. Esto nos permite calcular el rendimiento de diferentes versiones de nuestro código HB.
• m2_bidder_list : por un pequeño porcentaje de páginas vistas, eliminamos a un postor de la subasta. Esto nos permite ver el aumento causado por cada postor. Cada carácter de esta cadena corresponde a un postor. Hemos usado esto para encontrar postores que simplemente estaban reemplazando a otros, o ralentizando la subasta hasta el punto de reducir el RPM de la página.
• test1, test10, test50, test90 : periódicamente, los editores quieren probar que las líneas de pedido sean elegibles solo en ciertas páginas vistas. Para cada uno de estos, tienen un valor predeterminado de "0". En el 1 % de las páginas vistas, test1 = 1. En el 10 % de las páginas vistas, test10 = 1. En el 50 % de las páginas vistas, test50 = 1. Y en el 90 % de las páginas vistas, test90 = 1.
• m2_traffic : aunque por defecto ejecutamos header bidding en el 100 % de las páginas vistas, podemos deshabilitar header bidding en un porcentaje de las páginas vistas. Este KVP le indica si HB se habilitó para esa impresión y para qué porcentaje de páginas vistas se habilitó. Entonces, por ejemplo, "hbon-50" significa que el 50% de las páginas vistas para ese segmento tenían HB habilitado, y para esa impresión en particular, HB estaba habilitado.
• m2_overbid : de forma predeterminada, configuramos las líneas de pedido de HB con un límite de oferta de $20 USD o el equivalente en moneda extranjera para los editores que usan otras monedas en su cuenta de DFP. Cualquier puja por encima de este tope se redondea hacia abajo al tope. Esto se debe a que DFP tiene un límite de línea de pedido de por vida y un límite de línea de pedido activa. La creación irresponsable de líneas de pedido puede destruir por completo una cuenta de DFP y, dado que las cuentas de DFP están vinculadas a las cuentas de AdX y Adsense, destruye toda la cadena de cuentas de Google de un editor. Esto es indiscutiblemente malo. Sin embargo, algunos editores tienen audiencias en las que puede ser beneficioso aumentar el límite de oferta más allá de $20. Dado que no hay un límite de KVP de por vida, usamos m2_overbid para rastrear las ofertas que superan el límite de oferta y se redondean hacia abajo. A los editores que vean ofertas no despreciables por encima de su límite se les aumentará el límite.
• m2_timeout : este es un KVP combinado que se usa para rastrear el tiempo de la subasta. El KVP toma el siguiente formato: t#e#, oa veces t#e#x#. El número que sigue a la t es el tiempo de espera base establecido para la subasta. El número que sigue a la e es el tiempo real transcurrido de la subasta. A veces, esto es más corto que el tiempo de espera (todas las ofertas se devuelven antes y DFP estaba listo para generar impresiones). A veces, esto es más largo que el tiempo de espera (normalmente porque DFP no está listo).
• m2_auction_extension : este combo KVP se usa para rastrear los parámetros que se prueban para la extensión de la subasta. Con la extensión de la subasta, verificamos la distribución y la densidad de ofertas del editor para esa página vista y, potencialmente, extendemos la subasta si es probable que sea rentable hacerlo.
• vista de página : se establece en 1 para cada nueva página vista. Para calcular la cantidad de páginas vistas en las que nuestra tecnología se ejecutó realmente, sume la cantidad total de impresiones completas y sin completar página vista = 1. Esto puede ser diferente de Google Analytics porque GA generalmente no está bloqueado con anuncios, mientras que DFP sí lo está. Ignore el número de ingresos.
• session : esto es similar al KVP de vista de página, excepto que rastrea sesiones en su lugar. Para calcular el número de sesiones en las que se ejecutó realmente nuestra tecnología, sume el número total de impresiones completas y sin completar donde session=1. Nuevamente, esto puede diferir de GA debido a adblock.
• request_uri : algunos editores desean realizar un seguimiento de los ingresos por artículo. El método más sencillo para que los editores hagan esto es la atribución de ingresos request_uri. Esto es todo después del nombre de dominio. Sin embargo, es importante tener en cuenta que los KVP tienen un límite de 40 caracteres, por lo que los editores con URL largas pueden truncar sus valores de request_uri.
• session_ depth : representa el número de páginas vistas en la sesión del usuario. Algunos editores solo desean habilitar ciertos socios de demanda en páginas vistas posteriores en la sesión.
• a9 : PubGuru admite la carga local de la tecnología de ofertas de encabezado de Amazon A9. A9 no se maneja dentro de nuestro envoltorio, pero sincronizamos los dos tiempos de espera entre HB y A9 para que ninguno pueda finalizar la subasta antes de tiempo. En este KVP, rastreamos el estado de A9 en el momento en que se dispara la impresión.
• google : Google, como empresa de publicidad, requiere que el contenido del editor sea seguro para la marca y, en general, apto para familias. Para dar cabida a esto, tenemos un sistema de advertencia que busca e identifica contenido controvertido. El editor puede configurar google=0, google=no o google=off para inhabilitar todas las líneas de pedido de Google para esa impresión.
• envoltorio : normalmente se usa cuando un editor ha configurado una prueba 50/50 entre PubGuru y otro envoltorio. Siempre que se establezca en 50%, uno puede simplemente comparar los ingresos totales entre los dos segmentos de envoltorio para ver cuál tiene el RPM de página más alto.

KVP de atribución de ingresos

PubGuru Header Bidding también admite la atribución de beneficios. Esto se hace a través de UTM, y cada UTM tiene un KVP correspondiente: utm_source , utm_campaign , utm_content , utm_term , utm_medium . Dado que DFP no admite informes sobre varios KVP, también admitimos KVP combinados:

• utm_source_campaign : fuente y campaña separadas por dos puntos
• utm_scm : fuente, campaña y medio, separados por dos puntos

KVP de terceros

Algunos de nuestros socios publicitarios también agregan KVP en la pila de anuncios. Éstas incluyen:

• amznbid : el hash de oferta para Amazon A9.
• oxb, ox160x600 , ox300x250 , ox300x600 , ox320x50 , ox728x90 y similares: algunas implementaciones del licitador de OpenX han utilizado estos KVP.