What is a test account?
AdWords test accounts allow developers to execute AdWords API requests against the production environment for development and testing purposes. Here are some reasons to use a test account for developing your application:
- Test account campaign data has no effect on live campaigns, so you can test campaign management logic without affecting live campaign data.
- Test accounts are disabled. This means that they will not serve ads no matter what API calls you make.
- Test account access does not require an approved developer token, so you can start experimenting with the AdWords API before your application is reviewed.
To obtain a test account you need to first create a test MCC account. All client accounts created under this test MCC account will be automatically marked as test accounts. Prior to making AdWords API requests to a test account, make sure you also have a production (non-test) MCC account and a production developer token (either pending approval or approved will work).
In summary, the steps to create and use a test account are:
- If you don't already have a production MCC and/or a production MCC developer token:
- Create a test MCC
firstname.lastname@example.org). In order to create a test account, you must have an existing Google account that is not already linked to an AdWords account. You can create a new Google account at accounts.google.com.
- Use the production MCC account's developer token when making requests
againsts the test MCC account (e.g.,
- When requesting an OAuth 2.0 refresh token, make sure you are logged in as
the test MCC account user (e.g.,
The following table explains the allowed interactions between the developer token's status and the AdWords account types:
|Production developer token status||AdWords account type||Allowed|
OAuth 2.0 and the test account user
In order to access the test account using OAuth 2.0, you will need to have the test MCC account user grant permission to your client application. Hence, when requesting a refresh token, please make sure you are logged in as the test MCC account user rather than the production MCC account user.
When you want to switch from the test MCC account to the production MCC account, simply re-configure the client library to use the production MCC account user's refresh token.
All calls made with the AdWords API require a developer token, but the token doesn't have to be approved for calls made to test accounts; you can make requests against a test account while the token application is still pending. The token can be obtained from the AdWords API Center page under the My Account tab in your MCC production account (not MCC test account) AdWords user interface.
All requests to test accounts should be sent to the same endpoint as production requests:
Request and response SOAP headers are identical to those returned in production accounts. For authorization headers, make sure to use your test account credentials.
Differences between test accounts and production accounts
Here are the differences between test and production accounts:
- Test accounts will not serve any ads.
- The TargetingIdeaService and TrafficEstimatorService return dummy data to test accounts.
- Since test accounts will not serve any ads, they will also have no metrics. This impacts AdHoc reports (values for impressions, costs, etc. will all be zero).
- Test accounts will not have any associated clicks, so they cannot be used to test offline conversion uploads.
- The DataService will not return bid landscapes for test accounts because bid landscapes are based on ads served from the account.
- You can only have 100 accounts in the hierarchy of a test MCC account. The limit for production accounts is much higher.
Test accounts are designated with a red label (see screenshot) and are accessible from the AdWords User Interface. The UI is useful for API exploration during application testing. Test accounts have the same restrictions (including rate limits) as production accounts.
Developing with test accounts
When applying for AdWords API access, you may be requested to demonstrate some aspects of your application. One such aspect is reporting, which may be difficult to emulate when using just test accounts. Because test accounts do not serve impressions, they do not produce any metrics. It is still possible to download structural reports—but you will only see zero-impression rows, which means that segments will not work. To get around this limitation, we suggest displaying fake data. The Token Review team needs to see that your application can interact with and display report data. By mocking out the report call (i.e. pretending the report call succeeded and using a locally stored file containing fake report data), you can work with report data without actually having such data returned from the API.
Make sure the reports come back in the correct format. For example, if you run a campaign performance report with date, campaign name, campaign ID, impressions, clicks, and costs, you will get a file like this:
"CAMPAIGN_PERFORMANCE_REPORT (Mar 20, 2013-Mar 23, 2013)" Day,Campaign,Campaign ID,Impressions,Clicks,Cost 20130320,Widgets,123,1211,19,14.92 20130320,Sprockets,456,300,4,2.92 20130321,Widgets,123,901,12,9.86 20130321,Sprockets,456,340,5,3.86 20130322,Widgets,123,1065,16,11.23 20130322,Sprockets,456,509,6,5.23 20130323,Widgets,123,1005,15,10.12 20130323,Sprockets,456,287,3,1.12
By constructing such a file and storing it locally, you could have your application mock the call to the API: when the report is requested, return the stored file and process that rather than making an actual API call. You can create a file like this for each report you'd like to display. We recommend using this approach if you are developing with test accounts and need to display performance data.
Testing with production data
As noted before:
- You cannot link a test MCC account or a test AdWords account with a production MCC account, or vice versa.
- Test accounts don't have real production data.
You can test with production data in a read only fashion on your production accounts if you use the validateOnly header in your requests and you have an approved production developer token.