Testar e lançar o aplicativo

Depois de concluído e testado internamente, o aplicativo precisa passar por um conjunto de testes padronizados em que o representante da sua Conta do Google envia solicitações de teste para seus servidores. Quando o aplicativo for aprovado nesses testes, ele estará qualificado para lançamento. Os tópicos a seguir explicam como funciona o processo de teste e lançamento.

Como fazer testes com o tráfego do Google

Quando estiver tudo pronto para começar os testes com o tráfego enviado pelo Google, entre em contato com o representante do Authorized Buyers. Você precisará fornecer várias informações, como as seguintes:

  • Dados de contato da engenharia. Se o teste não ocorrer conforme o esperado e houver problemas de engenharia a serem resolvidos, usaremos esses dados de contato para interagir diretamente com a equipe.
  • O URL com SSL ativado que responde a solicitações RTB.
  • O URL com SSL ativado do servidor de correspondência de código de cookie, se você optou por usar essa funcionalidade.
  • O local físico (estado, país) dos servidores RTB para otimizar a comunicação com os servidores do Google.
  • Número máximo de consultas por segundo (QPS) que você pretende veicular de cada local físico após a conclusão do teste.
  • É a data em que os servidores de RTB / correspondência de código de cookie estão ativos para teste. O Google enviará solicitações RTB para seus servidores nessa data ou logo após essa data.
  • A latência estimada que seus servidores usarão para processar solicitações RTB.
  • Chaves PGP para enviar pelo correio informações de descriptografia de preços.
  • Confirme se a pré-segmentação está configurada na interface de pré-segmentação.

Entre em contato com seu representante do Authorized Buyers para alterar essas informações a qualquer momento durante o processo de teste.

O teste envolverá várias etapas com tráfego sintético para verificar latências de diferentes locais. O Google também fará alguns testes básicos para verificar a renderização dos anúncios e o rastreamento de cliques. A maior parte desse processo deve ser feito durante seus próprios testes e durante a certificação. Também pediremos que você confirme se pode receber e decodificar notificações e cliques de preços vencedores. Depois que esses itens forem verificados, a próxima etapa será um aumento gradual do tráfego ativo ao longo de vários dias.

O requisito de latência para usar o bidder em tempo real é de 80 a 1.000 ms, medido a partir do momento em que o Google envia a chamada até o momento em que recebe uma resposta. Esse prazo depende do formato e do tipo de leilão. Verifique o campo tmax ou response_deadline_ms na solicitação de lance para saber o valor exato.

Para se qualificar para impressões processadas em um determinado local, no máximo 2% das solicitações precisam exceder esse prazo. Para receber impressões de vários locais de negociação de acordo com esses requisitos, normalmente é necessário executar servidores de lances em todas as regiões. Por exemplo, receber impressões das costas leste e oeste dos Estados Unidos geralmente exigirá que você tenha servidores de lances em execução nas costas leste e oeste.

Um bidder que tenha temporariamente taxas de tempo limite altas devido a eventos de rede ou outros problemas será limitado automaticamente. Essa limitação reduzirá ou aumentará automaticamente o tráfego ao longo de alguns minutos. Se o tráfego costuma ser limitado por um longo período, o Google pode ajustar sua cota de tráfego para um nível que possa ser tratado com mais consistência.