Pares de valor-chave PubGuru (KVPs) explicados

Esta postagem foi atualizada pela última vez em 21 de março de 2022

Na MonetizeMore, usamos vários pares chave-valor (KVPs) para passar informações para segmentação e rastreamento na pilha de anúncios. Veja o que cada KVP significa:

• m2_bidder : código do licitante para o vencedor do leilão de lances de cabeçalho para essa impressão
• m2_pb : valor do lance superior do vencedor do leilão de lances de cabeçalho para essa impressão. O PubGuru oferece suporte a moedas internacionais, então a moeda é aquela que o editor estiver usando no DFP.
• m2_size : tamanho do criativo do vencedor para o leilão de lances de cabeçalho para essa impressão.
• m2_config : representa a versão do código HB, bem como o nome da configuração. Isso nos permite calcular o desempenho de diferentes versões do nosso código HB.
• m2_bidder_list : para uma pequena porcentagem de exibições de página, retiramos um licitante do leilão. Isso nos permite ver o aumento causado por cada licitante. Cada caractere nesta string corresponde a um licitante. Usamos isso para encontrar licitantes que estavam apenas preenchendo os outros ou retardando o leilão a ponto de diminuir o RPM da página.
• test1, test10, test50, test90 : periodicamente, os editores desejam testar itens de linha qualificados apenas em determinadas exibições de página. Para cada um deles, o valor padrão é "0". Em 1% das exibições de página, test1 = 1. Em 10% das exibições de página, test10 = 1. Em 50% das exibições de página, test50 = 1. E em 90% das exibições de página, test90 = 1.
• m2_traffic : embora tenhamos como padrão executar lances de cabeçalho em 100% das exibições de página, podemos desativar lances de cabeçalho em uma porcentagem de exibições de página. Este KVP informa se o HB foi ativado para essa impressão e para qual porcentagem de exibições de página ele foi ativado. Assim, por exemplo, “hbon-50” significa que 50% das exibições de página desse segmento tinham o HB ativado e, para essa impressão específica, o HB estava ativado.
• m2_overbid : por padrão, configuramos itens de linha HB para um limite de lance de US$ 20 ou o equivalente em moeda estrangeira para editores que usam outras moedas em suas contas do DFP. Qualquer lance acima desse limite é arredondado para baixo até o limite. Isso ocorre porque o DFP tem um limite de item de linha vitalício e um limite de item de linha ativo. A criação irresponsável de itens de linha pode destruir totalmente uma conta do DFP e, como as contas do DFP estão vinculadas às contas do AdX e do Google AdSense, ela destrói toda a cadeia de contas do Google de um editor. Isso é indiscutivelmente ruim. No entanto, alguns editores têm públicos-alvo em que pode ser benéfico aumentar o limite de lance para além de US$ 20. Como não há limite vitalício de KVP, usamos m2_overbid para rastrear lances que ultrapassam o limite de lance e são arredondados para baixo. Os editores que veem lances não negligenciáveis ​​acima de seu limite terão seu limite aumentado.
• m2_timeout : este é um combo KVP usado para rastrear o tempo para o leilão. O KVP tem o seguinte formato: t#e#, ou às vezes t#e#x#. O número que segue o t é o tempo limite de base definido para o leilão. O número que segue o e é o tempo real decorrido para o leilão. Às vezes, isso é mais curto do que o tempo limite (todos os lances voltam antes e o DFP está pronto para disparar as impressões). Às vezes, isso é mais longo do que o tempo limite (geralmente porque o DFP não está pronto).
• m2_auction_extension : este KVP combinado é usado para rastrear os parâmetros que estão sendo testados para a extensão do leilão. Com a extensão de leilão, verificamos a densidade e a distribuição de lances do editor para essa visualização de página e, possivelmente, estendemos o leilão se for provável que seja lucrativo fazê-lo.
• pageview : é definido como 1 para cada nova exibição de página. Para calcular o número de exibições de página em que nossa tecnologia realmente foi executada, some o número total de impressões preenchidas e não preenchidas pageview=1. Isso pode ser diferente do Google Analytics porque o GA geralmente não é bloqueado por anúncios, enquanto o DFP é bloqueado por anúncios. Ignore o número da receita.
• sessão : é semelhante ao KVP de exibição de página, exceto que, em vez disso, rastreia as sessões. Para calcular o número de sessões em que nossa tecnologia realmente foi executada, some o número total de impressões preenchidas e não preenchidas em que sessão=1. Novamente, isso pode diferir do GA por causa do adblock.
• request_uri : alguns editores desejam rastrear a receita por artigo. O método mais fácil para os editores fazerem isso é a atribuição de receita request_uri. Isso é tudo depois do nome de domínio. É importante observar, porém, que os KVPs têm um limite de 40 caracteres, portanto, os editores com URLs longos podem ter seus valores request_uri truncados.
• session_depth : representa o número de visualizações de página na sessão do usuário. Alguns editores desejam habilitar apenas determinados parceiros de demanda em exibições de página posteriores na sessão.
• a9 : o PubGuru oferece suporte ao sideload da tecnologia de lances de cabeçalho do Amazon A9. A9 não é manipulado dentro de nosso wrapper, mas sincronizamos os dois tempos limite entre HB e A9 para que nenhum deles possa encerrar o leilão antecipadamente. Neste KVP, rastreamos o estado de A9 no momento em que a impressão é disparada.
• google : o Google, como empresa de publicidade, exige que o conteúdo do editor seja seguro para a marca e adequado para toda a família. Para acomodar isso, temos um sistema de alerta que procura e identifica conteúdos controversos. O editor pode definir google=0, google=no ou google=off para desativar todos os itens de linha do Google para essa impressão.
• wrapper : normalmente usado quando um editor configurou um teste 50/50 entre o PubGuru e outro wrapper. Contanto que seja definido como 50%, pode-se simplesmente comparar a receita total entre os dois segmentos wrapper para ver qual tem o RPM de página mais alto.

KVPs de atribuição de receita

PubGuru Header Bidding também suporta atribuição de lucro. Isso é feito por meio de UTMs, e cada UTM tem um KVP correspondente: utm_source , utm_campaign , utm_content , utm_term , utm_medium . Como o DFP não oferece suporte a relatórios sobre vários KVPs, também oferecemos suporte a KVPs combinados:

• utm_source_campaign : origem e campanha separados por dois pontos
• utm_scm : origem, campanha e meio, separados por dois pontos

KVPs de terceiros

Alguns de nossos parceiros de anúncios também adicionam KVPs na pilha de anúncios. Esses incluem:

• amznbid : o hash de lance para Amazon A9.
• oxb, ox160x600 , ox300x250 , ox300x600 , ox320x50 , ox728x90 e similares: algumas implementações do licitante do OpenX usaram esses KVPs.