Testing and Releasing Your Application

When your application is complete, and you have tested it in-house, it must undergo a suite of standardized tests in which your Google account representative sends test requests to your servers. Once your application passes these tests, it is eligible for release. The following topics explain how the test and release process works.

Initial testing

You can test ad rendering for your HTML snippets by creating third-party ads in the UI. Clicking on the ad name will pop up a preview window containing the rendered ad. You can also click on the rendered ad to test click tracking and the use of the click tracking macros. If you create ads just for the purpose of previewing, then make sure to leave them paused so that they do not serve.

Testing with Google traffic

When you are ready to start testing with traffic sent from Google, please contact your Ad Exchange representative. You will be asked to provide various information such as the following:

  • 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.
  • The SSL-enabled URL that responds to RTB requests
  • The SSL-enabled URL of the Cookie Code Matching server, if you opted to use this functionality
  • The physical location (state, country) of your RTB servers, in order to optimize communication with Google's servers.
  • Maximum QPS (query-per-second) you are willing to serve from each physical location after testing is finished.
  • 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.
  • Estimated latency your servers will use for processing RTB requests.
  • PGP keys for mailing price decryption information.

Contact your Ad Exchange representative to make changes to this information at any time during the testing process.

Testing will involve several steps with synthetic traffic to verify latencies from different locations. Google will also do some basic tests that ads render and to click tracking properly. (Most of this should be done during your own testing and during certification.) We will also ask for you to confirm that you are able to receive and decode winning price notifications and clicks. Once these items are verified, the next step will be a gradual ramp up of live traffic over several days.

The latency requirement for using Real-time Bidder is 100 milliseconds, measured from the time Google sends the call to the time Google receives a reply. To qualify for impressions processed at a given location, at most 2% of requests should exceed this 100ms deadline. If you want to receive impressions from multiple 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.

A bidder that temporarily has high timeout rates because of network events or other problems will be automatically throttled. This throttling will automatically reduce or increase traffic over a time-frame of a few minutes. If traffic is often throttled for an extended period of time, then Google may adjust your traffic quota to a level that can be handled more consistently.

Send feedback about...

Real-Time Bidding Protocol
Real-Time Bidding Protocol