Google Ads Developer Blog: Deprecation of the default namespace in the AdSens...

Google Ads Developer Blog: Deprecation of the default namespace in the AdSens...: TL;DR Projects using the AdSense Management API should now check for accounts with multiple AdSense/AdX accounts and let users pick instead of using the default namespace, as it will be disabled for some accounts.

API users with access to more than one AdSense or AdX accounts will receive an error when using the default namespace due to cases of ambiguity. We expect a very small percentage of users to have this problem, as this functionality is restricted to a limited set of accounts.

To avoid complications, make sure you're not using the default account namespace adclients.list, adunits.getAdCode, etc. and specify an account ID for every call. For that, use accounts.adclients.list, accounts.adunits.getAdCode, etc. You’ll find the whole list of calls in the API reference pages.

The flow you should always use from now on is:

• Authenticate
• Call accounts.list
• Show a publisher account picker if there's more than one account
• Do the rest of the requests using the account ID

If you have questions about this change or need help with updating your code, please let us know on the AdSense API forum or our Google+ page.

Google Ads Developer Blog: Call metrics from AdWords API will be disabled by ...

Google Ads Developer Blog: Call metrics from AdWords API will be disabled by ...:
AdWords API users in the United States, United Kingdom, Germany, France and Spain who have been using call metrics with call extensions may be affected by a change we are rolling out starting on March 3rd, 2014.
Previously, the default was to enable call metrics when the TRACKED placeholder was not included as an AttributeFieldMapping in the CALL Feed. We will be updating how this works by enabling this feature only when specifically requested. You can still enable call metrics, if available in your country, when setting up the call extension or modifying an existing extension with this placeholder.
This change may affect your current call extensions. Any call extensions that have not explicitly enabled call metrics will stop collecting metrics starting on March 3rd. If you rely on call metrics data, you should make sure that all of your call extensions have explicitly enabled call metrics. If you were already setting this flag when creating call extensions in any version of the API, then no further action is required.
If you have any questions about this upcoming change or anything else related to the AdWords API, please contact us on the forum or via our Google+ page.

Google Ads Developer Blog: Announcing v201403 of the DFP API

Google Ads Developer Blog: Announcing v201403 of the DFP API: Today, we launch v201403 of the DFP API. This important release focuses our API by removing non-bulk methods and introduces some crowd favorite features like creating VAST video redirect creatives. A detailed list of these features and what’s changed can be found on our release notes page. Also, stay tuned for a special hangout on March 24th where we’ll go over all of these new features and discuss some common topics brought up on our forum.

Bulking up

Starting in v201403, we've removed all non-bulk methods from the API, such as OrderService.getOrder and LineItemService.createLineItem. The goal of this is to encourage you to think about your applications holistically. Instead of fetching a single order, sync orders regularly using lastModifiedDateTime and instead of creating or updating a single line item, group them together, e.g. create all orders first, then line items, and then creatives instead of one at a time.

If you do need to fetch a single object, we recommend following the pattern (in Java):

  // Create a statement to only select a single
  // order by ID.
  StatementBuilder statementBuilder =
      new StatementBuilder()
          .where("id = :id")
          .orderBy("id ASC")
          .limit(1)
          .withBindVariableValue("id", orderId);

  // Get the order.
  OrderPage page = orderService.
      getOrdersByStatement(statementBuilder.toStatement());

  Order order = Iterables.getOnlyElement(
      Arrays.asList(page.getResults()));

Notice that you can easily turn this into a function if needed, and possibly implement a caching mechanism.

Creating video creatives

This launch marks our first steps into opening up the writability of video creatives. We are starting with VastRedirectCreatives, video creatives that store the VAST 2 or 3 tag URL on an external server. All other types of video creatives are still read-only for now. We will be looking into opening more externally hosted video creatives in the coming versions and please do let us know what you are looking for on our forum.

ClientLogin gets the axe

You will notice that starting in v201403, you must use OAuth2 to authenticate with the API. Using ClientLogin will result in an error from our servers. We've modified all of our client libraries to throw exceptions if you are using ClientLogin with any non-compatible version. If you need a refresher on how to use OAuth2, see a guide for Java, PHP, .NET, Python, or Ruby.

Look out, deprecation ahead

We are getting closer to the deprecation of v201206, v201204, v201203, v201201, v201111, and v201108. These versions will be turned off on April 1st. If you have not yet, please upgrade to v201403 and OAuth2 as soon as possible. As a Java developer, you will also notice that v201403 is only available in the new Java client library and the old Java library will not receive any further feature enhancements.

As always, if you have any suggestions or questions about the new version, feel free to drop us a line on our Ads Developer Google+ page.

Google Mobile Ads Blog: Moving the mobile conversation to the Inside AdWor...

Google Mobile Ads Blog: Moving the mobile conversation to the Inside AdWor...: Posted by: Google Mobile Ads Team There’s a lot to say about mobile!  In today’s multi-screen world, mobile is a part of everything we do...

Google Ads Developer Blog: Retiring AdSense Management API v1 and v1.1

Google Ads Developer Blog: Retiring AdSense Management API v1 and v1.1: With the release of v1.2 (and the subsequent v1.3) of the AdSense Management API, older versions became deprecated, and we announced we would be retiring them later this year. The turnoff date will be August 12, 2013.

If your application is still using v1 or v1.1, please be sure to update it to use v1.2 ‒ or preferably, v1.3. The new versions build on top of the old ones, so all previous functionality will still be available and work exactly the same, which should make for an easy upgrade.

If you have any questions or need any help, be sure to join us in the forum!

Google Ads Developer Blog: Local time zone reporting in the AdSense Managemen...

Google Ads Developer Blog: Local time zone reporting in the AdSense Managemen...: You may have heard that we launched local time zone reporting for AdSense, a fantastic feature for publishers far from the Pacific Time Zone (PTZ)! On the API side we’ve been asked some questions about it, as in some cases this may lead to the AdSense web interface and the AdSense Management API showing different data.

In Version 1.3 of the AdSense Management API, the report.generate call has a new, optional parameter called useTimezoneReporting. If set to true, the report will be generated in the local time zone configured in the web interface. Note that billing is still based on PTZ, so if you want to fetch actual earnings you may want to make sure that useTimezoneReporting is set to false or you might see small discrepancies.

The default value for this parameter is false resulting in PTZ being respected, as it was before the feature was added. If an AdSense user doesn’t choose a local time zone it will default to PTZ, so this parameter won’t make a difference.

Our recommendation is that developers let users choose if they want reports in their “Billing time zone” or their “Local time zone” (to match AdSense’s terminology).

Bear in mind that users changing their local time zones can generate spikes or dips in the local time zone reports, as it makes the day of the change longer or shorter.
See more from source