[go: nahoru, domu]

We understand the importance of documentation when navigating a system as complex as the AdWords API. For this reason, we would like to remind you about the reference materials available on our Developers site

First off, we’ve updated the Selector Fields page that provides information about the fields that can be used in generic selectors. This information is available on an object’s individual reference page, but we’ve collected it together across entire services for quicker lookups.

Next, we’ve added more columns to the Report Types page to include a field’s type, its behavior, and its XML and display names. The behavior of a field in the generated report describes its effect on zero impression rows as well as whether the field represents historical data or the latest object state.

Finally, we’ve added new tips to our Best Practices Guide on topics such as grouping batch job operations by ad groups and campaigns and using the partial failure feature. The guide is a great resource for developers starting an AdWords API project, but is also useful for established developers trying to increase the efficiency of their applications.

There is a feedback link on the top right hand corner of every page where you can report documentation issues. For technical help, visit our forum or office hours. You can also follow the Google Ads Developer page for all Ads-related updates.


Today we’re happy to announce the launch of the new DoubleClick Ad Exchange Seller REST API. With it, you can list your inventory and programmatically run reports, opening up possibilities such as:
  • checking out how much money you made last month, on your phone
  • adding stylish charts to your earnings reports
  • making your own reporting interface, suited to your specific needs
  • using real ad unit or channel performance data in your internal systems, to help with business decisions.
This API, like all of our new APIs, is built on the same RESTful, standards-based technology stack you’re used to. This means you have access to all sorts of useful tools for trying out the API, such as the APIs explorer (which is also built into the documentation for each method), and our generic, cross-API client libraries.

Give it a try, and let us know if you have any questions!

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

Apps are a powerful way to keep your most loyal users engaged, and can also be a real driver of revenue for marketers big and small. When advertising apps, the key is to know what’s working and what’s not. While advertisers have already been able to measure their Android app downloads within AdWords, we’ve now launched the ability to track iOS downloads that were driven by in-app display ad campaigns.

To set up iOS conversion tracking, advertisers need to create a single code snippet in their AdWords account and install it in their app. This snippet is accessible in the AdWords interface in the same place where advertisers have been able to codelessly track Android downloads. With iOS conversion tracking, marketers can better understand which campaigns are most effective at driving app downloads. These enhanced insights help marketers iterate on app promotion strategies to reach their return on investment goals, with the help of features like the Conversion Optimizer for apps.

Figuring out what ads are working is key for marketers like Sho Masuda, Vice President of Player Marketing for GREE, a leading mobile social game app developer. GREE has used click to download and in-app advertising solutions with AdWords to promote their app, and Masuda says, "Google’s host of tracking and optimization tools help us quickly iterate and maximize ROI across our app promotion campaigns. iOS conversion tracking will help us gain even deeper insights into our Google app promotion efforts for our iOS apps.

If you’d like to learn more about how to track value beyond the app download, you can watch a recording of our Learn with Google webinar “Understanding your App Users with Google Analytics” here.

Since releasing version 6.2.0 of our Android SDK on Tuesday, we have identified a high priority bug which causes apps to crash when our SDK returns certain types of ads. We’ve made a server-side fix which stops the crash-inducing ads, and are also issuing an SDK hotfix to prevent any similar issues from happening in the future.

Please download the new 6.2.1 SDK here and update your apps at your earliest convenience. And Happy Friday from AdMob!

Posted by Chrix Finne, Product Manager

This is a reminder that on Friday October 26th, 2012, the following versions of the AdWords API will be sunset:
  • v201109
  • v201109_1
Calls made to these versions after Friday October 26th, 2012 will fail. It is therefore critical that you migrate to AdWords API v201206 or later if you want your applications to continue to run without interruption.

If you have any questions about these sunsets or about the AdWords API in general, please post on the forum. Follow our Google+ page for updates about the AdWords API.


Good news, everyone! Version 1.2 of the AdSense Management API is now available, and with it come two new features:
  • the ability to retrieve saved ad styles
  • the ability to retrieve and run saved reports

In addition, we’ll soon be deprecating versions 1.0 and 1.1. These will both be sunset six months from now, on April 17, 2013. Migration to the new version should be extremely simple, since version 1.2 is a superset of both previous versions, with no breaking changes.

If you have any questions or comments, let us know in the forum!


We’re excited to announce the release of the AdMob SDK v6.2.0 for Android and v6.2.1 for iOS. The iOS update is mostly a bugfix release, but now requires you to link against the StoreKit framework, which will allow us to experiment with innovative ad experiences. The Android release includes changes to DFP App Events and Custom Events that we’ll discuss below.

DFP App Events

The Android AppEventListener interface has changed slightly to include the ad that fired the app event. The new interface definition is:

public interface AppEventListener {
  void onAppEvent(Ad ad, String name, String info);
}

If you previously implemented onAppEvent(String name, String info), you’ll have to update this method signature when upgrading to v6.2.0.

Custom Events

Due to popular demand, we’ve added the ability to pass information to your custom event. We’ve also added a destroy() method so you can clean up your custom event. The new CustomEventBanner interface definition is:

public interface CustomEventBanner extends CustomEvent {
  void requestBannerAd(CustomEventBannerListener listener,
                       Activity activity,
                       String label,
                       String serverParameter,
                       AdSize size,
                       MediationAdRequest mediationAdRequest,
                       Object customEventExtra);
  void destroy();
}
The customEventExtra object is sent to your custom event by creating an instance of CustomEventExtras and passing it to the AdRequest. The following example sends the string “hello custom event” to your custom event class:
final String CUSTOM_EVENT_LABEL = “MyCustomEventLabel”;
AdRequest adRequest = new AdRequest();
CustomEventExtras extras = new CustomEventExtras();
extras.addExtra(CUSTOM_EVENT_LABEL, "hello custom event");
adRequest.setNetworkExtras(extras);

When calling CustomEventExtras.addExtra(), make sure the key is the same as the label of the custom event you defined in the AdMob UI. The AdMob SDK searches CustomEventExtras for the object corresponding to the label of the custom event, and invokes requestBannerAd on your custom event class with that object. You can call addExtra() for each custom event class you have, and AdMob Mediation will send the appropriate object to the custom event it invokes. If AdMob can’t find an object for your custom event label, it will pass null to requestBannerAd().

A destroy() method has also been added to the custom event interface so you can perform any necessary cleanup. The AdMob Mediation framework will invoke destroy() when it refreshes the AdView.

Check out the release notes for the full list of changes in this version. If you have any questions about the latest AdMob SDK, please reach out to us on the forum or join us for AdMob office hours. You can also follow us on the Google Ads Developer plus page for AdMob-related updates.

With November on the horizon, we’d like to remind DFA API users of two important upcoming changes. Both of these changes were previously announced in August.

Java DART API Version Enforcement

To give you the best experience connecting to ReportCentral, it has become necessary to stop supporting older versions of the Java DART API. Starting November 3rd, 2012, we will only accept requests from the 3 latest versions, which are currently 13.4, 13.6, or 13.8. We have continued to improve our DFA Reporting API and still recommend all users switch to this new offering as soon as possible.

Removal of our Deprecation Policy

Also on November 3rd, 2012, our deprecation policy will no longer be in effect. Our commitment to our APIs and our users remains strong, and we will strive to announce all changes to our APIs long before they launch.

Please feel free to post any questions or concerns you may have on our forum.

In an effort to continue to improve report download functionality in the AdWords API, we’ve made some changes in v201209 to improve error handling and debugging for developers. In a future release, we also plan to separate API downloads from UI downloads to make the downloaded reports easier to work with for developers.

In v201209 we’ve introduced a new XML format for report download errors. Currently, we return a text string with the error message embedded within it. For example, if you mispelled the field Date as Datee:

!!!2|||-1|||ReportDefinitionError.INVALID_FIELD_NAME_FOR_REPORT @ ; trigger:'Datee'???

In v201209, this error will be returned in this XML format (HTTP response codes will remain unchanged):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<reportDownloadError>
<ApiError>
<type>ReportDefinitionError.INVALID_FIELD_NAME_FOR_REPORT</type>
<trigger>Datee</trigger>
<fieldPath/>
</ApiError>
</reportDownloadError>


The new error reporting format will make it easier to handle report download failures. If you’d like to preview these changes, you can pass this special HTTP header when downloading reports for versions prior to v201209:

apiMode: true

Support for this new XML error format will be added to client libraries for v201209. We’ve also published an XSD including this new report download error XML at:

https://adwords.google.com/api/adwords/reportdownload/vYYYYMM/reportDownloadError.xsd

For v201209, you can see it here. Some other things to keep in mind with these new changes:
  • Remember to make sure you provide the version in the report download URL. With the next major release (and when specifying this new HTTP header), version will be required when downloading reports.
  • AdHoc reports must be used - it will no longer be possible to download by reportDefinitionId.
If you have any questions about this new XML format or the AdWords API in general, please post on the forum. Follow our Google+ page for updates about the AdWords API.

Update: The sunset of v201206 is now moved to March 25th, 2013.

We’re pleased to announce the launch of AdWords API v201209, which includes the ability to share budgets across multiple campaigns, set up demographic targeting at the ad group level, opt into a rotate indefinitely option for ad text, as well as some reporting changes that make errors clearer. Below we’ve highlighted some of the new features available to all users. A complete list of changes is available in the release notes.

v201209 highlights:

  • Shared budgets - The AdWords API now supports sharing budgets across campaigns through the new BudgetService and top-level Budget entity. All budgets are now potentially shareable so you need to first create a budget that is not associated with any particular campaign, and then assign campaigns to this budget via CampaignService. 
  • Rotate indefinitely - CampaignService now has a fourth option for the ad rotation setting called ROTATE_INDEFINITELY. Read more about it in this announcement
  • Ad group-level demographic targeting - Demographic targeting criteria (Age Range and Gender) are now available at the Ad group level (positive and negative). Note that you can continue to set negative targets at the Campaign level. 
  • Reports - A new XML format is being introduced to report download error responses that makes it easier to parse the error messages. Also, report downloads using reportDefinitionId are no longer supported, and a valid AdWords API version must now be supplied in the URL for all report download requests. 

With the release of v201209, we are deprecating v201206 and sunsetting it at the end of February 2013.

As with every new version of the AdWords API, we encourage you to review the resources in the release notes. If you have any questions please post on the forum or attend one of the AdWords API Office Hours Hangouts.

- The AdWords API Team

An authorization method is a scheme the client application uses to gain access to account information. AdWords, DoubleClick Ad Exchange Buyer and DFP APIs support several authorization methods including ClientLogin, OAuth1.0a and OAuth2.0. If you are still using an email address and a password to access the API, you are using the ClientLogin method which is now deprecated and is scheduled for sunset.

In a previous blog post we’ve covered general aspects of OAuth2.0 authorization and its benefits. To describe the process in more details, we’ve created a new article that shows how to use it with our official Ruby client library.

As always, please feel free to ask any questions regarding the client libraries or the AdWords API on our forum or during scheduled office hours. You can also follow the Google Ads Developer page for all Ads-related updates.