É oficial, Prebid.org lançou Prebid 7.0!

O que há de novo em Prebid.js 7?

Desta vez, as notas de lançamento foram colocadas no site para além do Github, para que possa ver o produto final sem ter de mergulhar na forma como foi feito em https://docs.prebid.org/dev-docs/pb7 -notas.html. Os destaques incluem: a interface de objeto ORTB2 atualizada e componentes internos, a interface de referência de página atualizada e componentes internos, a concessão de permissões de gestor de armazenamento e a consolidação contínua de parâmetros adaptador.

O maior grupo de mudanças trata de módulos obsoletos; por exemplo, o módulo FLOC. As obsolescências dos módulos foram lançadas em grandes lançamentos para que os processos de construção dos editores não falhassem sem aviso quando um módulo desaparece. Seguindo este exemplo, o módulo FLOC não tem qualquer função há algum tempo, mas foi removido na versão principal para que as editoras que confiam na sua existência recebam uma notificação para alterar as suas definições. O suporte TCF1 para a gestão do consentimento também é removido.

Alguns depreifos da editora API acompanham algumas alterações realmente importantes aos componentes internos da pré-bid na versão 7. Uma delas é a remoção do suporte para o setConfig('publisherDomain'). Definir este parâmetro agora não terá efeito e nenhum licitador pode ler este campo. Foi concluída uma refacção completa da forma como os licitadores identificam a página atual e o seu referencial, com alterações feitas para cada licitador. Os licitadores devem verificar duas vezes se obtêm o que esperam, uma vez que havia alguma ambiguidade no que significa referência antes (a página em que o utilizador está ou a página anterior) em algumas opções de código adaptador. No Prebid 7, os licitadores que configuram o equivalente openRTB site.page devem ver o URL da página configurado pelo editor, o link nos metatags da página ou as informações fornecidas pelo navegador nessa ordem alternativa. Perceberam que as implementações muito díspares deste entre os licitadores tinham levado alguns concorrentes a chegar a diferentes conclusões sobre a página em que a impressão ocorre; este não deve continuar a ser o caso.

Outra grande mudança interna acompanha a remoção do setConfig('fpd'). O comité de taxonomia trabalhou arduamente para alinhar essa especificação de dados proprietária com o objeto OpenRTB e, como tal, deve agora ser especificada no seu interior. O Prebid 7 também permite que este objeto varie em leilões em casos em que a informação contextual varia para uma aplicação de uma página ou inserção de vídeo. A grande mudança que isso precisava era que o objeto OpenRTB fosse agora entregue aos módulos como parte do pedido de oferta, e os licitadores já não têm de se referir a ele com o GetConfig.

Algumas das alterações mais importantes no Prebid 7 seguem o modelo Prebid 5, no qual os parâmetros comuns do licitador só precisam de ser especificados uma vez. Os editores podem agora confiar que já não é necessário definir determinados parâmetros nas definições do licitador, incluindo (a) o indicador instl numa unidade de anúncios, (b) o parâmetro de posição, e (c) as categorias proibidas (bcats). Os licitadores devem considerar que, se aceitarem quaisquer campos OpenRTB nos seus parâmetros de configuração, também devem verificar o objeto Prebid ORTB2.js para esse campo.

Outra grande mudança concebida para permitir o cumprimento da editora e reforçar ainda mais a confiança da editora no projeto: os licitadores já não podem aceder ao armazenamento do dispositivo sem autorização explícita da editora. Muitos licitadores têm esta funcionalidade, mas a partir de Prebid.org queria ter a certeza de que as editoras estavam cientes de cada uma delas e aceitaram-na, para que possam incluí-la na sua comunicação aos leitores sobre como utilizam o armazenamento do dispositivo nos seus sites. Note-se que isto não se aplica aos módulos de ID DED e de utilizador, uma vez que a sua utilização de armazenamento é a regra, e não a exceção. Os editores que usam este tipo de módulos devem falar com o fornecedor sobre como utilizam o armazenamento se tiverem os seus próprios requisitos de divulgação para satisfazer.

Algumas outras coisas menores a mencionar: Se estiver a carregar o Prebid duas vezes na mesma página ou a utilizar uma versão muito antiga do Prebid Server, tem de consultar as notas de lançamento para obter alguns detalhes sobre as alterações comportamentais nessas áreas.

O que mais o Prebid lançou recentemente?

O Prebid lança sempre novas funcionalidades e não as guarda para um grande lançamento, a menos que se espere que quebre as definições de alguém. O módulo Cadeia de Procura é um grande exemplo disso. Têm trabalhado em coordenação com a equipa de transparência de compradores da IAB, e os editores da Prebid podem agora acumular cadeias de procura num determinado local para eles, ou os seus fornecedores de análise, para extrair informações. Prebid também tentará construir um dchain incompleto mesmo quando está desaparecido. Atualmente, a Xandr, o desenvolvedor de módulos, é a única integração conhecida que passa o dchain numa resposta de oferta, mas espera-se que cresça rapidamente, uma vez que a transparência dos compradores é uma prioridade para as editoras.

Outra mudança recente é o apoio às bibliotecas. Há muito tempo que existe uma regra do módulo que os módulos só podem importar do núcleo. As bibliotecas podem agora ser importadas, mas não farão parte da construção a menos que um módulo o exija. Isto deve ajudar a reduzir substancialmente a duplicação de códigos no âmbito do projeto.

Outra alteração, é possível incluir o código de depurg em movimento. Agora pode carregar um módulo de pré-oferta separado para depuração que não foi incluído no momento da compilação e melhorar o fluxo de trabalho depuração, incluindo a capacidade de gerar respostas de ofertas falsas de qualquer licitador. O recente lançamento do Professor Prebid já é uma ferramenta valiosa no fluxo de trabalho de operações de anúncios e a nova funcionalidade de depuração está programada para ser totalmente integrada.

O Prebid está rapidamente a tornar-se o centro onde as editoras centralizam informações sobre a identidade do leitor e os seus próprios dados. Uma API foi recentemente exposta para obter um identificador assíncrono para que os chamadores não tenham que sondar a existência de identificadores. O Prebid também divulgou a funcionalidade para passar um identificador para o GAM como um sinal GAM encriptado ou um GAM PPID (não confundir com o módulo PPID do Prebid). A Amazon APSTAG começou a ingerir informações de identidade a partir de locais pré-10. Espera-se que o padrão Prebid seja a ferramenta de publicação a partir da qual outras bibliotecas extraem para continuar com audiências definidas pelo vendedor e identificadores de transações.

O que podemos esperar em futuras versões de Prebid.js?

A Prebid está muito entusiasmada com a próxima fusão do módulo de vídeo. Promete melhorar drasticamente as partes internas do fluxo de trabalho de vídeo. Neste momento, coisas como simplesmente identificar uma proposta vencedora para marcá-la como submetida ainda são um desafio. Da mesma forma, os nativos estão a ser revistos, com algumas mudanças anunciadas que se esperam que se fundam em breve. espera-se Prebid.org reduzir consideravelmente o atrito de implementação em ambos os tipos de meios de comunicação. Alguns tipos de meios de áudio também estão a ser preparados, e está a ser discutido um suporte mais formal e padronizado para isso.

Num futuro próximo, em parceria com Sincera.io, Prebid.org planeia publicar algumas estatísticas de utilização em lançamentos recentes, para que os editores também possam ver quando uma versão menor ou um módulo particular alcançou uma forte adoção. As empresas têm vários níveis de conforto entre o inovador e o experimentado e verdadeiro, pelo Prebid.org quiser dar uma melhor orientação sobre onde estão essas linhas. Também reconhecem que a curva de adoção pode não ser a mesma para o núcleo como para um módulo, e as estatísticas de utilização de vários fornecedores ou módulos centrais darão informações extremamente úteis aos editores que selecionam os seus parceiros e componentes.

Um dos projetos mais ambiciosos do roteiro de Prebid.org de curto prazo é uma interface ORTB2 melhorada. Os editores estão agora a completar um objeto ORTB2 através do setConfig, módulos RTD ou do próprio módulo de enriquecimento de dados. Prebid.org planeia expandir consideravelmente esse modelo, com algumas propostas em cima da mesa, incluindo um módulo de licitador ORTB2 em que os pontos finais baseados em ORTB2 poderiam ser convertidos em submodulos, uma expansão espetacular do objeto ORTB2 atual exposto a bidders, e/ou funções de utilidade no núcleo Prebid que transforma o objeto de bid request atual em ORTB2. Isto teria enormes vantagens: o tamanho da construção poderia ser drasticamente reduzido se os módulos de licitação fossem muito menores. Muitos módulos de licitação duplicam consideravelmente os esforços de outros para transformar um objeto interno de pré-licitação em algo que o seu terminal pode esperar. Além disso, Prebid.org esperaria ver algumas integrações de bidders que podem ter sido intimidadas por saber que os seus recursos internos constroem integrações diretas utilizando este objeto de pedido mais pronto para ORTB2. Os módulos de licitação seriam muito mais fáceis de manter e os objetos RFQ seriam muito mais uniformes entre os bidders. Por exemplo, quando adiciona algo novo [por exemplo, dispositivo.sua, regs.ext.gpc, ou source.tid] ao objeto ORBT2 interno, todos os bidders que consomem esse objeto verão automaticamente o novo campo sem a necessidade de um pedido de puxar. Da mesma forma, uma funcionalidade de utilidade de processamento de resposta ORTB2 deve ter benefícios semelhantes para os editores.

Prebid.org também planeia continuar a ser um local de ensaio para normas propostas e tecnologias emergentes. Quer as várias propostas na Privacy Sandbox e outros esforços semelhantes sejam bem-sucedidos ou não, pode-se esperar que a Prebid.js seja onde muitas destas soluções são testadas. Por exemplo, os editores podem esperar que a Prebid.js em breve permita que os seus parceiros SSP participem em leilões da FLEDGE ou aumentem os seus pedidos de licitação com informações da API de Tópicos. Prebid.org estará pronto para permitir a rentabilização do editor em qualquer interface de navegador pop-up.

Prebid.org planeia acolher um webinar para aprofundar alguns destes tópicos no dia 27 de julho ao meio-dia EST. Fique atento para mais detalhes.

Patrick McCann, Committee Chair, Prebid.js

(*) Prebid.org Nota: Prebid.js 7, à semelhança de outros lançamentos importantes, é uma coleção de alterações "inesperadas" em que o publisher e os manutenção de módulos devem verificar as notas de lançamento para alterações comportamentais ou novos requisitos de configuração antes da atualização. Tal como as grandes versões anteriores, as correções de bugs e os compromissos do adaptador com a base de código 6.x continuarão a ser lançados durante sessenta dias. Depois disso, ainda pode fundir o código com as versões antigas numa base ad hoc, mas não haverá mais lançamentos contra a base de código 6.x. O lançamento destas grandes mudanças como um grupo foi concebido para que os editores possam contar com atualizações menores sem danificar a sua interface, e podem fazê-lo regularmente com testes menos extensos.