Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Cuando tu aplicación esté completa y la hayas probado de forma interna, deberá someterse a un paquete de pruebas estandarizadas en las que el representante de tu cuenta de Google enviará solicitudes de prueba a tus servidores. Una vez que tu aplicación
paso estas pruebas, es apta para publicarse. En los siguientes temas, se explica cómo funciona el proceso de prueba y lanzamiento.
Pruebas con el tráfico de Google
Cuando tengas todo listo para comenzar a realizar pruebas con el tráfico que envía Google, comunícate con tu representante de Authorized Buyers. Se te solicitará que proporciones varios tipos de información, como la siguiente:
Información de contacto de Ingeniería. Si las pruebas no se realizan como se espera y hay problemas de ingeniería que deben abordarse, usaremos esta información de contacto para interactuar directamente con tu equipo.
La URL habilitada para SSL que responde a las solicitudes de RTB.
La URL habilitada para SSL del servidor de coincidencia de códigos de cookies, si habilitaste esta funcionalidad
La ubicación física (estado y país) de tus servidores de RTB para optimizar la comunicación con los servidores de Google
Es la cantidad máxima de QPS (consultas por segundo) que deseas entregar desde cada ubicación física una vez que finalicen las pruebas.
Es la fecha a partir de la cual tus servidores de coincidencia de código de RTB o de cookies están activos para las pruebas. Google enviará solicitudes de RTB a tus servidores en esa fecha o poco después.
La latencia estimada que usarán tus servidores para procesar las solicitudes de RTB.
Claves PGP para la información de desencriptación de precios de correo
Comunícate con tu representante de Authorized Buyers para realizar cambios en esta información en cualquier momento durante el proceso de prueba.
Las pruebas incluirán varios pasos con tráfico sintético para verificar las latencias desde diferentes ubicaciones. Google también realizará algunas pruebas básicas para que los anuncios se rendericen y el seguimiento de clics funcione correctamente. (La mayor parte de esto se debe hacer durante tus propias pruebas y durante la certificación). También te pediremos que confirmes que puedes recibir y decodificar las notificaciones de precios ganadores y los clics. Una vez que se verifiquen estos elementos, el siguiente paso será aumentar gradualmente el tráfico en vivo durante varios días.
El requisito de latencia para usar el creador de ofertas en tiempo real es de 80 a 1,000 ms, medido desde el momento en que Google envía la llamada hasta el momento en que recibe una respuesta. Esta fecha límite depende del formato y el tipo de subasta. Consulta el campo BidRequest.tmax para conocer el valor exacto.
Para calificar para las impresiones procesadas en una ubicación determinada, el 2% como máximo de las solicitudes debe superar esta fecha límite. Si deseas recibir impresiones de varias
ubicaciones de mercado según estos requisitos, por lo general, es necesario ejecutar servidores de ofertas en todas las regiones. Por ejemplo, recibir impresiones de la costa este y la costa oeste de Estados Unidos suele requerir que tengas servidores de ofertas en ejecución en ambas costas.
Se reducirá automáticamente la velocidad de un ofertante que tenga tasas de tiempo de espera altas de forma temporal debido a eventos de red o a otros problemas. Esta limitación reducirá o aumentará automáticamente el tráfico en un período de unos minutos. Si el tráfico se limita con frecuencia durante un período prolongado, es posible que Google ajuste tu cuota de tráfico a un nivel que se pueda controlar de manera más coherente.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 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,["When your application is complete, and you have tested it in-house, it must\nundergo a suite of standardized tests in which your Google account\nrepresentative sends test requests to your servers. Once your application\npasses these tests, it is eligible for release. The following topics explain\nhow the test and release process works.\n\nTesting with Google traffic\n\nWhen you are ready to start testing with traffic sent from Google, contact\nyour Authorized Buyers representative. You will be asked to provide various\ninformation such as the following:\n\n- Engineering contact information. If the testing does not proceed as expected and there are engineering issues to be addressed we will use this contact information to interact directly with your team.\n- The SSL-enabled URL that responds to RTB requests.\n- The SSL-enabled URL of the Cookie Code Matching server, if you opted to use this functionality.\n- The physical location (state, country) of your RTB servers, in order to optimize communication with Google's servers.\n- Maximum QPS (query-per-second) you are willing to serve from each physical location after testing is finished.\n- Date from which your RTB / Cookie Code Matching servers are live for testing. Google will send RTB requests to your servers on or soon after that date.\n- Estimated latency your servers will use for processing RTB requests.\n- PGP keys for mailing price decryption information.\n- Confirm that [pretargeting](//support.google.com/authorizedbuyers/answer/6048315) is set up in your [Pretargeting\n UI](//www.google.com/authorizedbuyers).\n\nContact your Authorized Buyers representative to make changes to this\ninformation at any time during the testing process.\n\nTesting will involve several steps with synthetic traffic to verify\nlatencies from different locations. Google will also do some basic tests that\nads render and to click tracking properly. (Most of this should be done during\nyour own testing and during certification.) We will also ask for you to\nconfirm that you are able to receive and decode winning price notifications and\nclicks. Once these items are verified, the next step will be a gradual ramp up\nof live traffic over several days.\n| Since your account as a whole is placed into test mode for this, any bid that you make in response will be filtered out of the auction whether the value you see in the `BidRequest.test` is `true` or `false` (`1` or `0` if using the JSON format).\n\nThe latency requirement for using Real-time Bidder is 80 to 1000 ms,\nmeasured from the time Google sends the call to the time Google receives a\nreply. This deadline depends on format and auction type; check the\n`BidRequest.tmax` field for the exact value.\n\n\u003cbr /\u003e\n\nTo qualify for impressions processed at a given location, at most 2% of requests should exceed this deadline. If you want to receive impressions from multiple [trading locations](/authorized-buyers/rtb/peer-guide#trading_locations) according to these requirements, it is usually necessary to run bidding servers in all regions. For example, receiving impressions from both the East and West coasts of the United States will usually require that you have bidding servers running on both the East and West coast.\n\n\u003cbr /\u003e\n\nA bidder that temporarily has high timeout rates because of network events\nor other problems will be automatically throttled. This throttling will\nautomatically reduce or increase traffic over a time-frame of a few minutes. If\ntraffic is often throttled for an extended period of time, then Google may\nadjust your traffic quota to a level that can be handled more consistently."]]
