Publicação de anúncios através de RFCs externas

Esta funcionalidade está em versão beta
As funcionalidades na fase beta podem não estar disponíveis na sua rede. Veja as notas de lançamento para quando esta funcionalidade ficar disponível em geral.

Este artigo explica como usar redes de fornecimento de conteúdo (RFCs) externas para fornecer conteúdo multimédia de anúncios para streams em direto através da Inserção de anúncios dinâmicos (DAI) do Google Ad Manager.

Nesta página

• Vista geral desta funcionalidade
• Como funciona
• Requisitos e configuração da RFC externa
• Estratificação hierárquica
• Configuração do Google Ad Manager
• Perguntas frequentes

Vista geral desta funcionalidade

Normalmente, os publicadores que usam a DAI do Google Ad Manager dependem da RFC de anúncios da Google para o fornecimento de anúncios. Em alternativa, esta funcionalidade permite que os publicadores usem uma RFC à sua escolha. Isto oferece várias vantagens:

• Compatibilidade com várias RFCs: use RFCs diferentes para diferentes regiões ou com base no desempenho, melhorando o alcance global e a redundância. Isto é importante para eventos em direto em grande escala.
• Desempenho melhorado: a utilização de RFCs otimizadas para localizações específicas pode resultar em tempos de carregamento de anúncios mais rápidos e numa melhor experiência do visitante.
• Fornecimento de anúncios e conteúdo unificado: a utilização da mesma RFC para conteúdo e anúncios simplifica as operações e pode melhorar o desempenho com uma única ligação SSL. Também permite que as RFCs monitorizem melhor o tráfego e ajustem o encaminhamento.

Como funciona

A configuração envolve configurar a RFC externa para usar a RFC de anúncios da Google como um servidor de origem para o conteúdo multimédia de anúncios e, potencialmente, configurar o Google Ad Manager. O fornecimento de anúncios é alcançado através do seguinte:

1. Pedido do leitor: o leitor pede o anúncio à RFC do publicador.
2. Procura da RFC: a RFC verifica a respetiva cache para o anúncio.
3. Pedido de origem: se o anúncio não estiver em cache, a RFC pede-o à RFC de anúncios da Google.
4. Fornecimento de anúncios: a RFC de anúncios da Google publica o anúncio, que é colocado em cache pela RFC do publicador e publicado para o leitor.

Veja um fluxo de trabalho detalhado

Passos do fluxo ordenados

1. O leitor de vídeo pede o manifesto à DAI
2. A DAI devolve o manifesto com URLs (que apontam para a DAI)
3. URL do segmento de pedidos do leitor de vídeo
4. A DAI devolve o redirecionamento HTTP 302 para a RFC externa do publicador
5. A RFC do publicador pede o URL do segmento de anúncios (após o redirecionamento da DAI)
6. A RFC do publicador verifica a cache

Se houver uma cache em falta:

7. A RFC do publicador pede o segmento de anúncios ao servidor de origem da Google
8. O servidor de origem da Google devolve um redirecionamento HTTP 302 para o nó da RFC da Google ideal
9. A RFC do publicador pede o segmento de anúncios ao nó da RFC da Google (após o redirecionamento de origem da Google)
10. O nó da RFC da Google devolve dados do segmento de anúncios à RFC do publicador
11. A RFC do publicador armazena o segmento de anúncios em cache
12. A RFC do publicador devolve os dados de segmentos de anúncios ao leitor de vídeo

Se houver um resultado da cache quando a RFC do publicador verifica a cache, os dados do segmento de anúncios são devolvidos ao leitor de vídeo.

Requisitos e configuração da RFC externa

A RFC externa tem de:

• Ser compatível com redirecionamentos HTTP (302s) 
  Nota: se a RFC externa não for compatível com redirecionamentos 302, considere encadear uma camada de RFC adicional sobreposta. Saiba mais sobre a estratificação hierárquica.
• Respeitar os cabeçalhos de controlo de cache
  • O servidor de origem da Google redirector.googlevideo.com devolve um cabeçalho de controlo de cache com uma diretiva privada.

    Exemplo

    Não definido

    Cache-Control: private, max-age=85908

  • A configuração da RFC deve ignorar a diretiva "private", mas respeitar max-age.

  • Para configurações da Akamai, desative a definição "honor private".

• Permitir chaves de cache configuráveis com base em componentes de URL
• NÃO coloque em cache respostas que não sejam HTTP 200.

A RFC externa tem de ser configurada para pedir o conteúdo multimédia de anúncios a redirector.googlevideo.com (RFC de anúncios da Google) como o servidor de origem. Deve consultar a documentação da sua RFC aceder a instruções específicas. A chave da cache deve ser configurada como o caminho de URL completo, excluindo qualquer prefixo de caminho especificado pela DAI (por exemplo, o valor do parâmetro dai-aup). Os parâmetros de consulta têm de ser ignorados para a colocação em cache.

Estratificação hierárquica

As RFCs podem ser encadeadas hierarquicamente para permitir o processamento de redirecionamentos HTTP (302). Os 302s devolvidos pelo servidor de origem da Google podem ser resolvidos através da "união de 302s" (também conhecida como "seguimento de redirecionamentos") por uma RFC externa compatível com HTTP 302s, como a Akamai ou a RFC de multimédia da Google.

• Configure uma RFC externa que seja compatível com HTTP 302s, como a Akamai ou a RFC de multimédia da Google, com o servidor de origem redirector.googlevideo.com.
• Configure a RFC adicional com o servidor de origem a apontar para a sua RFC externa compatível com HTTP 302s.

Com esta estratificação hierárquica, os redirecionamentos HTTP podem ser resolvidos numa resposta de segmento de anúncio ou de faixa para todas as RFCs que ainda não sejam compatíveis com o processamento de 302.

Configuração do Google Ad Manager

Importante: valide a sua configuração antes de publicar

Ao usar esta funcionalidade, deve ter o máximo cuidado ao definir configurações de RFCs externas e transmitir os valores corretos para o parâmetro de consulta dai-aup. O produto DAI não consegue identificar erros na configuração ou no parâmetro de consulta. Uma configuração ou valores incorretos resultam numa reprodução danificada e num potencial impacto na receita.

Recomendamos que reveja atentamente as suas configurações da RFC e realize testes de reprodução abrangentes antes de implementar esta funcionalidade nos seus eventos de stream em direto. Recomendamos que implemente estas funcionalidades de forma incremental, certificando-se de que a reprodução não é interrompida e que os pings de acompanhamento estão a chegar corretamente aos servidores de anúncios.

Existem 2 abordagens para a integração da RFC na DAI do Google Ad Manager, que usam parâmetros de consulta diferentes durante a criação da stream: dai-ad-dlid ou dai-aup. Pode saber mais acerca destes parâmetros aqui ou decidir que parâmetro usar.

Use um ID da RFC dedicado por stream (dai-ad-dlid)

Com esta abordagem, é associada uma RFC específica e pré-configurada a uma stream em direto no Google Ad Manager. A RFC é identificada por um ID exclusivo definido durante a configuração da RFC no Google Ad Manager. Este ID é transmitido como o parâmetro dai-ad-dlid durante a criação da stream.

A utilização do parâmetro dai-ad-dlid requer que crie configurações da RFC com detalhes como o nome do anfitrião para cada RFC externa.

Vantagens da utilização do parâmetro dai-ad-dlid	Limitações
Controlo detalhado: permite usar diferentes RFCs para diferentes streams. Criação de streams simplificada: só é necessário o ID da RFC após a configuração inicial da RFC no Google Ad Manager. Potencial para configuração da RFC predefinida: pode ser definida uma RFC de fornecimento de anúncios predefinida ao nível do evento de stream em direto.	Mais configuração: requer configuração prévia no Google Ad Manager. Menos flexível: a alteração da RFC requer a modificação da configuração da stream.

Use um prefixo de URL arbitrário (dai-aup)

Atualmente, o dai-aup é a única opção para o fornecimento de anúncios de RFCs externas quando usa a publicação de agrupamentos. Se usar a DAI de serviço completo, este parâmetro tem precedência sobre o parâmetro dai-ad-dlid se ambos estiverem presentes.

Com esta abordagem, é usado um prefixo de URL arbitrário, que aponta para a RFC externa, para criar URLs de segmentos de anúncios. Este prefixo é transmitido como o parâmetro dai-aup durante a criação da stream. A DAI da Google substitui o URL da RFC habitual por um URL que usa este prefixo, que tem de:

• Ter o formato "https://domain.com/path/", em que "/path/" é opcional
• Ser um prefixo de URL absoluto (os URLs relativos não são compatíveis)

Exemplo

dai-aup=https://domain.com/path-c1/path-c2

URL da RFC da Google:
https://redirector.googlevideo.com/videoplayback/foo?bar=baz

URL do segmento de anúncios resultante:
https://domain.com/path-c1/path-c2/videoplayback/foo?bar=baz

Não é necessária nenhuma configuração específica do Google Ad Manager.

Vantagens da utilização do parâmetro dai-aup	Limitações
Flexibilidade: as RFCs podem ser alteradas sem modificar as configurações da stream (basta alterar o prefixo do URL). Configuração mais simples: não é necessário pré-configurar as RFCs no Google Ad Manager.	Controlo menos detalhado: menos controlo sobre a RFC usada para cada stream. Potencial complexidade da gestão de URLs: é necessária uma gestão cuidadosa dos prefixos de URLs quando se usam várias RFCs de forma dinâmica.

Decida que parâmetro usar

A melhor abordagem depende das suas necessidades e da estratégia de gestão da RFC. Considere as contrapartidas entre o controlo detalhado e a flexibilidade. Em geral, recomendamos que:

Escolha o parâmetro dai-ad-dlid se:

• For necessário um controlo detalhado sobre a seleção da RFC por stream.
• For preferível uma criação de streams mais simples após a configuração inicial.
• Quiser usufruir da capacidade de configurar RFCs predefinidas no Google Ad Manager.

Escolha o parâmetro dai-aup se:

• For necessária a máxima flexibilidade para alterar as RFCs dinamicamente.
• Devem ser evitados passos de configuração adicionais no Google Ad Manager.

Perguntas frequentes

É um pré-requisito que as redes de fornecimento de conteúdo (RFCs) para segmentos de conteúdo e de anúncios sejam idênticas para que esta configuração funcione corretamente?

Embora não seja um pré-requisito rigoroso, a utilização da mesma RFC para segmentos de conteúdo e de anúncios oferece vantagens significativas em termos de desempenho. Veja o motivo:

• Início mais rápido dos anúncios: uma ligação existente à RFC para o conteúdo principal elimina a necessidade de uma nova procura de DNS e de um handshake de ligação quando começa uma pausa para anúncios, o que resulta numa reprodução de anúncios mais rápida.
• Estabilidade melhorada: o balanceamento de carga estabelecido da RFC para a stream de conteúdo pode gerir facilmente os pedidos de anúncios. Isto evita um aumento súbito do tráfego que, de outra forma, poderia sobrecarregar os servidores, mitigando o efeito de "thundering herd".