Testar e lançar o aplicativo

Quando o aplicativo estiver concluído e testado internamente, ele precisará passar por um conjunto de testes padronizados em que o representante da sua conta do Google envia solicitações de teste aos 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.

Testar com o tráfego do Google

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

• Informações de contato da equipe de engenharia. Se o teste não prosseguir como esperado e houver problemas de engenharia a serem resolvidos, usaremos essas informações de contato para interagir diretamente com sua equipe.
• O URL habilitado para SSL que responde a solicitações de RTB.
• O URL ativado para SSL 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 seus servidores de RTB para otimizar a comunicação com os servidores do Google.
• O QPS (consultas por segundo) máximo que você quer veicular em cada local físico após a conclusão do teste.
• Data em que seus servidores de RTB / correspondência de código de cookie ficam ativos para teste. O Google vai enviar solicitações de RTB aos seus servidores nessa data ou logo depois.
• Latência estimada que seus servidores vão usar para processar solicitações de RTB.
• Chaves PGP para informações de descriptografia de preços de correspondência.
• Confirme se a pré-segmentação está configurada na interface de pré-segmentação.

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 envolve 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 renderizar anúncios e rastrear cliques corretamente. (A maior parte disso deve ser feita durante seus próprios testes e durante a certificação.) Também vamos pedir que você confirme que pode receber e decodificar notificações de preço vencedor e cliques. 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 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, receber impressões das costas leste e oeste dos Estados Unidos geralmente exige que você tenha 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 longo período, o Google poderá ajustar sua cota para um nível que possa ser processado de forma mais consistente.