애플리케이션이 완성되고 자체 테스트를 마친 후에는 Google 계정 담당자가 서버에 테스트 요청을 전송하는 표준화된 테스트 모음을 거쳐야 합니다. 애플리케이션이 이러한 테스트를 통과하면 출시할 수 있습니다. 다음 주제에서는 테스트 및 출시 프로세스의 작동 방식을 설명합니다.
Google 트래픽으로 테스트
Google에서 전송한 트래픽으로 테스트를 시작할 준비가 되면 Authorized Buyers 담당자에게 문의하세요. 다음과 같은 다양한 정보를 제공하라는 메시지가 표시됩니다.
엔지니어링 담당자 연락처 정보 테스트가 예상대로 진행되지 않고 해결해야 할 엔지니어링 문제가 있는 경우 이 연락처 정보를 사용하여 담당 팀과 직접 소통합니다.
RTB 요청에 응답하는 SSL 지원 URL입니다.
이 기능을 사용하도록 선택한 경우 쿠키 코드 일치 서버의 SSL 지원 URL입니다.
Google 서버와의 통신을 최적화하기 위한 RTB 서버의 실제 위치 (주, 국가)입니다.
테스트가 완료된 후 각 실제 위치에서 제공할 최대 QPS (초당 쿼리 수)입니다.
RTB / 쿠키 코드 매칭 서버가 테스트를 위해 게시된 날짜입니다. Google은 해당 날짜 또는 그 직후에 서버에 RTB 요청을 전송합니다.
테스트 프로세스 중 언제든지 Authorized Buyers 담당자에게 문의하여 이 정보를 변경할 수 있습니다.
테스트에는 여러 위치의 지연 시간을 확인하기 위한 합성 트래픽을 사용하는 여러 단계가 포함됩니다. Google에서는 광고가 렌더링되고 클릭 추적이 제대로 이루어지는지 확인하는 몇 가지 기본 테스트도 실행합니다. 대부분은 자체 테스트 및 인증 중에 실행해야 합니다. 또한 낙찰 가격 알림 및 클릭수를 수신하고 디코딩할 수 있는지 확인해 달라고 요청합니다. 이러한 항목이 확인되면 다음 단계는 며칠에 걸쳐 실시간 트래픽을 점진적으로 늘리는 것입니다.
실시간 입찰자를 사용하기 위한 지연 시간 요구사항은 80~1,000밀리초이며, 이는 Google에서 호출을 전송한 시점부터 Google에서 응답을 수신한 시점까지 측정됩니다. 이 기한은 형식 및 입찰 유형에 따라 다릅니다. 정확한 값은 BidRequest.tmax 필드를 확인하세요.
지정된 위치에서 처리된 노출을 얻으려면 요청의 최대 2% 가 이 기한을 초과해야 합니다. 이러한 요구사항에 따라 여러
거래소에서 노출을 수신하려면 일반적으로 모든 지역에서 입찰 서버를 실행해야 합니다. 예를 들어 미국 동부 해안과 서부 해안에서 모두 노출을 수신하려면 일반적으로 동부 해안과 서부 해안에서 모두 입찰 서버를 실행해야 합니다.
네트워크 이벤트 또는 기타 문제로 인해 일시적으로 제한 시간 비율이 높은 입찰자는 자동으로 제한됩니다. 이 제한으로 인해 몇 분 동안 트래픽이 자동으로 감소하거나 증가합니다. 트래픽이 장시간에 걸쳐 자주 제한되는 경우 Google에서 트래픽 할당량을 더 일관되게 처리할 수 있는 수준으로 조정할 수 있습니다.
[null,null,["최종 업데이트: 2025-08-21(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,["# Testing and Releasing Your Application\n\nWhen 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---------------------------\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."]]
