Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
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.
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.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[[["\u003cp\u003eOnce in-house testing is complete, applications must undergo standardized tests from Google, with the Google account representative sending test requests to the servers, in order to become eligible for release.\u003c/p\u003e\n"],["\u003cp\u003eTo initiate testing with Google traffic, you must contact your Authorized Buyers representative and provide them with key information such as engineering contact details, server URLs, server locations, maximum QPS, and PGP keys.\u003c/p\u003e\n"],["\u003cp\u003eTesting involves synthetic traffic to verify latencies and basic ad rendering, as well as receiving and decoding winning price notifications and clicks, followed by a gradual ramp-up of live traffic.\u003c/p\u003e\n"],["\u003cp\u003eThe latency requirement for Real-time Bidder is between 80 to 1000 ms, and no more than 2% of requests should exceed this deadline to qualify for impressions from a specific location.\u003c/p\u003e\n"],["\u003cp\u003eBidders with high timeout rates will experience automatic throttling, with Google adjusting traffic quotas if throttling persists over an extended period.\u003c/p\u003e\n"]]],["After in-house testing, contact your Google representative to initiate testing with Google traffic. Provide details like engineering contacts, SSL-enabled URLs, server locations, maximum QPS, and estimated latency. Testing involves synthetic traffic to verify latency and basic ad functionality. Live traffic will gradually increase. The latency requirement is 80-1000 ms. High timeout rates trigger automatic throttling, which might result in a reduced traffic quota. Servers in multiple locations are recommended for broader reach.\n"],null,[]]
