Google Ads Developer Blog

AdWords API - Upcoming changes to AdGroupCriterionService.mutate behaviour

2012-05-28T00:34:00.000-07:00

We are making some changes to the way qualityInfo and firstPageCpc fields are returned by AdGroupCriterionService in AdWords API. Currently, the qualityInfo and firstPageCpc fields are populated for BiddableAdGroupCriterion objects returned in response to AdGroupCriterionService.mutate API calls. Starting the week of June 15th, these fields will no longer be populated in mutate call responses. If you wish to retrieve QualityInfo or firstPageCpc for criteria, you need to retrieve them by making a get() call instead, using the appropriate selector fields. This change will affect all the active versions of the AdWords API.

If your code depends on the current behaviour of AdGroupCriterionService.mutate, please make sure you migrate your code by the week of June 15th. If you have any questions about these changes please reach out to us in the forum or during one of our office hours hangouts.

- Anash P. Oommen, AdWords API Team

AdWords API - Updates in Search Query Performance Report

2012-05-25T14:06:00.000-07:00

As previously mentioned, AdWords now supports new matching behavior for exact and phrase match keywords. Support was added in v201109_1 that allows toggling of this setting. In order to better support reporting on the performance of this new feature, the Search Query Performance Report will gain a new field, MatchTypeWithVariant, which will now return two additional enum values in addition to the existing values of the MatchType field (enum values / display values):

NEAR_EXACT / exact (close variant)
NEAR_PHRASE / phrase (close variant)

The existing MatchType field will continue to return only the values it does today. This means that a value that would return “exact (close variant)” from MatchTypeWithVariant will return as “exact” for field MatchType.

This new field will be available starting the week of Monday June 4th.

If you have any questions about this change or other issues, please post on the forum or attend one of the AdWords API Office Hours Hangouts.

- Kevin Winter, AdWords API Team

Announcing a from-scratch rewrite of the Java Client Library

2012-05-21T14:01:00.000-07:00

The Java Client libraries for Ads APIs are some of the most popular, used by thousands of developers each day to manage their AdWords, DFA and DFP accounts. Since they were initially written years ago, we’ve gotten a lot of feedback from developers using the libraries. We’ve tried to incorporate as many suggestions as possible, but due to the legacy architecture, certain changes were not feasible.

Today we’re pleased to announce that we are officially supporting a new from-scratch rewrite of the Java Library! It is now production-ready and is no longer experimental. Read on for some reasons why you’ll want to take the new library for a spin right away.

New Features

New features in the rewritten library include:

Product level support for AdWords, DFA and DFP with shared common layer code.
Library is now hosted on Maven.
OAuth1.0a and OAuth2.0 support.
Uses the SLF4J logging facade.
More control over building your session, providing authentication and more.
Experimental AppEngine support via JAX-WS.

Migrating

The two biggest changes involve how to configure your session and how to obtain Service objects.

Here’s how you configure an AdWordsSession:

AdWordsSession session = new AdWordsSession.Builder()
    .fromFile()
    .withClientLoginToken(clientLoginToken)
    .build();

Here’s how you obtain a reference to a service:

AdWordsServices adWordsServices = new AdWordsServices();
CampaignServiceInterface campaignService =
    adWordsServices.get(session, CampaignServiceInterface.class);

Check out the migration guide we have recently published on the new project page wiki. You’ll find these procedures described in depth, along with best practices for using these classes.

The new library will be the primary focus of development moving forward. The existing AdWords and DFP java libraries are now in maintenance mode and we will continue to add support for new AdWords and DFP API releases for the near future.

If you find any bugs, have a patch to contribute or just a feature request, please feel free to file an issue on our issue tracker.

- Kevin Winter, AdWords API Team

Update on DFA API Page Size Capping

2012-05-17T06:33:00.001-07:00

Previously, we discussed extending the set of operations in version v1.18 of the DFA API which will receive a limit of 1000 objects per page on June 2nd, 2012. Additional operations have been added to this set since the announcement. The new list is as follows:

The getPlacementsByCriteria operation has been capped at 1000 results per page since version v1.18’s release. The original post has also been updated with this new list. You can reach us with any questions you may have on our forum.

- Joseph DiLallo, DFA API Team

DFA API v1.18 Released

2012-05-14T09:33:00.000-07:00

The newest version of the DFA API is now available: v1.18. This release adds support for In-Stream Video creatives and makes some assorted improvements, including better error messages and trimming out some unused fields. This post reflects just some of the changes in the release. Our updated release notes page gives you a more in-depth breakdown of what has changed since the previous version.

In-Stream Video Creatives

New to v1.18, you can create and manage your In-Stream video creatives through the API. Several new classes have been added to the creative service to represent these objects. You can expect to see examples of their use in our updated client libraries.

Capping on Page Sizes

Most get operations in the DFA API return pageable result sets. We are now beginning to enforce reasonable limits on the number of objects within an individual pages (also known as pageSize). With the release of v1.18, the placement service’s getPlacementsByCriteria operation is limited to a maximum of 1000 objects in a single page.

[Update 5/17/2012: The following list of operations has been extended as explained in this blog post.]

Beginning June 2nd, 2012, the same limit also applies for the following operations:

All affected operations will have a default page size of 1000 if a page size is not provided.

Deprecation and Sunset of Older Versions

With the the release of v1.18, version v1.16 is now deprecated. Version v1.16 will continue to be supported until June 2nd, 2012, when it will be entirely removed from service, as previously announced.

Meanwhile, version v1.17 will be deprecated in August and sunset in early September, 2012.

As always, we highly value your feedback and questions. Please join us on our forum whenever you’d like to reach us.

- Joseph DiLallo, DFA API Team

Announcing the AdWhirl to AdMob Ad Network Mediation Import Pipeline

2012-05-11T13:00:00.000-07:00

We're very pleased to announce the availability of the AdWhirl to AdMob Ad Network Mediation Import Pipeline. This functionality--accessible from mediation.admob.com--will enable you to import all of your relevant configuration data from AdWhirl in just a few clicks!

Getting started is simple! Here are the steps you'll want to follow to import a configuration:

Navigate to mediation.admob.com and click the Import Placement from AdWhirl link. Read through the notes.
Click Log in to AdWhirl. You'll be redirected to an AdWhirl authorization page where you should enter your AdWhirl account's email address and password.
Click Submit. Assuming your info is correct, you'll be redirected back to AdMob's Import Placement from AdWhirl workflow, where you can choose a particular placement to pull over.
Mouse over a placement and click the Select to Import button. After confirming things are correct on the Review & Import screen, go ahead and click the final Import button.
Put your feet up, grab a brew; you're done! Take a moment to bask in the warm glow of your accomplishment. The placement will now appear in your AdMob Ad Network Mediation Placements interface.

The AdMob Ad Network Mediation product offers many improvements over AdWhirl, including enhanced stability, support for tablet sizes, revenue optimizations by country, and improved reporting. We hope you give it a look! As always, if you have questions or concerns, you can get a hold of us on our forum.

- Wes Goodman, AdMob Team

Make it your own with Custom Fields in DFP API

2012-05-11T11:37:00.001-07:00

New to v201204 of DFP API are custom fields, which can be applied to orders, line items, and creatives. This new feature gives you the ability to include additional information on DFP entities without having to implement data persistence in your own system. They are saved when the entities are saved on the DFP servers which ensures data consistency and removes the need for syncing.

Data Types
The following are the supported data types of a custom field:

String
Number
Toggle (true/ false)
Drop-down (selection from user-defined values)

These data types should cover some of the most common use cases for custom fields such as comments (string), metrics (number), and internal system status (toggle/drop-down).

How-To
You can create and manage your custom fields and custom field options (for drop-down custom fields) with the new CustomFieldService. Please make sure you have the feature enabled for your network before you try to set up custom fields. We are also working on bringing custom fields to the user interface, so be on the lookout for them!

Walk-Through
The following Java sample shows how you can add a string and drop-down custom field value to your line item. This assumes that you have already created the custom fields and custom field options. You can check out how to create them using the CreateCustomFields and CreateCustomFieldOptions examples in the client libraries.

Long customFieldId = Long.parseLong("INSERT_STRING_CUSTOM_FIELD_ID_HERE");
Long dropDownCustomFieldId = 
    Long.parseLong("INSERT_DROP_DOWN_CUSTOM_FIELD_ID_HERE");
Long customFieldOptionId = 
    Long.parseLong("INSERT_CUSTOM_FIELD_OPTION_ID_HERE");
Long lineItemId = Long.parseLong("INSERT_LINE_ITEM_ID_HERE");

// Get the line item.
LineItem lineItem = lineItemService.getLineItem(lineItemId);

// Create custom field values.
List customFieldValues = new ArrayList();

// Create the String custom field value.
TextValue textValue = new TextValue();
textValue.setValue("Custom field value");
CustomFieldValue customFieldValue = new CustomFieldValue();
customFieldValue.setCustomFieldId(customFieldId);
customFieldValue.setValue(textValue);
customFieldValues.add(customFieldValue);

// Create the drop-down custom field value.
DropDownCustomFieldValue dropDownCustomFieldValue =
    new DropDownCustomFieldValue();
dropDownCustomFieldValue.setCustomFieldId(dropDownCustomFieldId);
dropDownCustomFieldValue.setCustomFieldOptionId(customFieldOptionId);
customFieldValues.add(dropDownCustomFieldValue);

// The line item can contain custom field values for the field you are
// trying to set or an unrelated one.  The following checks that you only 
// add existing custom field values for custom fields different from the 
// ones you are setting.
if (lineItem.getCustomFieldValues() != null) {
  for (BaseCustomFieldValue oldCustomFieldValue : 
      lineItem.getCustomFieldValues()) {
    if (!oldCustomFieldValue.getCustomFieldId().equals(customFieldId)
        && !oldCustomFieldValue.getCustomFieldId().equals(
        dropDownCustomFieldId)) {
      customFieldValues.add(oldCustomFieldValue);
    }
  }
}

// Set the custom field values on the line item.
lineItem.setCustomFieldValues(customFieldValues.toArray(
    new BaseCustomFieldValue[]{}));

// Update the line item on the server.
LineItem[] lineItems = lineItemService.updateLineItems(
    new LineItem[] {lineItem});

And that’s it! For the full Java code example, you can refer to the SetLineItemCustomFieldValue in the client library.

With this new feature, we aim to help you create stronger integrations with DFP through the API. If there are any features you would like us to demonstrate, please don’t hesitate to let us know with a forum post or at a Office Hour Hangout.

- Jeffrey Sham, DFP API Team

Ad Exchange Buyer SOAP API v201109_1 - features available more quickly in dot releases

2012-05-11T07:46:00.001-07:00

The Ad Exchange Team is pleased to announce the launch of v201109_1 of the Ad Exchange Buyer SOAP API, a dot release which includes the following services that are relevant to Ad Exchange Developers:

Expandable directions for display ads are now available through ThirdPartyRedirectAd.ExpandingDirection.
TargetingIdeaService now exposes the attribute CATEGORY_PRODUCTS_AND_SERVICES.

Moving forward, we will use dot releases which will allow us to launch features more quickly; v201109_1 does not start the sunset on prior versions.

The full set of release notes is available here. If you have any questions please reach out to us in the DoubleClick Ad Exchange forum.

- David Torres, AdWords API Team

AdWhirl v3.2 Released!

2012-05-10T12:33:00.000-07:00

We're very happy to announce the release of AdWhirl v3.2! This version brings us support for the latest and greatest from several ad networks. In particular:

Android:

Support for AdMob v6.0.1
Support for Millennial v4.5.1
Support for InMobi v350

iOS:

Support for AdMob v6.0.4
Support for Millennial v4.5.5
Support for InMobi v350

As always, you can find the latest SDKs available on our download page. Or, feel free to snag the source: (Android | iOS). If you encounter any issues, don't hesitate to contact us on our forum or during Office Hours--times to be announced on our blog.

- Wes Goodman, AdMob Team

Updates to our AdMob SDK

2012-05-10T10:06:00.000-07:00

Editor’s note: We’d like to share this post from Chrix Finne which announces updates to the Google AdMob Ads SDK. -- Eric Leichtenschlag, Ads Developer Relations Team

Today we are posting an update to the AdMob SDKs for iOS and Android. This SDK update features several minor bug fixes and improvements.

We are also releasing an optional version of our SDK for iOS that includes the UDID parameter, which is used to improve ad performance and relevance. Apps utilizing this version must obtain appropriate user consent for sending device identifier information in compliance with relevant iOS policies.

Posted by Chrix Finne, Product Manager

AdWords API v201109_1 - new AdWords features available more quickly in dot release and beta program

2012-05-08T12:57:00.000-07:00

In an effort to make more features available faster to AdWords API users, we’re launching AdWords API v201109_1, a dot release which includes services to help API users incorporate some recent AdWords web interface launches into their applications. New features include:

Keyword match properties NEAR_EXACT and NEAR_PHRASE, which allow API users to opt in/out of these match types.
LocationSyncExtension and the reports download service now have OAuth 1.0 support, bringing these services in line with others in the API.

As part of this dot release, we are also launching a few other features that will be available through an invitation-only beta. Similar to beta programs for the AdWords interface, the goal of this beta is to give developers earlier access to specific features, allowing us to incorporate feedback more quickly and innovate more effectively.

Moving forward, we will use dot releases to launch AdWords features more quickly. AdWords API v201109_1 does not start the sunset on prior versions, so you do not need to upgrade immediately.

Complete release notes are available here. If you have any questions about these changes please reach out to us in the forum or during one of our office hours via Google+ Hangouts.

Posted by AdWords API Team

Announcing v201204 of the DFP API

2012-05-07T10:00:00.000-07:00

v201204 of the DFP API has launched and is ready for you to explore. In this version, we’ve added custom fields, expanded team and user functionality, and updated the conversion reports columns. A full list of features can be found on our release notes page.

Custom fields

Custom fields is a new feature to the API that lets you add attributes to entities, such as orders and line items. For example, you can add your own field to a line item that would let salespeople add comments as a string. Those comments would then be placed into custom field values that are added to each line item. Support for custom fields will be coming or the DFP UI soon, but if you have this feature enabled on your network now, you’ll be able to start working with them right away.

Teams changes

The way in which users are added to teams has changed starting in v201204. In previous versions, users were added to team objects directly. Now, you can associate users and teams, much like line items and creatives. The new associations will also let you define per user permissions, such as only letting some users have read-only access.

Version deprecation reminder

As a reminder, we are retiring support for v201103, v201104, and v201107 on May 11th. If you haven’t upgraded yet, now would be a great time.

Our next hangout is May 9th and we’d love to see you there. As always, let us know if you have any questions on our forum.

- Adam Rogal, DFP API Team

Placing ads to prevent accidental clicks in your mobile app

2012-05-03T10:29:00.000-07:00

In this blog post, we will help you understand how you can monetize your mobile applications while following our ad placement guidelines to ensure a good experience for your users.

As you may know, Google takes issues regarding program policy compliance very seriously. We have our AdSense program policies and AdMob program policies to help ensure a positive experience for our publishers, our users, and our advertisers. As such, we ask that our publishers/developers comply with these policies.

One of the most common policy violations is placing ads in a way which can trigger accidental clicks. Your ads’ proximity to the other elements within your application can influence whether or not users click on ads by accident.

Here are some tips to decrease the chances of accidental clicks:

Ads should not be right next to interactive buttons, such as a “next” button, or on a game play screen where users are interacting continuously with the application. We have seen that when a user is clicking or tapping repeatedly within an application and there is an ad near or within the interaction area, there is a much higher rate of invalid activity.
If the space within your application is limited, it helps to then delineate the ad from the application content by creating a thick border between the ad and the application’s interactive portion.

An example of a placement to avoid:

A recommended ad placement in this scenario:

Please double check your ads’ implementation with the tips above. With the right implementation, you’ll be able to monetize your application properly without accidental clicks.

- Maiko Fujita, AdMob Team

Know Your AdMob IDs: Publisher vs Mediation

2012-04-27T14:14:00.000-07:00

Last week we announced the release of Google AdMob SDK 6.0 with Ad Network Mediation. We’ve noticed some confusion on how to use a mediation ID instead of a publisher ID, so we’d like to explain the difference between the two.

A publisher ID is generated after adding a site/app and is used to request ads from the AdMob network. A publisher ID can request banners as well as interstitials, giving you the ability to use the same ID throughout your application to get AdMob ads. However, for better reporting, we still recommend that you use a different publisher ID for each ad placement.

A mediation ID is generated after creating a mediation placement. A mediation ID is used to retrieve the mediation configuration from the server so the AdMob SDK can make ad requests to other ad networks on your behalf. Unlike a site/app, a mediation placement requires you to define an ad format, for example a 320x50 banner. Trying to request an interstitial ad with a 320x50 banner mediation placement (and vice versa) will result in the following error:

iOS - Failed to fetch interstitial ad: Unable to request an interstitial when server configuration was for kGADAdSizeBanner.
Android - onFailedToReceiveAd(There was an internal error.)

Therefore, you’ll need to create multiple mediation placements if you want to use banners and interstitials in the same application with mediation.

Feel free to post any questions regarding the AdMob SDK or ad network mediation to our forum. Even better, if you’d like real-time responses, join us at our upcoming office hours hangout session.

- Eric Leichtenschlag, AdMob Team

AdMob Optimisation Essentials

2012-04-26T08:43:00.000-07:00

Whether your ads are from AdMob or another source, the focus of your app should always be on delivering the best possible user experience. Ads should be an integral part of your design process, rather than an afterthought so you can ensure that ads complement rather than compete with your content.

Increase Coverage

When choosing where to place your ad units, remember only one ad can be visible on the screen anytime. If your application involves playing a game with the controls at the bottom of the page then it is advisable you place the ad at the top. If your application carries a lot of article pages make sure you implement an ad unit on each of the article pages, sometimes these pages can be forgotten once the main pages are being served.

Increase Fill Rate

Take advantage of the Google certified ad networks feature within your AdMob account. Opting in to AdSense Backfill could help your fill rate improve substantially and therefore positively impact your earnings. Once you have the latest AdMob SDK implemented, you can access additional ad inventory from the Google Ad Network. Remember:

The backfill feature is enabled per site ID
Ads served from the Google Ad Network will not respect the filter rules set by your site ID at this time.

Increase Competition

Increase competition by keeping your filter list small. Filtering decreases the number of ads that can appear, thereby decreasing your potential earnings as well. Blocking ad groups may have a negative revenue impact because blocked ads won't compete in the auction on your site, and therefore won't drive up potential earnings for that ad space.

Optimize your refresh rate to improve your click-through-rate

It is important to keep in mind that users need time to interact with your content and the ad within your application. An ad that refreshes too often can adversely affect your CTR, by not giving users a chance to view the ad and decide if they are interested in clicking it. We would recommend setting your refresh rate between 45s - 60s and this can be managed within the AdMob interface.

Increase Traffic

If your app doesn't immediately make the top 50 rankings on an app marketplace, you have plenty of promotional options.

Advertising can drive downloads and place your app in the top 50 of an app store, where you'll likely enjoy even more downloads from people browsing the store. Read more about Google's solution to help you get discovered through advertising.
Get featured: App marketplaces, ranking and review sites tend to highlight the most interesting and advanced app offerings. Try to make your app unique, see more on Android design.
Allow social sharing: When people reach a goal in the app (say, a game level) or find something interesting in the app, make it easy for them to share this information directly with their social networks.
Cross-promotion is another easy and often free way to drive more users to your app; this occurs when you target users of other apps or properties and promote your app. For more information on promotion check out the guidetotheappgalaxy.com.

We hope these new resources help you make the most of AdMob.

- Dairine Kennedy, EMEA Mobile Specialist

DFP API Test Network Update and Sandbox Shutdown

2012-04-24T15:00:00.000-07:00

We announced in a previous post an easier way to test with the DFP API. We've iterated quickly and improved on that solution and we are also setting a date for the shutdown of the sandbox.

Test Accounts
When we initially launched the new test networks, you had to create a new Google account if you had any type of DFP network associated with the account. We've lifted this restriction. Now each Google account is always allowed to create a single test network using NetworkService.makeTestNetwork(). This means you can use the same google account for production and test networks.

Sandbox Shutdown
Now that we've given you a bit of time to switch off of the sandbox environment, we're announcing that we are shutting it down on May 24th, 2012. This allows for another month of testing, but we hope you will migrate to the new test networks as soon as possible.

Happy testing and stay tuned for more DFP API blog posts. Don't forget to join us on our next Hangout and, as always, let us know if you want to see any new features or blog posts on our forum.

- Paul Rashidi, DFP API Team

Build a flexible app business with the latest AdMob SDK

2012-04-19T11:56:00.000-07:00

Editor’s note: reposting from Google Mobile Ads Blog post by Chrix Finne. -- Stan Grinberg, Ads Developer Relations Team

Mobile applications are now big businesses, but the developers behind them are forced to spend more of their time dealing with increasing complexity. They need to develop for different devices with different screen sizes, choose from a myriad of advertising networks, and manage varying rich media ad creative formats.

The new Google AdMob SDK 6.0 release for Android and iOS is designed to reduce the complexity that app devs are managing, freeing them up to focus on continuing to grow their great app into a great app business. With AdMob SDK 6.0, app developers can:

Use multiple ad networks
We recognize that many app devs work with several ad networks to maximize fill rates, and ultimately, revenue. AdMob SDK 6.0 makes it easier to do this with our free AdMob Ad Network Mediation solution which allows app developers to allocate inventory across many top 3rd party ad networks on a country-by-country basis. App devs will retain full control and choice over the ad networks they use with a single UI that features the best-in-class AdMob reporting. For more information on AdMob Ad Network mediation, visit the AdMob Help Center.

Get banner ads to be smart, regardless of screen size
New mobile device screen sizes pop up every day, but app developers shouldn’t have to worry about how banner ads will appear on different devices. AdMob SDK 6.0 eliminates this issue with the introduction of new banner ad formats that automatically expand to the full width of any smartphone screen, even in landscape mode. To learn how to implement these new banners, visit the AdMob Developer Site.

Serve more rich media ads
The lack of industry standards for mobile rich media ads has been a barrier for advertisers and made it challenging to app devs to run more of these engaging ads in their apps. The new AdMob SDK 6.0 is compliant with Mobile Rich Media Ad Interface Definitions (MRAID), a common API for mobile rich media ads running in mobile apps. This is a big step forward in reducing complexity as it establishes a standardized set of commands for developers creating rich media ads. It also means that advertisers will be able to build mobile rich media ads that can be served across networks regardless of device platform, application or technology used to display the media.

As we announced several weeks ago, the iOS version of the Google AdMob SDK no longer uses the universal device identifier (UDID). We are working toward a long-term solution that will benefit users, app developers and advertisers.

To learn more about how app devs can work with AdMob to build a great app business through monetization and promotion of their app, visit our new AdMob website.

Posted by: Chrix Finne, Product Manager, Mobile Ads

The Docs are Dead. Long Live the Docs!

2012-04-19T04:36:00.003-07:00

Recent visitors to any of the Ads API documentation pages will have noticed their shiny new appearance and a message to let you know the docs have moved to a new platform:

This move is much more than a skin-deep makeover. As we’ve blogged before, the new Google Developers platform is so named to reflect our focus on you, and not just on the tools we provide.

Follow the links below to take a look at the full range of Ads API docs on Google Developers:

We’ll continue to try to improve the Ads API docs on Google Developers while, over time, Google Code returns to its original purpose as an open source project hosting service. Visits to the old Google Code docs will be redirected to the corresponding Google Developers docs throughout 2012, so be sure to update your bookmarks soon.

If you have any questions about these changes please reach out to us through any of the Ads API forums or office hours.

Lesley Burr, Ads Developer Relations Team

AdWords API - Updates in Ad Performance Report

2012-04-16T14:10:00.000-07:00

Recently the Ad Performance Report and AdGroupAdService of the AdWords API were returning incomplete data from Dynamic Search Ads. The report and API service were not prepared to support this type of Ad, which resulted in the report returning an undocumented “Website Ad” type, and the service returning AdGroupAd objects with no set ad property. This issue was fixed as of March 20th. We apologize for any inconvenience this change might have caused.

Note that even though Dynamic Search Ads are no longer returned in the Ad Performance Report, their performance data (i.e. impressions, clicks, conversions) is rolled up in reports such as the Account, Campaign and Ad Group performance reports.

If you have any questions about this change please reach out to us in the forum or during one of our office hours hangouts.

- The AdWords API Team

Changes to advanced location targeting

2012-04-09T11:15:00.000-07:00

Last year we exposed advanced location targeting settings in the AdWords API, using the GeoTargetTypeSetting object. Based on customer feedback we are now rolling out a series of changes to improve the power and clarity of this feature. The full details of these changes can be found on the Inside AdWords blog, but some highlights are:

The advanced location targeting settings now apply to Display Network traffic in addition to Google Search and the Search Network traffic.
The default value of the exclusion setting will be more restrictive for new campaigns, taking into account both the physical location and the area of interest. In API terms, GeoTargetTypeSetting.negativeGeoTargetType will default to DONT_CARE for new campaigns. The value will not be updated for existing campaigns.
The AdWords web interface has reworded the language used to describe these settings. If you provide a user interface you may want to update your language as well.

If you have any questions about these changes please reach out to us in the forum or during one of our office hours hangouts.

- Eric Koleda, AdWords API Team

Processing updates in bulk with MutateJobService

2012-04-04T04:57:00.000-07:00

The AdWords API is designed to handle a high volume of changes, and many services allow developers to submit a large number of operations in one request. Most of the AdWords API services are synchronous though, so the client sends the request to the server, waits for processing and receives the result back.

Unlike other services, the MutateJobService (MJS) is designed for an asynchronous workflow. This has the following benefits:

No need to manage connections for each job - the job is executed autonomously and the results can be retrieved when ready.
Multiple jobs can be submitted and executed in parallel. In fact, the service has no limit on the maximum jobs count.
Transient errors like 'CONCURRENT_MODIFICATION' are automatically retried with no extra requests necessary.
Workload is automatically balanced so you will never receive a 'RateExceededError' error.

Also, MutateJobService operations cost only 50% of usual operations units cost.

Using MutateJobService in existing applications

Replacing existing calls to synchronous services with calls to MJS is easy. In most cases you can just use the same operations array to submit a job. Once submitted, the application needs to check the job status periodically to see when it is complete. Once ready, the results can be retrieved with the getResult method.

Please see examples in Java, PHP, Perl, DotNet, Ruby and Python for more details.

Recommendations:

Don't poll for job status too often as this can result in RATE_EXCEEDED_ERROR error. We recommend pausing for 5-30 seconds between get requests.
Although there is no minimum number of operations for a MJS job, it is more effective to send at least 100 operations per job. You can send up to 10,000 operations in one job.
When submitting a job that operates on multiple AdGroups and Campaigns, try grouping operations in such a way as to minimize the number of different AdGroups in one job.

Note: while the old BulkMutateJobService is still available we recommend to use the MutateJobService for all future developments.

MutateJobService is covered in more details in our video presentation: Efficient API Usage with the MutateJobService. As always, please feel free to ask any questions regarding the AdWords API on our forum or during scheduled office hours.

- Danial Klimkin, AdWords API Team.

Creating A GADBannerView Singleton in AdMob Applications

2012-04-03T16:12:00.001-07:00

View controllers in iOS such as UITabBarController and UINavigationController allow users to navigate between screens quickly. Developers using these controllers often hesitate to create new GADBannerViews for each screen because the user may not spend enough time on each screen to see the ad, thus diluting their click-through rate (CTR). A nice alternative here is to use a singleton GADBannerView across the entire application. This blog post will outline the steps to get this up and running.

Initialization

Create a class that wraps around GADBannerView to add some minimal functionality. We’ll call this class GADMasterViewController in our example. Define your header file to have properties similar to what’s below:

@interface GADMasterViewController : UIViewController {
  GADBannerView *adBanner_;
  BOOL didCloseWebsiteView_;
  BOOL isLoaded_;
  id currentDelegate_;
}

You need to provide a static accessor method in your GADMasterViewController class:

+(GADMasterViewController *)singleton {
  static dispatch_once_t pred;
  static GADMasterViewController *shared;
  // Will only be run once, the first time this is called
  dispatch_once(&pred, ^{
    shared = [[GADMasterViewController alloc] init];
  });
  return shared;
}

You also need an init: method in GADMasterViewController. You can now initialize the GADBannerView normally. Presume the initialization gets called only once:

-(id)init {
  if (self = [super init]) {
   adBanner_ = [[GADBannerView alloc]
                     initWithFrame:CGRectMake(0.0,
                                              0.0,
                                              GAD_SIZE_320x50.width,
                                              GAD_SIZE_320x50.height)];
    // Has an ad request already been made
    isLoaded_ = NO;
  }
  return self;
}

Placing the Ad

Write a method which takes a new view controller and places the GADBannerView into that view controller’s view hierarchy. Again, this code will go into GADMasterViewController. This will be called every time you want to display an ad inside a different view controller:

-(void)resetAdView:(UIViewController *)rootViewController {
  // Always keep track of currentDelegate for notification forwarding
  currentDelegate_ = rootViewController;

  // Ad already requested, simply add it into the view
  if (isLoaded_) {
    [rootViewController.view addSubview:adBanner_];
  } else {

    adBanner_.delegate = self;
    adBanner_.rootViewController = rootViewController;
    adBanner_.adUnitID = kSampleAdUnitID;

    GADRequest *request = [GADRequest request];
    [adBanner_ loadRequest:request];
    [rootViewController.view addSubview:adBanner_];
    isLoaded_ = YES;
  }
}

At this point, putting an ad into a view that’s not the GADMasterViewController becomes extremely easy. The code can go into any view controller’s viewWillAppear: method (assuming the view conforms to the GADBannerViewDelegate protocol):

- (void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    shared = [GADMasterViewController singleton];
    [shared resetAdView:self];
}

Forwarding Delegate Notifications

An important note is that the AdMob SDK doesn’t let you change delegates after a request has been made. This means that if you switch view controllers after making an ad request, all GADBannerViewDelegate notifications will continue to be sent to the initial delegate (first view controller). A workaround for this is to make GADMasterViewController conform to the GADBannerViewDelegate protocol, then forward any notifications it receives to the correct view controller. This is the reasoning behind always setting currentDelegate_ in resetAdView:. Forwarding the notification takes minimal code. Here is an example of forwarding the adViewDidReceiveAd: notification:

- (void)adViewDidReceiveAd:(GADBannerView *)view {
  // Make sure that the delegate actually responds to this notification
  if  ) {
    [currentDelegate_ adViewDidReceiveAd:view];
  }
}

With these easy steps, your application is set up to use a singleton GADBannerView. If you have any questions about this topic or the SDK in general, feel free to post them in our forum or come join us in our upcoming office hours.

- Raj Parameswaran, AdMob Team

Announcing Google AdMob Ads SDK 5.0.8

2012-03-30T13:11:00.000-07:00

Editor’s note: We’d like to share this post from Mark Schaaf which announces v5.0.8 of the Google AdMob Ads SDK for iOS. -- Eric Leichtenschlag, Ads Developer Relations Team

For developers who want to run ads in iOS versions of their apps, we are releasing an update to our Google AdMob Ads SDK. This new version of the SDK is consistent with Apple’s reported decision regarding developer usage of the universal device identifier (UDID). Our goal is to help all developers and publishers continue to reach users on mobile, grow their businesses and make money, in accordance with the policies of the mobile platforms on which they build.

Developers and publishers building their businesses on the iOS platform can download the new SDK here. Stay tuned for more new SDK features and updates in the coming weeks.

Posted by: Mark Schaaf, Google Mobile Ads

Brushing up on DFP API Forecasting

2012-03-30T12:28:00.000-07:00

With the addition of the new test networks to replace the sandbox environment networks, we’d like to do a review of how to test your forecasting on test networks. Since the test networks don’t serve ads, you have no traffic history to provide forecasting data. Instead, the API returns predictable results in the Forecast object so you can effectively test your application.

Forecast Service with Test Networks

The forecast service can be used by calling getForecast with a new line item or getForecastById with the ID of an existing line item. In production, these calls will tell you whether you can expect the line item to deliver the booked clicks/impressions based on how your network’s done in the past. In the test network, the only two parameters that affect the forecast results are the lineItemType and unitsBought fields on the line item. The expected responses are summarized below and in our documentation.

Input (Line Item Field)		Output (Forecast Field)
lineItemType	unitsBought	availableUnits	forecastUnits (matchedUnits)	deliveredUnits
Sponsorship	50	1,200,000	6,000,000	600,000 prospective: 0
Sponsorship	!= 20 and != 50	1,200,000	1,200,000	600,000 prospective: 0
Not Sponsorship	<= 1,000,000	unitsBought * 2	availableUnits * 3	600,000 prospective: 0
Not Sponsorship	> 1,000,000	unitsBought * 2	availableUnits * 3	600,000 prospective: 0

It is a good idea to include a test case where the forecasting service throws an exception so your application can handle error conditions correctly. You can trigger the service to throw a SERVER_NOT_AVAILABLE error by setting the line item type to sponsorship and the units bought to exactly 20.

Dealing with Production Quota

In addition, please be mindful that in production (as opposed to test networks), forecasting is a resource intensive process on the server and too many back-to-back requests may cause the API to throw an EXCEEDED_QUOTA error. When this occurs, we recommend backing off briefly before retrying to bring the requests per second down. Recall that the quotas are based on the number of requests per second rather than an absolute number of requests. You are less likely to get rate limited by the API with a steady stream of requests rather than with short bursts of many requests.

We appreciate any feedback from you regarding features you’d like us to highlight or about the API in general. Please don’t hesitate to leave us a suggestion on our forum or come chat with us at one of our DFP API Office Hours Hangouts.

- Jeffrey Sham, DFP API Team

Announcing new Ad Exchange developer resources

2012-03-29T14:44:00.000-07:00

The Ad Exchange Team is excited to make this set of resources available to our developer community. Below you’ll find new and better ways to work with the Ad Exchange. If you have any questions or feedback, please contact us via the forum.

New website

Built on top of Google’s new developers platform developers.google.com, we’ve created a new site for our community. There you’ll find docs for the real-time bidding (RTB) protocol, the REST API and the SOAP API. Plus, we’ve revamped the docs to make them easier to use and understand.

Access to the Ad Exchange REST API

This API gives you the ability to manage your RTB account configurations, submit creatives and list direct deals. Contact your technical account representative to set up access to the API. Then, try it out before you write a line of code, using the API explorer.

Client library support and code examples in major programming languages

Trying out the client libraries first might save you a lot of time compared to coding directly against the APIs. Also, check out our code examples in your preferred programming language for both the SOAP and REST APIs.

Access to the Ad Exchange Buyer API’s Forum

The Ad Exchange Buyer APIs Forum is a Google-monitored environment for public discussions where you can ask - and, if you like, answer - questions regarding the REST and SOAP APIs.

- David Torres, Ad Exchange Team