Testar e lançar o aplicativo

Quando o aplicativo estiver concluído e você o tiver testado internamente, ele precisará passar por uma série de testes padronizados em que o representante da sua conta do Google enviará solicitações de teste para seus servidores. Quando o aplicativo passar nesses testes, ele estará qualificado para lançamento. Os tópicos a seguir explicam como funciona o processo de teste e lançamento.

Como testar com o tráfego do Google

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

  • Informações de contato da engenharia. Se o teste não for concluído como esperado e houver problemas de engenharia a serem resolvidos, usaremos esses dados de contato para interagir diretamente com sua equipe.
  • O URL com SSL ativado que responde às solicitações de RTB.
  • O URL com SSL do servidor de correspondência de código de cookie, se você tiver optado por usar essa funcionalidade.
  • O local físico (estado, país) dos seus servidores de RTB, para otimizar a comunicação com os servidores do Google.
  • O QPS máximo (consultas por segundo) que você quer oferecer em cada local físico após o término do teste.
  • Data em que seus servidores de correspondência de código de cookie / RTB estão ativos para testes. O Google vai enviar solicitações de RTB para seus servidores nessa data ou logo depois dela.
  • Latência estimada que seus servidores vão usar para processar solicitações de RTB.
  • Chaves PGP para informações de descriptografia de preço de envio.
  • Confirme se a segmentação antecipada está configurada na interface de segmentação antecipada.

Entre em contato com seu representante do Authorized Buyers para fazer mudanças nessas informações a qualquer momento durante o processo de teste.

O teste vai envolver várias etapas com tráfego sintético para verificar latências de diferentes locais. O Google também vai fazer alguns testes básicos para renderizar anúncios e para o acompanhamento de cliques corretamente. A maior parte disso precisa ser feita durante seus próprios testes e durante a certificação. Também vamos pedir que você confirme se consegue receber e decodificar notificações e cliques de preço 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 Real-time Bidder é de 80 a 1.000 ms, medido desde o 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 BidRequest.tmax para saber o valor exato.

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

Um bidder que tiver taxas de tempo limite altas temporariamente devido a eventos de rede ou outros problemas será limitado automaticamente. Essa limitação vai reduzir ou aumentar automaticamente o tráfego em um período de alguns minutos. Se o tráfego for limitado com frequência por um período prolongado, o Google poderá ajustar sua cota de tráfego para um nível que possa ser processado de forma mais consistente.