Google Ads Developer Blog: March 2014

Monetizing Unity Mobile Apps Just Got Easier

Monday, March 31, 2014

Calling all Unity app developers! We are excited to announce the launch of version 2.0 of the Google Mobile Ads Unity Plugin. The new version comes with a completely rewritten, but much more flexible, API. It includes the following new features:

A single package supporting both Android and iOS

Support for running apps in the Unity editor

Ability to create multiple banner instances

Ability to create banners of any size

Flexible ad request targeting

and much more!

Taking a closer look at how to integrate the plugin, a typical banner request in v2.0 looks like this:BannerView bannerView = new BannerView( "YOUR_AD_UNIT_ID", AdSize.Banner, AdPosition.Top); AdRequest request = new AdRequest.Builder().Build(); bannerView.LoadAd(request); For custom banner sizes, simply pass in an AdSize object into the BannerView constructor:AdSize adSize = new AdSize(250, 250); BannerView bannerView = new BannerView( "YOUR_AD_UNIT_ID", adSize, AdPosition.Top); Want to pass additional targeting parameters? No problem! Set your custom targeting when building the AdRequest:AdRequest request = new AdRequest.Builder() .AddTestDevice(AdRequest.TestDeviceSimulator) .AddTestDevice("0123456789ABCDEF0123456789ABCDEF") .AddKeyword("unity") .SetGender(Gender.Male) .SetBirthday(new DateTime(1985, 1, 1)) .TagForChildDirectedTreatment(true) .Build(); Listening for ad events is also extremely straightforward. Register for the callbacks you care about:bannerView.AdLoaded += HandleAdLoaded; bannerView.AdFailedToLoad += HandleAdFailedToLoad; bannerView.AdOpened += HandleAdOpened; bannerView.AdClosing += HandleAdClosing; bannerView.AdClosed += HandleAdClosed; bannerView.AdLeftApplication += HandleAdLeftApplication; … public void HandleAdLoaded() { print("HandleAdLoaded event received."); } You can also manage the lifecycle of each BannerView by calling show(), hide(), or destroy().To get access to these awesome features, check out the source code. Also stay tuned for upcoming support for interstitial ads.If you have any feature requests or bug reports against the plugin, track it! If you have questions about how to use the plugin, speak up! And if you just want the latest news on what’s going on in the wonderful world of Google Ads, circle us!

- Eric Leichtenschlag, Mobile Ads Developer Relations

Changes Required for Creating New Campaigns in the AdWords API v201402

Friday, March 28, 2014

advertisingChannelType

displaySelect

Enabled networkSettings

Search Network

false

Search Networks only

Search Network with Display Select

true or unspecified

Search & Content networks

Display only

DISPLAY

false or unspecified

Content Network only

Shopping only

SHOPPING

false or unspecified

Search Network only

Any parameter combination other than the above when creating a new campaign or making targeting changes to existing campaigns will be rejected with an OPERATION_NOT_PERMITTED_FOR_CAMPAIGN_TYPE error.

While you can no longer create Search & Display Network campaigns, existing campaigns of this type will remain unchanged. You can identify them by their displaySelect attribute being false, while both the Search and Content Networks are enabled. These campaigns should be migrated to SNDS by setting displaySelect to true.

The advertiserChannelType and isDisplaySelect fields are also present in reporting, so you can see how your Campaigns are configured.

If you have any questions about this change or the AdWords API in general, you can post them on our developer forum. You can also follow our Google+ page for updates about the AdWords API.

- Mark R. Bowyer, AdWords API Team

With v201402 of the AdWords API, it is now necessary to set the advertisingChannelType when you create a new Campaign. As part of this change, the networkSetting attribute is now used to define in more detail where you want your ads to appear.

All newly created campaigns, or campaigns that are switched into targeting both Search and Display using v201402, will automatically be SNDS campaigns. This behavior is the same as you will see in the AdWords User Interface, bringing that and the API into closer alignment. Existing applications are unaffected. As we continue to invest in Search Network with Display Select (SNDS) and see strong adoption from advertisers, we will over time be upgrading Search & Display Network campaigns to Search Network with Display Select.

With the introduction of both SNDS and Shopping campaigns, the new advertisingChannelType field allows you to state which kind of Campaign you're building. The field is an enumeration, which can be set to:

SEARCH, for the Search Network, including (for campaigns created with older API releases) Search and Display hybrids, and now SNDS campaigns;
DISPLAY, for the Google Display Network only;
SHOPPING, for Shopping campaigns serving Product Listing Ads on Google and Google Shopping.

Note that an UNKNOWN value can be returned if the value set isn't supported by the called version of the API. This covers situations where new options are added in newer releases.

This table specifies the only valid combinations of parameters for newly created campaigns on the networks that you intend to target.

Networks Targeted by the settings on the right	advertisingChannelType	displaySelect	Enabled networkSettings
Search Network	SEARCH	false	Search Networks only
Search Network with Display Select	SEARCH	true or unspecified	Search & Content networks
Display only	DISPLAY	false or unspecified	Content Network only
Shopping only	SHOPPING	false or unspecified	Search Network only

- Mark R. Bowyer, AdWords API Team

Support for v201402 Reports in AdWords Scripts

Wednesday, March 26, 2014

We are announcing support for AdWords API v201402 reports in AdWords scripts. The following new reports are available for use:

BID_GOAL_PERFORMANCE_REPORT
PAID_ORGANIC_QUERY_REPORT
PRODUCT_PARTITION_REPORT
SHOPPING_PERFORMANCE_REPORT

You can refer to https://developers.google.com/adwords/api/docs/appendix/reports for the list of supported columns and other details for these new reports.

If you use API versioning in your reports, then you need to modify your code to use v201402 as shown below. If you don’t use API versioning, no code changes are required.

var report = AdWordsApp.report(query, {
   apiVersion: 'v201402'
});

If you have any questions about this feature or AdWords Scripts in general, you can post them on our developer forum.

Anash P. Oommen, AdWords Scripts Team

AdWords API users - don’t wait to migrate from ClientLogin to OAuth 2.0!

Wednesday, March 26, 2014

ClientLogin authentication support for the AdWords API will sunset along with v201309 on July 21st, 2014. But it doesn’t mean you should wait till the last minute to migrate!

We have plenty of resources to help you migrate. It might take longer than expected to migrate to OAuth2, especially if you don't already use a single top-level MCC to manage your AdWords accounts.

Start your migration as soon as possible and reach out to us early on the AdWords API Forum with any questions.

- Ray Tsang, AdWords API Team

New geo targeting options in AdWords API

Friday, March 21, 2014

Building on our AdWords announcement in November 2013, v201402 of the AdWords API supports geo targeting for areas with particular places of interest or income levels. These are useful for reaching customers based on the types of places they visit or demographic information based on their location. Please check the support site for more information, and to determine if these new targeting options are available for the country you would like to target. Within the API, these new criteria types are called LocationGroups and can be applied on a campaign to affect all of its ads.

The targeting can be set up using a matching function, which you may already be familiar with from other parts of the API. There are three new operand types for LocationGroups matching functions. Each matching function will pair one of either IncomeOperand or PlacesOfInterestOperand with a GeoTargetOperand, which is always required, to target income brackets or places of interest within a specific geographical region.

For example, to target airports in New York City using the Java client library, you would set up a matching function using a PlacesOfInterestOperand and a GeoTargetOperand, like this:

LocationGroups locationGroup = new LocationGroups();
Function matchingFunction = new Function();
matchingFunction.setLhsOperand(new FunctionArgumentOperand[] {
    new PlacesOfInterestOperand(null, PlacesOfInterestOperandCategory.AIRPORT)
});
matchingFunction.setOperator(FunctionOperator.AND);
matchingFunction.setRhsOperand(new FunctionArgumentOperand[] {
    new GeoTargetOperand(null, new long[]{ 1023191L }) // ID for NYC
});
locationGroup.setMatchingFunction(matchingFunction);

You can look up geo target IDs via the LocationCriterionService or in the documentation. You can also see fully functional, runnable code demonstrating this criterion type in each client library (Java, PHP, .NET, Python, Ruby, Perl).

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

- Michael Cloonan, AdWords API Team

Bidding on the DoubleClick Ad Exchange with the Google Cloud Platform

Wednesday, March 19, 2014

Real time bidding (or programmatic buying), is one of the fastest growing methods of buying and selling ads online, and is predicted to account for 25% of all display spending by next year. Marketers are embracing this model as it allows them to connect to audiences at scale quickly and we've been making ongoing investments to help them grow their programmatic businesses. Today we're continuing those investments by introducing functionality that enables marketers to conduct their real-time bidding on the DoubleClick Ad Exchange (AdX) directly from Google Cloud Platform.

Speed is critical to success in programmatic buying and many exchanges, including the DoubleClick exchange, require that bidders respond to an ad request within a certain time limit in order to preserve the real-time nature of the marketplace. Real time bidding transactions typically happen within 100 milliseconds from a user visiting a website. Starting today, Ad Exchange users hosting on Google Compute Engine will always receive 100 milliseconds for bid request processing and free network transit from Google Cloud Platform to all Ad Exchange trading locations. This effective increase in processing time, combined with the strengths of Google Compute Engine will make Google Cloud Platform a great choice for DoubleClick Ad Exchange buyers.

To ensure that AdX customers have the best possible experience on Google Cloud Platform, we now offer complimentary Gold support for Google Cloud Platform to qualified customers hosting their bidding infrastructure for AdX. You can find more information on this offer as well as instructions on how to sign up here.

For customers who would like to jump start their real-time bidding using a framework provided by Google, Open Bidder provides you the real-time bidding infrastructure. You can sign up for access to Open Bidder here.

For those looking to build their own bidders without the use of our Open Bidder framework, we’ve also published a white paper on how to build real-time bidding solutions on Google Cloud Platform.

If you are interested in learning more about Open Bidder, real-time bidding on DoubleClick Ad Exchange, and bidder hosting on Google Cloud Platform, please join us at an AdX Developer Day in Google’s New York City or San Francisco office on April 9. You can register for the event here.

Posted by Scott Spencer, Director of Product Management, Doubleclick Ad Exchange
Greg Demichellie, Director of Product Management, Google Cloud Platform

* For trading on the DoubleClick Ad Exchange Hong Kong trading location, please contact Ad Exchange Sales.

Introducing IMA SDK Downloads for FlashDevelop and Flash Builder

Tuesday, March 18, 2014

- Bret McGowen, IMA SDK Team

Using FlashDevelop or Adobe Flash Builder and looking to get started with the IMA SDK? Now it's even easier with new downloads specifically for FlashDevelop and Flash Builder 4.7.

Check out our guide to getting started with the Flash IMA SDK with these IDEs.

Once you've gone through the guide and are up and running with a compiled .swf, what's next? Check out the Flash IMA SDK Quick Start Guide and Flash IMA SDK API Reference docs to learn more about the features of the Flash IMA SDK.

If you have any questions about the Flash IMA SDK let us know on the IMA SDK forum. Follow our Google+ page for other announcements and updates.

- Bret McGowen, IMA SDK Team

Readying AdMob for the Second App Economy with New Features: Livestream from GDC Today

Tuesday, March 18, 2014

In-App Purchase Ad

3. Ad network optimization and Live CPM.
If a developer is using more than one ad network to monetize their apps, a mediation tool helps to manage them. However, these tools may not optimize for the highest revenue. To solve this, ad network optimization obtains the most up-to-date CPMs from ad networks in the AdMob mediation stack, and requests ads from the highest paying one.

Live CPM goes one step further to ensure developers earn the most money from their ad impressions. When a developer uses AdMob to monetize, they get real-time access to all of Google’s demand sources, including programmatic demand, via our integration with DoubleClick Ad Exchange. For each ad request, Live CPM compares the highest CPM a developer can get from Google’s demand sources, with the CPM they could get from other networks in their mediation stack. If a higher-paying ad is available from Google’s demand sources, it will serve that ad over lower-paying CPMs offered by the other networks. App developer iHandy Inc. began using Live CPM in February this year. Many apps' revenues increased at different rates, and certain apps achieved a 200% increase.

4. The App Developer Business Kit.
The App Developer Business Kit is an in-depth website designed to help app developers understand ways to build a successful business. For example, there are detailed chapters about building an app, different ways to earn money, and options for marketing your app. You can also check out the interviews with developers, read case studies and view market insights from AdMob surveys which give developers a head start into building apps for global users. For example, did you know that a third of smartphone gamers in China have spent money in apps to personalize characters?

Tune into Google’s GDC livestream today at 10AM PST. We have sessions for game developers all day, and the AdMob talk is from 12-12.30PM PST.

Posted by Jonathan Alferness, Product Management Director, Google

According to Gartner, more than 130 billion apps will be downloaded onto phones and tablets in 2014, and most of them will be free. At the same time, revenue from apps is expected to grow by over 200% in the next 4 years. That may sound contradictory, but the reason has been clear to many developers for some time: while the first app economy was predominantly focused on paying for apps up front, we’re now seeing the rise of a second app economy, the era of free apps and incremental payments.

In this second app economy, the currency of success has altered significantly, centered on three critical areas:

Understanding audiences: Developers should be able to segment their audiences based on in-app behavior and turn data into useful insights for better monetization.
Growing in-app purchase revenue: According to Gartner, soon in-app purchases will account for almost half of all app store revenues, but this model requires a sophisticated approach from app developers and the right tools haven’t been available.
Maximizing ad revenue: Developers shouldn’t have to worry about managing ads; ads should optimize themselves, in real time, so developers can focus on other important parts of their business.

To help every developer succeed in this new economy, the AdMob team will be at the Game Developers Conference today to share four announcements.

1. Google Analytics now directly available in AdMob.
We introduced mobile app analytics in mid 2012 and there are hundreds of thousands of app developers using it already. We've now built Google Analytics directly into AdMob so developers can understand how people are using their app, segment them based on behavior in just a few clicks, then act on those insights. For example, the Google Analytics ecommerce report shows key insights into in-app purchases: top items sold, overall revenue and average order value. Now that Google Analytics is built directly into AdMob, developers can have a holistic view on their monetization based not only on revenue from ads but also on in-app purchase performance. All these functionalities have been incorporated into the updated Home tab in AdMob, making it a one-stop shop for all your performance reports.

2. In-App Purchase Ads.
To help developers promote in-app purchases to users in a more relevant way, we're also introducing in-app purchase ads. A developer can use these ads to promote in-app items at the right time to the users who are most likely to make a purchase, while still showing AdMob ads to those who aren't. Segmentation tools enable developers to quickly find these users, and then in-app purchase ads can be used to build relevant interstitial ads to reach them. For example, a developer can discover which of their users began playing their game in the last 48 hours, and promote a ‘welcome pack’ of extra lives at a 50% discount. This creates a more customized experience for users and can help prolong engagement. A developer can also choose where to place these interstitial ads in their app, and they can appear in either portrait or landscape mode.

In-App Purchase Ad

Changes to conversion counting in AdWords scripts

Friday, March 14, 2014

We recently announced changes to conversion counting and column names in AdWords. We are making the following changes to AdWords scripts to match the updated naming conventions:

We have deprecated the getConversions and getConversionRate methods in the Stats class. These methods will work for now, and will return the “converted clicks” and “converted click rate” values as per the new naming conventions.
We have introduced two new methods, namely getConvertedClicks and getClickConversionRate to replace the deprecated methods. Please use these methods in your new scripts.
We are keeping the column names unchanged in reports available through AdWordsApp.reports(). However, the meaning of values returned by these columns will reflect the new methods of counting conversions.

The following columns refer to “converted click” columns under the new naming convention.
- Conversions
- ConversionRate
- CostPerConversion
- ValuePerConv
- ValuePerConversion
- ConversionSignificance
- ConversionRateSignificance
- CostPerConversionSignificance
The following columns in AdWords scripts reports refer to the “conversion” columns under the new naming conventions. These columns will either return “All Conversions” or “Unique Conversions” values depending on the user preference for counting conversions. By default, this preference defaults to “All Conversions”, so these reporting columns will continue returning the same values as they do today, unless the user changes this preference to “Unique Conversions”.
- ConversionManyPerClick
- ConversionRateManyPerClick
- CostPerConversionManyPerClick
- ValuePerConvManyPerClick
- ValuePerConversionManyPerClick
- ConversionManyPerClickSignificance
- ConversionRateManyPerClickSignificance
- CostPerConversionManyPerClickSignificance

If you have questions or feedback about this change, let us know on our forum or via the Google Ads Developers Google+ page.

Anash P. Oommen, AdWords Scripts Team

New feed-based location extensions in v201402 of AdWords API

Friday, March 14, 2014

Location Feeds

Other Feeds

Feed.systemFeedGenerationData

Required

Defines the link between your AdWords and Places for Business accounts.

Not applicable

FeedMapping

Not applicable

AdWords maintains the feed item attribute -> placeholder field relationship for you.

Required

You maintain the feed item attribute -> placeholder field relationship.

FeedItem

Automatically managed by AdWords.

Maintained by you via the FeedItemService

CustomerFeed

Required

Not applicable

CampaignFeed

Optional

Only needed if you want more control over which businesses from your Places account are used for location extensions on a particular Campaign.

Required

AdGroupFeed

Optional

Only needed if you want more control over which businesses from your Places account are used for location extensions on a particular AdGroup.

Just as for other feed types, you can get stats for a location feed's extensions from the PLACEHOLDER_FEED_ITEM report.

This is just a quick overview of the AdWords API support for upgraded location extensions. For more information, check out our feed services guide for location extensions and the accompanying code sample in each client library (Java, Perl, PHP, Python, Ruby, .NET).

Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.

- Josh Radcliff, AdWords API Team

As previously announced, AdWords API v201402 lets you manage your upgraded, feed-based location extensions in addition to your campaign location extensions. Upgraded location extensions are linked to your Google Places for Business account and offer significant benefits over manually entered location extensions. Most importantly, once you configure your upgraded location extensions you don't have to worry about keeping them up to date with changes in your Google Places for Business account -- AdWords does it for you!

As mentioned in our detailed guide to upgraded location extensions, you can use the AdWords API to set up your extensions in a few easy steps:

Create a new Feed with its systemFeedGenerationData set to a PlacesLocationFeedData object, which tells AdWords to automatically create FeedItems from your Google Places for Business account.
Create a new CustomerFeed with the LOCATION placeholder type value of 7. This tells AdWords to use the Feed from step 1 to create upgraded location extensions for your ads.

There are a few key differences between feeds with systemFeedGenerationData ("location feeds") and other feeds you may have created for sitelinks, app or call extensions.

Type or Attribute	Location Feeds	Other Feeds
Feed.systemFeedGenerationData	Required Defines the link between your AdWords and Places for Business accounts.	Not applicable
FeedMapping	Not applicable AdWords maintains the feed item attribute -> placeholder field relationship for you.	Required You maintain the feed item attribute -> placeholder field relationship.
FeedItem	Automatically managed by AdWords.	Maintained by you via the FeedItemService
CustomerFeed	Required	Not applicable
CampaignFeed	Optional Only needed if you want more control over which businesses from your Places account are used for location extensions on a particular Campaign.	Required
AdGroupFeed	Optional	Optional
	Only needed if you want more control over which businesses from your Places account are used for location extensions on a particular AdGroup.

- Josh Radcliff, AdWords API Team

Introducing a new type of feed for AdWords API: Review extensions

Thursday, March 13, 2014

Review extensions, which let you show accolades from reputable third parties right in your search ads, were introduced last year. We have now made this feature available for the AdWords API in v201402.

Creating review extensions is the same as creating sitelinks as described in this guide. The only differences are:

The different placeholderId for FeedMappingService. As shown in the feed placeholders page, the placeholderId for review extensions is 8.
A different set of Feed attributes for FeedService. A review extension consists of four attributes:
- Text (String): Either an exact quote or paraphrase from a third-party source that appears beneath your ad
- Source (String): Name of the third-party publisher of the quoted or paraphrased review you’re using in your review extension
- Source URL (URL): Landing page of the third-party website where the quoted or paraphrased review is located
- Format (Boolean): Indicates whether your review is formatted as an exact quote from the third-party source, or if you’re paraphrasing. Setting to true means your review is formatted as an exact quote, false means paraphrasing.

Here is the Java code to create a Feed for review extensions. Code examples in other programming languages are available as part of the client libraries.

FeedAttribute textAttribute = new FeedAttribute();
textAttribute.setType(FeedAttributeType.STRING);
textAttribute.setName("Text");

FeedAttribute sourceNameAttribute = new FeedAttribute();
sourceNameAttribute.setType(FeedAttributeType.STRING);
sourceNameAttribute.setName("Source Name");

FeedAttribute sourceUrlAttribute = new FeedAttribute();
sourceUrlAttribute.setType(FeedAttributeType.URL);
sourceUrlAttribute.setName("Source URL");

FeedAttribute exactlyQuotedAttribute = new FeedAttribute();
exactlyQuotedAttribute.setType(FeedAttributeType.BOOLEAN);
exactlyQuotedAttribute.setName("Exactly Quoted");

Feed reviewExtensionFeed = new Feed();
reviewExtensionFeed.setName("Feed For ReviewExtension from API");
reviewExtensionFeed.setAttributes(
    new FeedAttribute[] {textAttribute, sourceNameAttribute,
    sourceUrlAttribute, exactlyQuotedAttribute});

If you have any questions about this feature or the AdWords API in general, you can post them on the developer forum. You can also follow the Google+ page for updates about the AdWords API.

- Takeshi Hagikura, AdWords API Team

Reminder: AdWords API v201306 and Ad Exchange Buyer SOAP API v201306 to be sunset on March 31

Thursday, March 13, 2014

As we have previously announced, if you're using the AdWords API or Ad Exchange Buyer SOAP API v201306, please note that support for this version will end on March 31st, 2014. If you are still using v201306 after that date, all requests will fail and your application will cease working until you migrate to a supported version. You can reference either the v201309 or v201402 migration guides for help upgrading to one of these versions.

In addition, remember that ClientLogin support is deprecated and you will have to migrate to OAuth 2.0 in order to authenticate starting in version v201402. It may be best to get this out of the way now, because with the sunset of v201309 on July 21st, 2014, all support for ClientLogin will go away and OAuth 2.0 will be required to access the API. Please reference our OAuth 2.0 migration guide for help with this process.

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.

- Michael Cloonan, AdWords API Team

A new way to access our Ads SOAP APIs through Python

Thursday, March 13, 2014

The Ads APIs Python client library, adspygoogle, has been around for quite some time, supporting versions of Python as old as 2.4 but capping out at 2.7. We’ve been getting more and more feedback recently that our users want Python 3 support. Also, many of adspygoogle’s dependencies are dated and no longer officially supported. We heard you, and with these items in mind... A New Client Library A completely new client library — googleads — is now available for Python 3 as well as Python 2.7. The new library has several advantages over our existing library:

Most of your code from the previous Python library will work with minimal modifications, listed below and in our migration guide.

The dependencies are all hosted on PyPI, so you do not need to use the --allow-external or --allow-unverified flags at install.

The constructors and attributes in the new library give you more control over client objects; for example, you can easily switch out OAuth 2.0 credentials and manage multiple accounts.

Data types are retained. Whereas adspygoogle uses strings for everything, googleads can send and receive numbers, booleans, datetimes, etc.

The library is more integrated with the Python standard library; for example, you can use the built-in logging framework to log SOAP messages.

The library is built on top of a fork of suds and allows users who are familiar with suds to take advantage of that library’s features.

Migrating to the New Client Library Existing Python users can retain almost all of their logic working with the objects defined in our APIs. An important difference is that your responses from the API are now objects returned by suds instead of dictionaries. The objects support using dictionary syntax to retrieve values but you cannot use dictionary methods on them. Most importantly, this means that .get() and .update() are no longer supported. Where in adspygoogle you may have done this:

response = inventory_service.GetAdUnitsByStatement(statement.ToStatement())[0]
ad_units = response.get('results')

You will now need to do this:

response = inventory_service.getAdUnitsByStatement(statement.ToStatement())
ad_units = response['results'] if 'results' in response else None

Some more minor changes that need to be made include changing your code to use the new methods for instantiating client and service objects and using the exact method names from our APIs, which are generally lower camel case. For more information on migration, check out the migration guide we have posted in the new library’s wiki section. The googleads library will be the primary focus of development moving forward. The existing adspygoogle library is now in maintenance mode but we will continue to add support for new AdWords and DFP API releases through December, 2014. If you find any bugs, have a patch to contribute or just a feature request, please feel free to file an issue on the issue tracker.

- Joseph DiLallo, Ads Developer Relations Team

Upcoming changes to call conversion settings in AdWords scripts

Wednesday, March 12, 2014

We recently announced the following changes to call metrics with call extensions in AdWords:

Since these changes are incompatible with AdWords scripts, we have deprecated the following methods related to these features in AdWords scripts:

These methods will be sunset on April 7, 2014. To make sure your scripts work properly, check any code that uses these methods, and fix them before April 7, 2014.

If you have questions or feedback about this change, let us know on our forum. You can also follow our Google+ page for updates about the AdWords scripts.

Anash P. Oommen, AdWords scripts Team

Sign up for beta access to AdWords scripts in My Client Center

Tuesday, March 11, 2014

We are excited to announce that AdWords scripts for MCC is now available as a limited beta for developers. This beta allows you to create AdWords scripts at the MCC level to efficiently manage changes across your client accounts at scale.

You can sign up for the limited beta at https://services.google.com/fb/forms/mccscripts. Once we’ve added you, we’ll send you an email with instructions on how to get started with MCC Scripts. You can learn more about this feature on our getting started guide.

We encourage you to try out this new feature and let us know what you think on our forum or our Google+ page.

- Anash P. Oommen, AdWords Scripts Team

Sunsetting CONVERSION DURATION THRESHOLD feed placeholder in AdWords API

Monday, March 10, 2014

Update: The sunset date was changed from April 7th, 2014 to April 28th, 2014. --Stan Grinberg

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.

- Ray Tsang, AdWords API Team

New Statement Builder Features in the DFP .NET Library

Monday, March 10, 2014

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.

- Chris Seeley, DFP API Team

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);

// 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.

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

- Chris Seeley, DFP API Team

Reminder: New filter limits for Adwords API and scripts

Friday, March 7, 2014

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:

AdWords API

AdWords scripts

Retrieving items using the get method
Requesting reports using the report method

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

Thursday, March 6, 2014

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.

- Ray Tsang, AdWords API Team

Announcing v201402 of AdWords API

Wednesday, March 5, 2014

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

Monday, March 3, 2014

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.

- Adam Rogal, DFP API Team

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

  // 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

ClientLogin gets the axe

Look out, deprecation ahead

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.

- Adam Rogal, DFP API Team

Ads Developer Blog

Step Inside AdWords on April 22 and be the first to see the newest innovations

Monetizing Unity Mobile Apps Just Got Easier

Changes Required for Creating New Campaigns in the AdWords API v201402

Support for v201402 Reports in AdWords Scripts

AdWords API users - don’t wait to migrate from ClientLogin to OAuth 2.0!

New geo targeting options in AdWords API

Bidding on the DoubleClick Ad Exchange with the Google Cloud Platform

Introducing IMA SDK Downloads for FlashDevelop and Flash Builder

Readying AdMob for the Second App Economy with New Features: Livestream from GDC Today

Changes to conversion counting in AdWords scripts

New feed-based location extensions in v201402 of AdWords API

Introducing a new type of feed for AdWords API: Review extensions

Reminder: AdWords API v201306 and Ad Exchange Buyer SOAP API v201306 to be sunset on March 31

A new way to access our Ads SOAP APIs through Python

Upcoming changes to call conversion settings in AdWords scripts

Sign up for beta access to AdWords scripts in My Client Center

Sunsetting CONVERSION DURATION THRESHOLD feed placeholder in AdWords API

New Statement Builder Features in the DFP .NET Library

Reminder: New filter limits for Adwords API and scripts

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

Announcing v201402 of AdWords API

Announcing v201403 of the DFP API

Labels

Archive