Práticas recomendadas para a geração de relatórios

Crie novos relatórios na interface primeiro

Os relatórios estão sujeitos a várias restrições e requisitos relacionados a tipos, filtros, dimensões e métricas. Essas limitações são aplicadas na API, retornando um erro HTTP 400. Para evitar erros ao criar relatórios, recomendamos que você crie novos relatórios na interface do Display & Video 360.

Depois de criar o relatório, clique no recurso"Testar esta API" na página de documentos de referência para executar um queries.get do recurso Query. Você pode usar o JSON retornado para criar relatórios futuros.

Usar métricas e filtros específicos para o tipo de relatório

Alguns valores de métrica e filtro são específicos para determinados tipos de relatórios. Além de criar seus relatórios na interface primeiro, você também pode identificar as métricas e os filtros que pertencem a determinados valores de ReportType pelo valor da API Bid Manager.

Confira algumas maneiras de identificar valores de filtro e métrica relevantes da API do Bid Manager. Esta tabela não é uma lista completa de filtros e métricas que podem ser usados nesses tipos de relatórios. Nem todos os valores podem ser usados juntos em um único relatório.

ReportType Filtros e métricas relevantes
YOUTUBE
  • Filtros com o prefixo FILTER_TRUEVIEW.
  • Métricas com o prefixo METRIC_TRUEVIEW.
GRP
  • Métricas com o prefixo METRIC_GRP.
YOUTUBE_PROGRAMMATIC_GUARANTEED
  • Filtros com o prefixo FILTER_YOUTUBE_PROGRAMMATIC_GUARANTEED.
  • Métricas com o prefixo METRIC_PROGRAMMATIC_GUARANTEED.
REACH
  • Métricas com o prefixo METRIC_UNIQUE_REACH.
UNIQUE_REACH_AUDIENCE
  • Métricas com o prefixo METRIC_UNIQUE_REACH.

Salvar e reutilizar relatórios

Recomendamos que você crie e salve relatórios para consultas que você faz regularmente, porque inserir e excluir o mesmo relatório várias vezes desperdiça recursos. Usar os valores definidos de Range, como PREVIOUS_DAY ou LAST_7_DAYS, no campo dataRange facilita a reutilização dos relatórios.

Programar relatórios

Relatórios ad hoc ou únicos podem desperdiçar recursos porque são executados de forma individual e podem ser executados em um conjunto de dados incompleto. Com os relatórios programados, é possível aproveitar mais os recursos disponíveis, porque eles são gerados em massa. Além disso, há a garantia de que eles só vão ser gerados após o processamento dos dados do dia anterior. Consulte os campos de programação disponíveis para mais detalhes.

Combinar relatórios semelhantes

Se você gera relatórios com métricas e períodos idênticos para diferentes anunciantes ou parceiros, recomendamos que você combine os relatórios para otimizar o volume deles.

É possível combinar relatórios semelhantes anexando os filtros de todos os relatórios e adicionando todos os tipos de filtro como dimensões. Após a geração, você pode dividir as linhas do relatório resultante de acordo com os valores do filtro original para produzir os relatórios originais.

Usar as cotas de relatórios

O uso responsável dos relatórios do Display & Video 360 é aplicado com as seguintes cotas de uso em todo o produto:

Execuções de relatórios ad hoc por dia

Limita o número de relatórios ad hoc que um usuário pode gerar em um período de 24 horas. Para ficar abaixo dessa cota:

Relatórios programados ativos

Limita o número de relatórios que um usuário pode ter ativamente programados em um determinado momento. Para ficar abaixo dessa cota:

Relatórios simultâneos

Limita o número de relatórios que um usuário pode gerar ao mesmo tempo. Para ficar abaixo dessa cota:

  • Programe relatórios gerados regularmente.
  • Desative scripts de API desnecessários.
  • Monitore quando os relatórios forem concluídos por meio de pesquisa usando a lógica de espera exponencial.

Se você tiver otimizado a implementação de relatórios e ainda exceder a cota, fale com o suporte do Display & Video 360 pelo formulário de contato.

Usar espera exponencial ao pesquisar o status de relatórios

Não é possível prever quanto tempo vai levar para gerar um relatório. Isso pode variar de segundos a horas, dependendo de muitos fatores, como o período e a quantidade de dados a serem processados. Também não há correlação entre o tempo de execução do relatório e o número de linhas retornadas no relatório. Por isso, é necessário recuperar regularmente o recurso de relatório usando o método queries.reports.get e verificar se o campo metadata.status.state do recurso foi atualizado para DONE ou FAILED para determinar se a execução foi concluída. Esse processo é conhecido como "sondagem".

Embora a pesquisa seja necessária, uma implementação ineficiente pode esgotar sua cota rapidamente se uma geração de relatório demorar muito para ser concluída. Portanto, recomendamos que você use a espera exponencial para limitar as tentativas e economizar sua cota.

Espera exponencial

A espera exponencial é uma estratégia padrão de tratamento de erros para aplicativos de rede em que o cliente repete periodicamente uma solicitação ao longo de um período crescente. Usada corretamente, a espera exponencial aumenta a eficiência do uso da largura de banda, reduz o número de solicitações necessárias para conseguir uma resposta bem-sucedida e maximiza a capacidade de solicitações em ambientes simultâneos.

O fluxo para implementação da espera exponencial simples é o seguinte:

  1. Faça uma solicitação queries.reports.get para a API.
  2. Extraia o objeto de relatório. Se o campo metadata.status.state não for DONE ou FAILED, isso indica que o relatório não foi concluído e precisa continuar a sondagem.
  3. Aguarde cinco segundos + um número aleatório de milissegundos e tente novamente a solicitação.
  4. Extraia o objeto de relatório. Se o campo metadata.status.state não for DONE ou FAILED, isso indica que o relatório não foi concluído e precisa continuar a sondagem.
  5. Aguarde 10 segundos + um número aleatório de milissegundos e tente novamente a solicitação.
  6. Extraia o objeto de relatório. Se o campo metadata.status.state não for DONE ou FAILED, isso indica que o relatório não foi concluído e precisa continuar a sondagem.
  7. Aguarde 20 segundos + um número aleatório de milissegundos e tente novamente.
  8. Extraia o objeto de relatório. Se o campo metadata.status.state não for DONE ou FAILED, isso indica que o relatório não foi concluído e precisa continuar a sondagem.
  9. Aguarde 40 segundos + um número aleatório de milissegundos e tente novamente a solicitação.
  10. Extraia o objeto de relatório. Se o campo metadata.status.state não for DONE ou FAILED, isso indica que o relatório não foi concluído e precisa continuar a sondagem.
  11. Aguarde 80 segundos + um número aleatório de milissegundos e tente novamente a solicitação.
  12. Continue esse padrão até que o objeto de relatório seja atualizado ou um tempo máximo decorrido seja atingido.

Se o relatório terminar a execução e terminar em um estado DONE, será possível recuperar o arquivo de relatório gerado do Google Cloud Storage no caminho fornecido no campo metadata.googleCloudStoragePath.