Google Ads Developer Blog

Security enhancements for search users
Troubleshooting and error handling - handling exceptions thrown by the DFP API (Part I)
Register Now for the Spring 2014 AdWords API Workshops

Posted: 09 Apr 2014 12:16 PM PDT

We've long worked to keep your searches on Google secure. We provided SSL encryption for signed-in searches in 2011 and have rolled that out to searches from the omnibox in the Chrome browser. Today, we are extending our efforts to keep search secure by removing the query from the referer on ad clicks originating from SSL searches on Google.com.

Advertisers will continue to have access to useful data to optimize and improve their campaigns and landing pages. For example, you can access detailed information in the AdWords search terms report and the Google Webmaster Tools Search Queries report.

Best practices

The AdWords search terms report (previously known as the search query performance report) lets you see search queries that generated ad clicks along with key performance data. And the Search Queries report available in Google Webmaster Tools provides aggregate information about the top 2000 queries, each day, that generated organic clicks.

If you use the query in the referer for reporting, automated keyword generation or landing page customization, then we suggest using the following alternatives:

For generating reports or automating keyword management with query data, we suggest using the AdWords API Search Query Performance report or the AdWords Scripts Report service.
For customizing landing pages, we suggest using the keyword that generated the ad click, rather than the query. The keyword and match type can be passed to your web server by using a ValueTrack parameter in your destination URLs.

We understand that some partners may need to make changes to their systems and operations, but we think that this is the right path forward for the security of our users searching on Google.com.

Posted by: Paul Feng, Product Management Director, AdWords

Troubleshooting and error handling - handling exceptions thrown by the DFP API (Part I)

Posted: 09 Apr 2014 09:02 AM PDT

We often get a lot of questions about running into exceptions when using the DFP API and what to do about them. Seeing an exception from time-to-time is a normal part of the API workflow and should be expected. Some exceptions are caused by user errors, others by server issues. We strongly recommend that you write code to handle exceptions early on so that it's easier to troubleshoot issues when they occur. In this blog post, we'll go over the first of two major scenarios where adding exception handling will benefit you.

Creating or updating entities

When creating or updating entities with the DFP API, if you forget to supply a required field or set a field to an invalid value, the API throws an ApiException. If you write code to catch this exception, you can print out the error message to show the root cause. The following is an example showing how to do this when using the Google Ads API Java Client Library to create line items.

  // Create a line item.
  LineItem lineItem = new LineItem();
  // lineItem.setSomeThings(...);

  try {
    // Create the line item on the server.
    lineItemService.createLineItems(new LineItem[] {lineItem});
  } catch (ApiException e) {
    ApiError[] apiErrors = e.getErrors();
    for (ApiError apiError : apiErrors) {
      StringBuilder errorMessage = new StringBuilder();
      errorMessage.append(String.format(
          "There was an error of type '%s', on the field '%s',"
          + "caused by an invalid "
          + "value '%s', with the error message '%s'",
          apiError.getApiErrorType(), apiError.getFieldPath(),
          apiError.getTrigger(), apiError.getErrorString()));
      if (apiError instanceof NotNullError) {
        errorMessage.append(String.format(", with the reason '%s'.",
            ((NotNullError) apiError).getReason()));
      } else if (apiError instanceof FrequencyCapError) {
        errorMessage.append(String.format(", with the reason '%s'.",
            ((FrequencyCapError) apiError).getReason()));
      }

      // Append details of other ApiErrors that you are interested in.

      System.err.println(errorMessage.toString());
    }
  }

If you use this code to create a line item, it prints the following if you don't specify an order ID:

There was an error of type 'NotNullError', on the field 'lineItem[0].orderId',
  caused by an invalid value '', with the error message 'NotNullError.NULL',
  with the reason 'NULL'.

If you provide invalid values for the frequency caps field when creating a line item, you'll get the following:

There was an error of type 'FrequencyCapError', on the field
  'lineItem[0].frequencyCaps', caused by an invalid value '1000', with the
  error message 'FrequencyCapError.RANGE_LIMIT_EXCEEDED', with the reason
  'RANGE_LIMIT_EXCEEDED'.
There was an error of type 'FrequencyCapError', on the field
  'lineItem[0].frequencyCaps', caused by an invalid value '0', with the error
  message 'FrequencyCapError.IMPRESSIONS_TOO_LOW', with the reason
  'IMPRESSIONS_TOO_LOW'.

Depending on the type of application you're writing, you may want to show these error messages to your user in a UI or log them. Note that you can find an entity's required fields and valid field values in our reference documentation, for example, LineItem.

If you're getting exceptions when creating or updating entities that are not ApiException errors (such as a SERVER_ERROR) and are unclear on how to diagnose them, then you can always write to us on the API forums and include the requestId of the call that failed and we will help you diagnose the issue.

Look forward to part II of this blog post where we will discuss handling exceptions that are thrown when retrieving entities.

- Vincent Tsao, DFP API Team

Posted: 09 Apr 2014 07:45 AM PDT

We're pleased to announce that the AdWords API Workshops are coming back for another round in April and May of 2014. Registration is now open!

Workshop topics include:

Shopping campaigns - how shopping integrates into the AdWords API
MCC scripts - The feature that was most requested is now available for beta signup
FeedServices updates - including the new location extensions setup
Targeting types - DSAs, DomainSetting and AutoTagging
Analytics - getting started with the Analytics API and how it fits within your AdWords apps
Bid Estimation - the different ways to estimate bids using the API

Not only are the workshops an important way to keep up-to-date with new features and best practices in the AdWords API, they are a great way for you to meet with and ask questions of the Google AdWords API team in person. This is also a key event for members of the community to bring their feedback directly to us. Finally, it's a great opportunity for you to exchange ideas and best practices with fellow developers.

Register now and join us at a workshop in one of the following cities:

London, UK, April 29
Hamburg, Germany, May 13
Amsterdam, Netherlands, May 15
New York City, USA, May 5
San Francisco, USA, May 12
Shanghai, China, May 20 (in Chinese)
Taipei, Taiwan, May 22 (in Chinese)
Delhi, India, May 26
Sydney, Australia, May 29

Note: The workshops in the USA, Europe, and Australia are technical in nature and best suited to developers. Those in China, Taiwan, and India will have additional sessions accessible to a broader audience, including non-developers.

For more information on the agenda, location and logistics, please visit the AdWords API Workshop website.

- Marc Wandschneider, AdWords API Team

Thursday, April 10, 2014