Category Archives: Google Ads Developer Blog

The blog for information about the AdWords, AdSense, DoubleClick and AdMob APIs and SDKs.

Sunsetting CONVERSION DURATION THRESHOLD feed placeholder in AdWords API

If you use AdWords call extensions, you know that you can count phone calls as conversions based on the duration of the call (e.g., 60 seconds). When using AdWords API feeds, this duration threshold is specified as the CONVERSION DURATION THRESHOLD placeholder. This placeholder is sunsetting on April 7th, 2014. You will not receive errors if you continue to read and set values associated with this placeholder. However, these values will not be honored past the sunset date.

How do I set conversion duration threshold in the future?
After the sunset date, if you’d like to continue using conversion duration threshold, then you must upgrade to the AdWords API v201402:
  • Use the ConversionTrackerService to create an AdCallMetricsConversion
  • Set the call duration threshold in the AdCallMetricsConversion.phoneCallDuration field
  • Use the new CONVERSION TYPE feed placeholder and setting the feed attribute value to the value of the newly created AdCallMetricsConversion.Id
Note: CONVERSION TYPE placeholder is not available for use at the time of this post. We will make a separate announcement when it’s ready.

What will happen to my existing conversion duration threshold values?
If you used CONVERSION DURATION THRESHOLD in a Feed Mapping prior to the sunset date, then we will automatically migrate those values after the sunset date - and they will be accessible via the AdWords API v201402 as follows:
  • New AdCallMetricsConversion will be automatically created for you with the existing conversion duration threshold.

    Note: If you have 3 feed items with call duration threshold, where two of them are set to 120 seconds, and one of them are set to 30 seconds, then only two AdCallMetricsConversion will be created - one with AdCallMetricsConversion.phoneCallDuration set to 120 seconds, and another one set to 30 seconds.
  • Feed attributes using CONVERSION DURATION THRESHOLD will remain, setting and reading those values will not throw errors. However, any associated feed attribute values will not be honored.
  • A new feed attribute will be automatically created in your existing feed, and it will be automatically be mapped to the new CONVERSION TYPE placeholder type
  • The new conversion type feed attribute will be associated to the newly created AdCallMetricsConversion
Note that in order to get the name and field attribute ID of the newly created conversion type field attribute, you should use the FeedMappingService to determine the feed attribute ID that is associated with the CONVERSION TYPE placeholder type.

If you have any questions about this upcoming change or anything else related to the AdWords API, please contact us on the AdWords API forum or via the Google Ads Developers Google+ page.

- , AdWords API Team

New Statement Builder Features in the DFP .NET Library

Good news for .NET DFP developers - working with PQL just got easier. Additional features have just been added to the statement builder in the .NET client library. You can now use a more fluent interface to construct and modify PQL statements in parts. This allows for better query validation and code that's easier to construct: 

// Using the statement builder with the PQL service
StatementBuilder statementBuilder = new StatementBuilder()
    .Select("Id, Name")
    .From("Line_Item")
    .Where("isMissingCreatives = :isMissingCreatives")
    .OrderBy("id ASC")
    .Limit(StatementBuilder.SUGGESTED_PAGE_LIMIT)
    .AddValue("isMissingCreatives", true);

These changes also make modifying and reusing your statements much easier. For example, when paging through result sets you can update the offset without having to alter the entire query. This makes paging quick and easy. 

// Using the statement builder with getCreativesByStatement
StatementBuilder statementBuilder = new StatementBuilder()
    .Where("advertiser_id = :advertiserId")
    .OrderBy("id ASC")
    .Limit(StatementBuilder.SUGGESTED_PAGE_LIMIT)
    .AddValue("advertiserId", myAdvertiserId);

CreativePage page;
do {
  page = creativeService.getCreativesByStatement(
      statementBuilder.ToStatement());
  if(page.results != null)  {
    foreach (Creative creative in page.results) {
      Console.WriteLine("Creative ID: {0}", creative.id);
    }
  }
  statementBuilder.IncreaseOffsetBy(StatementBuilder.SUGGESTED_PAGE_LIMIT);
} while (statementBuilder.GetOffset() < page.totalResultSetSize);

Migration

If you're already using the statement builder, no immediate changes are needed. The previous functionality is still available, although it is now marked as obsolete.

The only pitfall comes with mixing functionality. If you set the statement builder's query directly, don't attempt to set parts of the query individually. Likewise, if you're building the query in parts, direct access is not allowed.

Stick with one usage or the other - mixing the two will give you an IllegalOperationException.

For more information, you can check out the out the source or examples. If you have any questions about the new statement builder features, feel free to ask us in the developer forum or on our Google+ Developers page.

 - , DFP API Team

Reminder: New filter limits for Adwords API and scripts

As previously announced, AdWords API v201309 and AdWords scripts will start enforcing a limit of 10,000 matching values as arguments for the IN and NOT_IN operators starting March 31, 2014. This limit is currently enforced in AdWords API v201402.

You may be affected by this change if you construct large AWQL queries or selector predicates that have thousands of matching values using these operators in one of these use cases:

To make sure your applications and scripts work properly, check any code that constructs queries for reports or retrieve items using get or query methods and add necessary limit checks before March 31, 2014.

If you have any questions about this change, you can post them on AdWords API or Scripts developer forums. Anash P. Oommen, AdWords API Team

Important updates for flexible conversion counting options in v201402 of AdWords API

We recently announced a new flexible conversion counting option feature in AdWords that may affect AdWords API v201309 users. There are a couple of additional changes in the AdWords API v201402 that we want to bring to your attention so you can take full advantage of this offering:
  • Record conversion values in conversion report columns based on the flexible conversion counting option
  • Retrieve and set flexible conversion counting options in the ConversionTracker
  • Adopt new conversion-related column names in the reports

Flexible conversion counting option

Since February 25th, 2014, AdWords users have been able to change the conversion counting option between All Conversions and Unique Conversions. The conversion counting option is defaulted to All Conversions - when left as the default option, your conversion related values in the reports will not change.

If the conversion counting option is changed from All Conversions to Unique Conversions, then the following conversion-related report columns will reflect the counting option selected across all reports:
  • ConversionsManyPerClick
  • ConversionRateManyPerClick
  • CostPerConversionManyPerClick
  • ValuePerConvManyPerClick
  • ValuePerConversionManyPerClick
  • ConversionManyPerClickSignificance
  • ConversionRateManyPerClickSignificance
  • CostPerConversionManyPerClickSignificance
Please see the help center article for specific examples of how counting Unique Conversions differs from counting All Conversions.

Retrieve and set flexible conversion counting options

In the AdWords API v201402, you will be able to retrieve and set the flexible conversion counting option. Please review the ConversionTracker API documentation to see the new flexible conversion counting options field named countingType.

New conversion-related column names

Conversion-related columns will have new names in reports. In AdWords API v201402:
  • The selector field names will remain the same
  • The display names and XML attribute names will be renamed
If you are downloading XML reports, you will need to update your client application to read the new column names.

Please see the migration guide for a mapping between old and new display names and XML attribute names.

If you have any questions about this upcoming change or anything else related to the AdWords API, please contact us on the AdWords API forum or via the Google Ads Developers Google+ page.

- , AdWords API Team

Announcing v201402 of AdWords API

Today we are announcing the AdWords API v201402. This latest release introduces support for Shopping campaigns, extensions to feed services, new reports, and more! We have also made most of the features previously marked as Beta available for everyone.

v201402 highlights:
Note: ClientLogin authorization protocol is deprecated and no longer supported in versions v201402 and later. You need to migrate to OAuth2 to be able to use AdWords API v201402 and access these new features.

If you are still using v201306 of the AdWords API, please note that it is being sunset on March 31st, 2014; we encourage you to skip v201309 and migrate straight to v201402. If you’re using v201309, be aware it is now marked deprecated and will be sunset on July 21st, 2014.

As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201402 migration guide. The updated client libraries and code examples will be published shortly. With this release, we have also updated the Required Minimum Functionality document to include some of the newly added features that are now required in third-party tools. If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.

-Danial Klimkin on behalf of AdWords API Team.

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.

 - , DFP API Team

Join us at the Game Developers Conference!

When we’re not guiding a tiny bird across a landscape of pipes on our phones, we’re getting ready for our biggest-ever Developer Day at this year’s Game Developers Conference in San Francisco. On Tuesday 18 March, all the teams at Google dedicated to gaming will share their insights on the best ways to build games, grow audiences, engage players and make money. Some of the session highlights include:

  • Growth Hacking with Play Games
  • Making Money on Google Play: Best Practices in Monetization
  • Grow Your Game Revenue with AdMob
  • From Players to Customers: Tracking Revenue with Google Analytics
  • Build Games that Scale in the Cloud
  • From Box2D to Liquid Fun: Just Add Water-like Particles!

And there’s a lot more, so check out the full Google Developer Day schedule on the GDC website, where you can also buy tickets. We hope to see you there, but if you can’t make the trip, don’t worry; all the talks will be livestreamed on YouTube, starting at 10:00am PDT (5:00pm UTC).

Then from 19-21 March, meet the Google teams in person from AdMob, Analytics and Cloud at the Google Education Center in the Moscone Center’s South Hall (booth no. 218), and you could win a Nexus 7.

Posted by Greg Hartrell, Lead Product Manager

Call metrics from AdWords API will be disabled by default

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.

 - , AdWords API Team

Deprecation of the default namespace in the AdSense Management API

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.

- , AdSense API Team