Google Ads Developer Blog

Support for shared negatives in AdWords Scripts

2015-09-10T13:48:00.000-07:00

AdWords Scripts now support negative keyword and excluded ad placement lists, and the ability to share them across campaigns. Follow these links for implementation details and code examples:

Shared negative keywords: docs, code snippets
Excluded placement lists: docs, code snippets

We have also released a new solution named Master Negative List that uses this feature to maintain a master list of negative keywords and placements for AdWords accounts. The list of negative criteria can be managed from a spreadsheet. Separate versions are available for AdWords accounts and manager accounts.

Special thanks goes to Terence Nip, who implemented this feature during his summer internship at Google.

Give this feature a try and let us know what you think! You can post your questions and feedback on our developer forum.

Anash P. Oommen, AdWords Scripts Team

Manual Ad Break Playback Part Deux: Welcome Back!

2015-09-03T14:49:00.000-07:00

Today we’re expanding on our earlier blog post, Manual ad break playback in the IMA SDKs. One of the major benefits mentioned in that blog post is the ability to let your users skip ads they’ve already seen when they resume a video stream they previously suspended. We’re going to show you how to implement that functionality. For the purposes of this demo, we’ll be using the HTML5 SDK, but the principles outlined here can be used to achieve the same functionality in all four of our SDK flavors.

Prerequisites

If you’d like to follow along with these samples, you’ll need to first:

Get a copy of our simple sample for HTML5.
Modify that sample to disable automatic playback of ad breaks, as outlined in this guide. Be sure to remove the original call to adsManager.start() in onAdsManagerLoaded!
Change the ad tag to a playlist with multiple mid-rolls (like this one) so you can see the behavior in action.

Step 1: Saving the user’s progress

The first step towards our ultimate goal is to save the current time of the video when the user leaves the page. For simplicity’s sake, we’re going to be using HTML5’s built-in localStorage object. We’re going to override window.onbeforeunload to grab the current time of the video element when the user leaves the page and save it in local storage.


function init() {
  videoContent = document.getElementById('contentElement');
  playButton = document.getElementById('playButton');
  playButton.addEventListener('click', requestAds);

  window.onbeforeunload = onUserExit;
}

function onUserExit() {
  if (videoContent) {
    localStorage.setItem('watched_time', videoContent.currentTime);
  }
}

Step 2: Restoring the user’s progress

Now that we’re saving the user’s progress, we’ll want to restore the video to that point when the user returns to the page. We’re going to add some code to the init method to grab the stored current time (if it exists) and seek to that time when our video loads.


function init() {
  videoContent = document.getElementById('contentElement');
  playButton = document.getElementById('playButton');
  playButton.addEventListener('click', requestAds);

  window.onbeforeunload = onUserExit;

  watchedTime = localStorage.getItem('watched_time') || 0;
  videoContent.addEventListener('loadedmetadata', function() {
    videoContent.currentTime = watchedTime;
  });
}

Step 3: Skipping previously viewed ads

Now that we’re keeping track of the user’s progress and restoring that progress when the user returns, we can skip and ad breaks they watched in a previous visit. To do that, we’ll modify our adBreakReadyHandler to call adsManager.start() only when the loaded ad break is set to play after the user’s most recent saved progress. To ensure the video starts after the skipped ad breaks, we’ll also add a call to videoContent.play() when we decide to skip an ad break.


function adBreakReadyHandler(event) {
  if (event.getAdData().adBreakTime >= watchedTime ||
      event.getAdData().adBreakTime == -1) { // -1 ensures we play post-rolls
    adsManager.start();
  } else {
    videoContent.play();
  }
}

That’s all there is to it! Try starting your video and watching the first mid-roll break. When you leave the page and come back, clicking the play button will result in the video playing from where you left off. The first ad break you’ll see is the second mid-roll break.

As always, if you have any questions feel free to contact us via the support forum.

- Shawn Busolits, IMA SDK Team

Updated AdWords API remarketing guides

2015-09-03T11:27:00.000-07:00

Have you ever wanted to advertise to people who previously visited your site or mobile app? This remarketing strategy can be implemented using the AdWords API. For example, you can target ads to people who left your website without buying anything to encourage them to return and make a purchase.

We recently updated our Remarketing and Rule-based Remarketing guides to more clearly show you how to use the API to get started quickly and implement some of the most common remarketing strategies.

Remarketing resources

As always, feel free to visit us or ask questions on the AdWords API Forum or our Google+ page.

- Andrew Kallem and Amir Lazarovich, AdWords API Team

More features now available in the AdWords API

2015-09-01T10:58:00.001-07:00

Following the release of AdWords API v201506, we've added a few additional features that are available immediately:

Android App ‘first open’ conversion tracking. Recently available in AdWords, this new conversion tracking solution measures when a user first opens an app after clicking on an ad and completing an Android app install. Check out the new FIRST_OPEN conversion type in the AppConversion tracker that also supports Postback URLs for Android.
A new report specific to final URLs: FINAL_URL_REPORT. The report replaces the deprecated DESTINATION_URL_REPORT and provides statistics aggregated at the final URL level.

We also launched account hiding support recently—see this announcement if you missed it. If you have any questions, feel free to reach us on the forum or via the Ads Developers Plus Page.
- Danial Klimkin, on behalf of AdWords API Team.

Handling App Transport Security in iOS 9

2015-08-26T10:04:00.000-07:00

The rollout of iOS 9 is expected to come this Fall and will introduce a new privacy feature called App Transport Security (ATS) to enforce best practices in secure connections between an app and its back end. This change may need your action if you are developing with the Google Mobile Ads SDK and building an app against the iOS 9 SDK.

We recommend using HTTPS exclusively if you’re developing a new app. If you’re working on an existing app, we suggest using HTTPS as much as possible and creating a plan to migrate the rest of your app toward ATS compliance.

All iOS 9 devices running apps built with Xcode 7 that don’t disable ATS will be affected by this change. The following log message appears when a non-ATS compliant app attempts to serve an ad via HTTP on iOS 9:

“App Transport Security has blocked a cleartext HTTP (http://) resource load since it is insecure. Temporary exceptions can be configured via your app’s Info.plist file.”

While Google remains committed to industry-wide adoption of HTTPS, there isn’t always full compliance on third party ad networks and custom creative code served via our systems. To ensure ads continue to serve on iOS9 devices for developers transitioning to HTTPS, the recommended short term fix is to add an exception that allows HTTP requests to succeed and non-secure content to load successfully.

Publishers can add an exception to their Info.plist to allow any insecure connection:


<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <true/>
</dict>

If you have any questions regarding these changes, feel free to contact us through our forum.

Update (8/27/2015): We've received important feedback about this post and wanted to clarify a few points. We wrote this because developers asked us about resources available to them for the upcoming iOS 9 release, and we wanted to outline some options. To be clear, developers should only consider disabling ATS if other approaches to comply with ATS standards are unsuccessful. Apple has provided a tech note describing different approaches, including the ability to selectively enable ATS for a list of provided HTTPS sites.

We’ve strongly advocated for HTTPS protection for many years and we continue to roll it out across our products.

- Tristan Emrich, Mobile Ads Developer Relations

Announcing v201508 of the DFP API

2015-08-25T10:48:00.000-07:00

It’s finally here, the release ~~everyone~~ some of you have been waiting for: v201508. I know you’re excited and probably want to go download an updated version of the client library right away, but give me a second to tell you why you should be excited.

We’ve improved the reconciliation services in the DFP Sales Manager API, making for easier updates and reporting. There’s a bunch of changes to trafficking creatives giving you more control and visibility over your creative library. We’re also cleaning house on reporting, making the columns and dimension attributes you know and love that much easier to use.

(see full release notes here).

DFP Core

DFP trafficking objects received a few facelifts in this version.

We removed IDs from CreativePlaceholders (don’t worry, they weren’t being used anywhere).
On the creatives front, we switched Flash creatives over to use CreativeAssets, which should make duplicating and reusing flash creatives much easier. And we added CreativePolicyViolations to each creative so you can know exactly why a creative or line item was paused.
We’ve updated line item creative associations by adding a DeleteLineItemCreativeAssociations action to match UI functionality. It should be noted that deleting them is a permanent action and not simply a change in status. Deleted LICAs will no longer be accessible in the UI or API.

Sales Manager

If it’s been your dream to reconcile your delivery and billing data at the line item level, you should probably sit down for this, because featured in this release is the addition of the ReconciliationLineItemReportService which brings parity to the reconciliation process in the UI.

Additionally, we’re adding a few replacement DimensionAttributes to our ReportService - PROPOSAL_LINE_ITEM_LAST_RECONCILIATION_DATE_TIME, PROPOSAL_LINE_ITEM_RECONCILIATION_STATUS, and their LINE_ITEM_* equivalents to use for when you start reconciling line items. See the related blog post on the removal of the RECONCILIATION_RECONCILIATION_STATUS and RECONCILIATION_LAST_DATE_TIME columns found here.

Reporting

We’ve removed all DimensionFilters, as stated earlier this year (ones that have significant usage are replaced with PQL filters), added two new dimensions for ORDER_DELIVERY_STATUS as well as AGGREGATED_DEMAND_CHANNEL, and renamed the Nielsen metrics from NIELSEN_OCR_* to NIELSEN_*.

As a reminder, with each new release comes a new deprecation. If you're using v201408 or earlier, it's time to look into upgrading. If you have any questions about upgrading, let us know on the developer forum.

- Nicholas Chen, DFP API Team

Integrating with DFP as a third party

2015-08-19T07:42:00.002-07:00

Does your company want to provide third-party services for DFP but is unsure how to get started? If so, you're in luck! We've just published a new guide on how to integrate with DFP as a third party. The guide covers the major topics that new integrators commonly run into:

How to get started.
How to test your DFP integration.
How to properly set up authentication to access a client's network.
How to keep up to date with API versions.
Where to get support.

All this information can be yours just by visiting our guide.

If you have any questions, feel free to drop us a line on the DFP API forums or the Ads Developer Google+ page. - Vincent Tsao, DFP API Team

New Swift samples for the Google Mobile Ads SDK

2015-08-18T15:44:00.000-07:00

In response to the growing popularity of Swift development, we’ve added Swift samples for the Google Mobile Ads SDK to our GitHub repo. To make it easier for developers to get started using Swift, we’ve also added Swift code snippets to our Get Started and Interstitial guides.

If you have any questions about using Swift with the Google Mobile Ads SDK, you can reach us on our forum. Remember that you can also find us on Google+, where we post updates on all of our Google Ads developer products.

- Ram Parameswaran, Mobile Ads Developer Relations

IMA HTML5 SDK custom playback changes

2015-08-14T12:02:00.000-07:00

On September 16th, 2015, the IMA HTML5 SDK will change how it handles custom playback. In order to provide a more seamless ad experience, custom playback on Android 4.0+ devices will be disabled.

As per a previous change, the SDK only selects custom playback when necessary. Since Android 4.0+ devices support standard rendering, it is no longer necessary to use custom playback on these devices.

What must I do to prepare for this change?

Double check to make sure you’re always passing in your content video element as the custom playback element. Custom playback will still be used in pre-4.0 Android environments.
On mobile, be sure you’re calling AdDisplayContainer.initialize() as a result of a user action. This method is not necessary in custom playback, but it must be called to play ads using standard rendering. Otherwise your ad video will not play. We recommend you always call this method on mobile, so your implementation will be ready for any future devices that support standard rendering.
If your code requires a reference to the <video> element playing the ad, then this change might break your implementation. Instead, check the return value of AdsManager.isCustomPlaybackUsed(). If the value is true, the content video reference will be the same as the ad video reference.

If you have any questions about these changes, feel free to contact us via the support forum.

- Yury Pavlotsky, IMA SDK Team

Announcing new releases of the Google Mobile Ads SDK: v7.8 for Android and v7.4.1 for iOS

2015-08-14T10:39:00.000-07:00

Today we’re announcing two new versions of the Google Mobile Ads SDK: version 7.8 for Android, and version 7.4.1 for iOS. Those of you using Android Studio can download Google Repository (Rev. 20) to get the latest Gradle artifacts. Eclipse developers will find it listed as Google Play services (Rev. 26) in the Android SDK manager. Publishers with iOS apps can get the latest SDK for that platform by updating their CocoaPods Podfile to pull version 7.4.1 or by downloading it manually. These releases contain a number of stability and performance improvements, as well as some new features — including beta support for MRAID v2.0 on iOS and Android!

MRAID v2.0 Beta

MRAID v2.0 offers a number of new methods that advertisers can use to improve their creatives. Ads using the new standard can store photos, resize themselves on the fly, query screen dimensions, and make calendar events using calls like this:


mraid.createCalendarEvent({
    description: “A big sale at our store!”,
    location: ‘123 Savings Street’,
    start: ‘2015-9-01T09:00-05:00’, 
    end: ‘2012-12-22T10:00-05:00’
});

The new standard creates some great opportunities for increased engagement, so for more info about MRAID, see our iOS MRAID guide, our Android MRAID guide, or the IAB’s specifications document.

Checking ad loading status on Android

In the new Android release, we’ve added an isLoading method to the AdLoader, AdView, and InterstitialAd classes so publishers can check whether an ad request is in progress. If you’re using an AdLoader to fetch a native ad, for example, you can use a call like this to see if the request has completed:


if (!myAdLoader.isLoading()) {
    /* The AdLoader isn’t busy making a request. */
    myAdLoader.loadAd(new AdRequest.Builder().build());;
}

iOS global settings

This SDK release introduces the GADMobileAds class, which provides global settings for controlling certain information collected by the SDK. In-app purchase reporting and crash reporting are enabled by default. However, if you’d like, you can disable these settings in most instances by using the disableAutomatedInAppPurchaseReporting and disableSDKCrashReporting methods. See the global settings guide for more information.

For a full list of Mobile Ads SDK changes, check out our release notes. For technical questions, post them on our forum.

- Andrew Brogdon, Mobile Ads Developer Relations

Hiding AdWords accounts now possible via the AdWords API

2015-08-13T13:26:00.001-07:00

Starting with v201506 of the AdWords API, you can:

Hide or unhide an AdWords account under your manager account by setting the isHidden attribute of its ManagedCustomerLink to true or false, respectively.
Exclude hidden accounts in ManagedCustomerService.get and ManagedCustomerService.query calls by specifying ExcludeHiddenAccounts = true in your predicate or AWQL WHERE clause.

With these new features, you can hide old or inactive accounts to reduce clutter in your managed account's dashboard, as well as detect and exclude hidden accounts using the AdWords API.

As with the AdWords user interface, you can only hide or unhide AdWords accounts. Any attempt to hide a manager account will result in a ManagedCustomerServiceError.CANNOT_HIDE_OR_UNHIDE_MANAGER_ACCOUNTS error.

Don't worry -- hiding an account doesn’t affect serving:

You can always unhide an account by setting the isHidden attribute of its ManagedCustomerLink back to false.
You can retrieve all of your accounts by setting ExcludeHiddenAccounts to false in your selector, or by not specifying a predicate on ExcludeHiddenAccounts.
Ads in hidden accounts will continue to serve.

More manager account resources

Guide on managing customer accounts.
Latest docs on ManagedCustomerLink and ManagedCustomer.

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

- Josh Radcliff, AdWords API Team

Make sure your Ads API client library runtime environment is up-to-date!

2015-08-12T13:37:00.001-07:00

What's changing?

We’ve updated the runtime requirements of some of our client libraries. Make sure to update your setup to keep your application compatible and secure.

Which libraries are affected?

.NET

As announced in 2014, the .NET client library requires a minimum of Microsoft .NET Framework 4.0 or Mono version 3.2.8.

Java

As announced in 2014, the Java client library now requires Java 1.6 or higher.

Perl

With the release of version 4.0.0 of the AdWords API Perl client library, the minimum version supported is Perl version 5.14.
AdWords API Perl client library version 3.5.0 supports Perl 5.8 and will continue to be supported until September with critical bug fixes only.

We updated the minimum required Perl version to 5.14 because the Perl community no longer officially supports the older versions of the language, and our client library relies on CPAN modules that no longer exist for older versions of Perl. With the installation of client library version 4.0.0, please make sure you use Perl 5.14 or newer on your system.

PHP

As announced in 2014, the PHP client library now requires PHP 5.3 or higher.

Python

Depending on whether you’re using Python 2 or 3, the Python client library has differing minimum requirements:

Python 2: Requires Python 2.7.9 or higher because this is the earliest version supporting SSL certificate validation.
Python 3: Requires Python 3.4 or higher for compatibility with the oauth2client dependency.

Ruby

The Ruby client library has dropped support for Ruby versions 1.8, 1.9, and 2.0, and we will no longer be fixing bugs specifically for those versions.

If you have any question or concerns, visit us on the forums (AdWords API, DoubleClick for Publishers API, DoubleClick Ad Exchange Buyer API), our Google+ page, or a library-specific issue tracker.

Nadine Sundquist, AdWords API Team

Sunset of the v201405 DFP API

2015-08-11T09:11:00.000-07:00

On Monday, August 31, 2015, in accordance with the deprecation schedule, v201405 of the DFP API will be sunset. At that time, any requests made to v201405 will return errors.

If you're still using v201405, now's the time to upgrade to the latest release and take advantage of fresh new features like DeliveryForecasts. To do so, check the release notes to identify any breaking changes, grab the latest version of your client library and update your code.

Some changes to look out for:

The endpoint URL for requests has changed from https://www.google.com to https://ads.google.com. We updated this in the default settings of our client libraries, but double check your local configuration files as well.
LineItem.startDateTime and LineItem.endDateTime now require a timeZoneID. You can retrieve all the supported time zone IDs from the Time_Zone PQL table.
The ForecastService was given a facelift, adding support for a new kind of forecast and more granular breakdowns.
All MERGED_* reporting metrics have been deprecated and removed.
The ReportService's getReportJob is now getReportJobStatus. The new method returns only the ReportJobStatus, not the entire ReportJob.

This is not an exhaustive list, so as always, don't hesitate to reach out to us with any questions.

- Chris Seeley, DFP API Team

Manual ad break playback in the IMA SDKs

2015-08-06T12:53:00.000-07:00

We recently launched manual ad break playback across our iOS, Android, HTML5, and Flash SDKs. For more info on what this means and how to use it, read on!

What is manual ad break playback?

Under a standard IMA SDK implementation, when an ad rules or VMAP response is returned, the SDK will automatically play each ad break at its cue point. With manual ad break playback, the SDK will instead fire an event when it’s time to play an ad break, and let you decide if or when you’d like to play it.

What are the implications of this change?

If you’re happy with your current ad rules or VMAP performance, this change doesn’t require you to do anything - your implementation will continue to work just as it does now. If you’d like more fine-tuned control over ad break playback timing, then we recommend using this feature.

What are the benefits of this change?

We see two major areas in which this change will help publishers. The first is when a user starts a stream somewhere in the middle of the content instead of at the beginning. (The most common scenario is that the user watched part of the video previously, left the app or page, and returned to continue watching the rest of the video). With a standard implementation, the user will be greeted by (in some cases) a pre-roll, followed by the most recent mid-roll that they watched previously, then the content. By using manual ad break playback you can prevent the pre- or mid-roll (or both) from playing so that the user can go straight to the content, and then resume mid-rolls when the user sees their first mid-roll break for the new session.

The second major use case is misaligned ad breaks. If you’re playing long form content with mid-rolls, and your video fades in and out for mid-roll breaks, you want to make sure that your ad breaks properly align with those fades. In some cases, publishers have told us that the ad break scheduling changes slightly between pieces of content, causing the ad to cut off content for some streams. With this new system, if you know exactly when an ad break should play, you can listen for the AD_BREAK_READY event and delay the ad break playback until the exact time your stream is ready for it.

How do I implement this new feature?

We have guides for each of the SDKs on implementing this new feature:

As always, if you have any questions feel free to contact us via the support forum.

- Shawn Busolits, IMA SDK Team

New features in AdWords Scripts

2015-08-05T14:56:00.000-07:00

We have made the following changes to AdWords scripts.

Full screen mode for Scripts IDE

You can now toggle fullscreen mode for the Scripts IDE by clicking the Expand icon on the top right corner of the editor toolbar.

Clear methods for Upgraded URLs

We have added new methods to clear various fields in Upgraded URLs:

clearTrackingTemplate() clears the tracking template field in the CampaignUrls, KeywordUrls, AdGroupUrls and SitelinkUrls classes.
clearFinalUrl() clears the final URL field in the KeywordUrls class.
clearMobileFinalUrl() clears the mobile final URL field in the SitelinkUrls , MobileAppUrls and KeywordUrls classes.
Custom parameters may be cleared by specifying an empty collection. For example, keyword.setCustomParameters({});

Clear methods for sitelink descriptions

You can now use the clearDescription1() and clearDescription2() methods to clear the corresponding description fields in the Sitelink, AdGroupSitelink and CampaignSitelink classes.

Sunset support for updating destination URL

As previously announced, support for updating destination URL has been sunset completely. If any of your scripts use this field, make sure you upgrade your scripts to use the upgraded URL fields. We have also added clearDestinationUrl() to the Keyword class and clearLinkUrl() to various ad extension classes. These methods may be used to clear the destination URL field when you upgrade your URLs.

See our sunset tracker page for more details.

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

Announcing v2.2 of the DCM/DFA Reporting and Trafficking API

2015-08-04T12:22:00.000-07:00

Today we are releasing v2.2 of the DCM/DFA Reporting and Trafficking API. Highlights of this release include:

User requested enhancements: You asked and we listened! Based on your feedback, new fields--such as computed click-through URL for ad creative assignments--have been added.
Placement search improvements: You can now search for placements and placement groups by start and end date.
Ins tag support: When the new ins tag is enabled for your account, requests for iframe and javascript tags will return an updated tag format. We've introduced 4 new legacy tag values you can use to access the older versions of these tags, to ensure a smooth transition to the upgraded format. You can begin requesting these legacy tag values today, even if your account hasn't upgraded yet.

Retiring older API versions

Along with this release, we're introducing a new deprecation schedule and announcing the deprecation of all versions prior to v2.1. Moving forward, we will generally only support 3 versions of the API and sunset the oldest version 4 months after a new release. In order to help developers adjust to this new schedule, we're providing an extended migration period for users of these newly deprecated versions:

API Version	Deprecation Date	Sunset Date
v1	3 Aug 2015	29 Feb 2016
v1.1	3 Aug 2015	29 Feb 2016
v1.2	3 Aug 2015	29 Feb 2016
v1.3	3 Aug 2015	29 Feb 2016
v2.0	3 Aug 2015	29 Feb 2016

These versions will remain active and supported until the sunset date, and we encourage you to use this time to update your applications.

Learn more

As with every new version of the DCM/DFA Reporting and Trafficking API, we encourage you to carefully review all changes in the Release Notes. For those of you looking to get going right away, updated client libraries are now available. If you're just starting out, the Get Started guide is a great reference to help you get up and running quickly.

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

- Jonathon Imperiosi, DCM API Team

Changes to DFP Reporting, now with more deprecation!

2015-08-04T11:32:00.000-07:00

After our last round of spring cleaning, we've gone back to the drawing board to take another look at how we could make reporting better. There currently is an abundance of Dimensions, DimensionAttributes, and Columns (and more coming with each release), so in an effort to simplify the list of fields, we will be sunsetting the following reconciliation-related dimension attributes / columns in all versions. This will happen on September 1, 2015.

Columns with equivalent replacements:

RECONCILIATION_LAST_DATE_TIME replaced by dimension attribute: PROPOSAL_LINE_ITEM_LAST_RECONCILIATION_DATE_TIME and LINE_ITEM_LAST_RECONCILIATION_DATE_TIME
RECONCILIATION_RECONCILIATION_STATUS replaced by dimension attribute: PROPOSAL_LINE_ITEM_RECONCILIATION_STATUS and LINE_ITEM_RECONCILIATION_STATUS

Columns without equivalent replacements:

LINE_ITEM_RECONCILED_RATE (in <= v201502)
CONTRACTED_REVENUE_CONTRACTED_PLACEMENT_NET_REVENUE (in <= v201411)
CONTRACTED_REVENUE_CONTRACTED_PLACEMENT_GROSS_REVENUE (in <= v201411)
DISCOUNT_BREAKDOWN_ADDITIONAL_ADJUSTMENT (in <= v201411)

While the first two have equivalent replacements, the latter ones are not being replaced, as they don’t exist in core product reporting either.

This means that usage of these columns / dimension attributes will begin throwing errors in all versions starting September 1st. If your network is actively using any of these, please update your reports to switch to the supported fields or remove them entirely. If you have any questions, comments, or concerns about this, you know where to reach us!

- Nicholas Chen, DFP API Team

Help me help you (improve the DFP API)

2015-07-30T18:03:00.000-07:00

Believe it or not, the DFP API Team eat, breathe, and live the DFP API. We wake up in the morning thinking, "How can I make the DFP API even better?" Seriously, I have had dreams about the API. It’s weird, but I’m not embarrassed to admit that.

In an effort to delight our developers even more, we’re turning the proverbial mic over to you - our customers - to help us help you. Here’s your chance to let us know how we could be better – better support, better features in the client libraries, better content in workshops, better examples, better haircuts... really, anything. Simply fill out our survey with your thoughts here.

- Nicholas Chen, DFP API Team

What’s new with IMA iOS SDK Beta 15?

2015-07-29T21:08:00.000-07:00

Last week, we released beta version 15 of the IMA SDK for iOS. This release includes two new features:

Ad buffer events via IMAAdsManager delegates
Debugging mode

Ad buffer events

We’re providing more information on ad buffering by introducing new buffering events via the following optional IMAAdsManagerDelegate methods:

adsManagerAdPlaybackReady:
adsManagerAdDidStartBuffering:
adsManager:adDidBufferToMediaTime:

Collectively, these delegate methods provide more transparency into buffer events, giving you more control over the user’s ad experience. For more detailed information on these new methods, take a look at the reference documentation.

Debugging mode

We’ve introduced a new debugging mode setting to allow for more verbose logging to the console. You can now set IMASettings.enableDebugMode to YES to enable debug mode. This should not be used in production, as it will show a watermark on the ad player.

A note about CocoaPods

If you’re using CocoaPods with the IMA SDK, please make sure to use at least version 0.38.

As always, if you have any questions, feel free to contact us via the support forum.

- Yury Pavlotsky, IMA SDK Team

Relaxing constraints on ad group name uniqueness

2015-07-29T20:22:00.001-07:00

Have you ever found it frustrating that you can never reuse an AdGroup name after removing the AdGroup, since a removed AdGroup cannot be modified? We have awesome news for you!

Now, AdGroupService doesn’t consider REMOVED AdGroup names when verifying that an AdGroup name is unique within a Campaign. If an AdGroup is in a REMOVED state, then the name of that AdGroup can be reused. This is already the case for Campaigns, and we’ve extended this relaxation of constraints to AdGroups.

If you have questions or need clarification, visit us on the AdWords API Forum or our Google+ page.

Nadine Sundquist, AdWords API Team

New guide for setting up AdWords API authorization using the OAuth 2.0 Playground

2015-07-22T12:39:00.000-07:00

For those of you who’d prefer to generate an OAuth refresh token using only a browser, there's a new guide on how to use the OAuth 2.0 Playground:

https://developers.google.com/adwords/api/docs/guides/oauth_playground

The guide walks you through the authorization setup required by the AdWords API for a Web application--via a browser session--without the need to execute any command-line scripts.

More OAuth resources

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

- Josh Radcliff, AdWords API Team

FeedMappings for location targeting available via the AdWords API

2015-07-15T13:41:00.000-07:00

What's changing?
Starting on or after July 23, 2015, if you are using v201506 of the AdWords API, then FeedMappingService.get and FeedMappingService.query will return FeedMapping objects created for location targeting. These FeedMapping objects will have criterionType 77, and will not have a value for placeholderType. There will be no change in behavior for v201409 or v201502.

You will start seeing these objects if either of the following is true:

You created a Feed linked to your Google My Business account.
You created a Location targeting feed through the AdWords user interface, under Shared library -> Business data.

Why the change?
Starting with v201506, LocationGroups.feedId is required if your matching function includes a LocationExtensionOperand.

Specifying a feedId in this situation allows AdWords to target the areas surrounding the locations in a location targeting feed. This may be the same feed you are using for location extensions, or a separate feed containing additional locations you want to use strictly for targeting. The key point is that the Feed referenced by LocationGroups.feedId must have a FeedMapping with criterionType 77.

What should you do?
If your application retrieves FeedMapping objects, make sure it will properly handle objects where placeholderType is null and criterionType is set.

If you want to create LocationGroups objects that use a LocationExtensionOperand, you can now use FeedMappingService to find the ID of feeds that have a FeedMapping with criterionType 77.

Learn more
Check out the following resources for more information on Location Groups:

The updated placeholders documentation describes the required fields for a location targeting feed.
The AddCampaignTargetingCriteria example in the targeting folder of each client library shows how to set up a LocationGroups object using the ID of your location targeting feed.
The AdWords Help Center has an overview of using Location Groups.

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

DFA API sunset reminder

2015-07-14T11:10:00.002-07:00

As we announced in December 2014, with the release of the DCM/DFA Reporting and Trafficking API, we will be sunsetting the legacy DFA API on September 30th, 2015. To avoid an interruption in service, all DFA API users are required to update their application to use our new API by this date. If you haven’t yet started migrating, we strongly encourage you to do so.

If you’re new to the DCM/DFA Reporting and Trafficking API, you can use our Get Started guide to get up and running quickly. You can also reference our Migration Guide to help in transitioning legacy DFA API applications to the new API. If you have any other questions, feel free to reach out to us on the developer forum.

- Jonathon Imperiosi, DCM API Team

Removal of MatchType.BROAD_SESSION in AdWords API reports

2015-07-14T09:07:00.000-07:00

On or shortly after August 24th, we will remove the BROAD_SESSION match type label from the MatchType column in the Search Query Performance and Paid & Organic Query reports. Instead, rows that formerly returned "broad (session-based)" will begin returning "broad".

To simplify the way we report on match types, this label will be removed from all of our reports, including historical reports. If you'd like to see how your keywords are currently matching to this label, download a copy of your Search terms report before August 24th, 2015.

This is a reporting change and will have no impact on the broad match serving behavior. You can learn more about the MatchType column in the AdWords Help Center.

As always, if you have any questions, comments, or concerns, please contact us via the forum or the Ads Developers Plus Page.

- Michael Cloonan, AdWords API Team

Improved Upgraded URLs validation in AdWords API

2015-07-10T09:53:00.000-07:00

Waiting to see whether or not your ads have been approved can be time-consuming. That's why we're improving the validation logic during ad creation to “fail fast” for one common invalid URL case.

Currently, with new Upgraded URLs, an ad with a final URL domain that doesn't match the display URL domain will be disapproved. Starting on August 12th, 2015, rather than allowing these ads to be submitted for approval, the AdWords API will return an error for any request attempting to create an ad where the final URL domain doesn't match the display URL domain. This will allow you to fix these issues faster and get your ads up and running sooner.

As usual, if you have any questions, comments, or concerns, please contact us via the forum or the Ads Developers Plus Page.

- Michael Cloonan, AdWords API Team