Transparência de lances com o objeto SupplyChain

Com o objeto SupplyChain, compradores e intermediários podem ver todas as partes que estão vendendo ou revendendo inventário de anúncios. O objeto trabalha com ads.txt / app-ads.txt e sellers.json para dar transparência ao ecossistema de anúncios.

1. O editor envia uma solicitação de lance.
2. O comprador recebe a solicitação de lance e os dados do objeto SupplyChain.
3. O comprador procura pelas identidades de todos os intermediários que revendem inventário.
4. O comprador rastreia e verifica os fornecedores autorizados a vender inventário.

O Google cria automaticamente os objetos dentro de uma solicitação do OpenRTB ou no próprio protocolo RTB, se aplicável.

Como o objeto SupplyChain funciona

O objeto SupplyChain, também conhecido como schain, faz parte de uma solicitação de lance do OpenRTB e é formado por "nós". Cada nó no objeto schain representa uma entidade específica que participa da solicitação de lance, que inclui todas as entidades envolvidas no fluxo direto de pagamento do inventário.

// Exemplo de objeto
"schain": {
    "complete": 1,
    "nodes": [{
         "asi":"google.com",
         "sid":"pub-1234567891234567", // O mesmo seller_id do editor no sellers.json
         "hp":1
    }],
    "ver":"1.0"
}

Para saber mais, leia a documentação do desenvolvedor do OpenRTB e a documentação do IAB (em inglês).

O objeto SupplyChain tem aparência diferente dependendo da forma como você trabalha com os compradores.

Editores que vendem diretamente com o Google

Para editores que vendem inventário diretamente pelo Ad Manager, pela AdMob ou pelo Google AdSense, o objeto schain contém somente um nó para "google.com" com o seller_id encontrado no sellers.json.

Editores que usam o Open Bidding

Os editores que usam o Open Bidding para trabalhar com trocas de terceiros têm dois nós no objeto schain: um para "google.com" com o seller_id encontrado no sellers.json e outro para o parceiro de rendimento da troca.

Assim como o Google cria o nó para "google.com" antes de enviar a solicitação de lance, a troca de terceiros é responsável por adicionar o próprio nó antes de encaminhar a solicitação.

Todos os intermediários que não processam pagamentos

Os intermediários que não processam pagamentos não estão no objeto SupplyChain. Isso inclui lances de cabeçalho do lado do cliente, lances de cabeçalho que não envolvem pagamentos e outras mediações.

Editores que usam o Gerenciamento de múltiplos clientes

O Gerenciamento de múltiplos clientes (GMC) permite aos editores pais gerar receita de inventários de editores filhos individualmente com o tipo de delegação "Gerenciar conta" ou em grande escala com o tipo de delegação "Gerenciar inventário".

Para parceiros do gerenciamento de conta

Para editores pais e filhos que usam o tipo Gerenciar conta, o objeto schain terá um nó com o ID de vendedor do editor filho e será marcado como completo. Para editores do tipo "Gerenciar conta", a geração de receita ocorre na conta do editor filho. O editor filho é tratado como o editor final. As informações do editor pai não são incluídas no objeto schain.

Para parceiros do gerenciamento de inventário

O objeto SupplyChain agora está marcado como concluído para editores com o tipo Gerenciar inventário do GMC. Há um nó para editores filhos do GMC e outro para editores pais do GMC, e a cadeia é marcada como concluída.

Com essa atualização, os pais "Gerenciar inventário" do GMC precisam compartilhar o ID de vendedor (SID, na sigla em inglês) dos editores filhos com o front-end ou a API do Ad Manager. 

Exemplo do objeto SupplyChain completo

Esse exemplo mostra o objeto SupplyChain marcado como completo para pais e filhos do GMC, com o Google como a troca.

"schain" : {
    "ver": "1.0",
    "complete" : 1,
    "nodes" : [

// Nó para o editor filho do GMC
        {
            "asi":"mcm-parent-example.com",  // Isso é um exemplo. Insira o domínio real do editor pai. 
            "sid":"52e41fac28963d1e058a106f", // ID do vendedor do filho no arquivo sellers.json do pai
            "hp":1,
        },

// Nó para o pai do MI do GMC
        {
            "asi":"google.com",
            "sid":"pub-1234567891234567", // MCM parent’s publisher ID within Google’s seller.json
            "hp":1,
        }
    ]
}

Perguntas frequentes

Por que os pais do GMC precisam criar um arquivo sellers.json?

Tornar as informações dos parceiros disponíveis publicamente ao permitir que elas sejam listadas no arquivo sellers.json é uma etapa importante para ajudar os compradores de anúncios a verificar esses inventários. 

Saiba mais sobre a especificação sellers.json do IAB.

Todos os meus editores filhos precisam ter um arquivo ads.txt válido?

Sim. Como parte do processo de convite do GMC, os editores filhos configuram um arquivo ads.txt para verificar a propriedade de todos os sites que são deles e que são operados por eles. 

Se o ads.txt do editor filho não incluir uma linha listando o pai do GMC como DIRECT (por exemplo, MCM-parent-example.com, Seller-ID para o filho do GMC, DIRECT), mas lista a linha do Google com o ID do editor pai (por exemplo, google.com, ID do editor pai do GMC, RESELLER, f08c47fec0942fa0), haverá algum impacto negativo na receita? A cadeia de suprimentos vai estar completa?

A cadeia de suprimentos será marcada como completa, mas os compradores talvez considerem o tráfego como "não autorizado", já que há um nó no SupplyChain em que o site não está listado como um vendedor autorizado no ads.txt. A atualização do arquivo ads.txt para incluir o pai do GMC como DIRECT (por exemplo, MCM-parent-example.com, Seller-ID para o filho do GMC, DIRECT) é uma etapa essencial para evitar esses erros.