Google Ads Developer Blog

Using the Google My Business API to manage your location extensions

2015-10-15T04:20:00.001-07:00

Last year, we announced upgraded location extensions, a more efficient way to manage and use business locations in ads by linking Google My Business and AdWords accounts. To help you manage your business locations more easily at scale, we’re now releasing the Google My Business API.

Google My Business will be the central repository for managing your business locations. The creation of manual location extensions as feed items through the AdWords API has been deprecated and will sunset in Q2 2016. Please update your code before March 31, 2016 to avoid being impacted by this transition.

Supported features
The first version of the Google My Business API allows you to read, create, update and delete unverified business locations. Supported attributes are name, address, contact numbers, URL, categories, and business hours. Unverified locations can be used as location extensions in AdWords, but have to be verified to be eligible to show up on Google Maps.

Future releases of the Google My Business API will support additional functionality that will allow you to fully manage your location data across Google Ads and Maps.

Getting started with the Google My Business API
If you already use the AdWords API and manage more than 50 business locations, you can apply for access to the Google My Business API. Once granted, you will have access to the Google My Business API documentation and you can follow the steps there to get started. For accounts with 50 or fewer locations, please use Google My Business Locations for now.

Linking locations to accounts, campaigns or ad groups as location extensions
Users managing multi-location businesses (chains) must have a separate Google My Business account for each chain for bulk-verification. If you already manage locations under bulk-verified accounts in Google My Business today, you can link those accounts to AdWords to have your location extensions in sync.

For developers managing AdWords accounts with a large number of locations for small and medium businesses, we recommend creating one Google My Business account as a central repository for all locations. Each physical location should be created only once. If different owners and managers are involved per location or for sets of locations, we suggest using Business Accounts.

Once the AdWords accounts are linked to your shared Google My Business account, the locations will be available as feed items in AdWords. You are responsible for creating a CustomerFeed and using an appropriate matching function to make sure only locations that actually belong to the customer are linked to their related AdWords account. You can use CampaignFeeds or AdGroupFeeds for additional filtering based on campaigns or ad groups.

The best way to filter locations from a shared Google My Business account is to create location labels through the Google My Business API and use a matching function that uses these labels for selection. For example, you can label each location with its AdWords Customer ID in Google My Business and use these Customer ID labels for filtering in AdWords. Or you can label each location with a unique ID, as long as you keep track of these IDs.

Please see our guide for managing location extensions for further details, which also includes an end-to-end code example.

Migration of existing location extensions
If you are using manual location extensions through the AdWords API, we recommend migrating your locations to Google My Business before March 31, 2016. After this date, the creation of manual location extensions will sunset. All unmigrated locations stored in AdWords will be auto-migrated to Google My Business at a later date. Further details about the timeline and process will be announced in this blog.

Timo Bozsolik, AdWords API Team

AdWords API v201502 sunset reminder

2015-10-12T16:27:00.001-07:00

AdWords API v201502 will be sunset on November 12, 2015, after which all v201502 API requests will begin to fail. This version was deprecated on June 25, 2015. If you are still on v201502, we recommend that you migrate directly to v201509 (released last week) and skip v201506. Please be sure to migrate soon to ensure your API access is unaffected.

We have prepared various resources to help with the migration:

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

- Michael Cloonan, AdWords API Team

Sunset of the v201408 DFP API

2015-10-06T16:26:00.001-07:00

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

If you're still using v201408, now's the time to upgrade to the latest release and take advantage of new features like line item level reconciliation (see our guide here). 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:

Flash creatives have been updated to use CreativeAssets.
Report DimensionFilters have been replaced by PQL equivalents.
The ReportService's getReportJob has been replaced with getReportJobStatus. The new method returns only the ReportJobStatus.
The ForecastService was given a facelift, adding support for a new kind of forecast and more granular breakdowns.
LineItem.startDateTime and LineItem.endDateTime now require a timeZoneID. You can retrieve all of the supported time zone IDs from the Time_Zone PQL table.
Type fields have been removed from all entities. Use class names, instance of, or xsi:type instead.

This is not an exhaustive list, so as always, don't hesitate to reach out to us with any questions. To be notified of future deprecations and sunsets, join the DFP API Deprecation Announcements group and adjust your notification settings.

- Chris Seeley, DFP API Team

Announcing v201509 of the AdWords API

2015-10-06T10:33:00.000-07:00

Today we’re announcing the release of AdWords API v201509. Here are the highlights:

Improved batch processing. The new BatchJobService supports all of the same operations as MutateJobService, but offers additional features such as support for creating dependent objects using temporary IDs, better error reporting, improved performance, and a much higher limit on the number of operations per job. Check out the accompanying guide to get started.
AdWords for video and TrueView video campaigns in reports. The AdWords API now supports TrueView campaigns that have migrated from AdWords for video, and several reports now include statistics and new metrics for these campaigns. See the release notes for the complete list of changes and additions.
New reporting columns for multi-channel advertisers are available on multiple reports making it easier to track interactions vs. clicks.
Customer Match. Build and target user lists from email addresses using the new CrmBasedUserList.
Structured snippets can now be created using extension setting services.
Conversion column changes. Conversion columns have been modified, added, or removed on multiple reports to coincide with the upcoming conversion reporting changes in AdWords. See the release notes for the complete list of changes.
HTML5 ads can now be added as TemplateAds using template ID 419. In addition, MediaService now supports uploading media bundles for use with this new template.
Geo targeted ad customizers. Target each ad customizer feed item to a specific geographic location.
Gmail sponsored promotions. The AdWords API now fully supports the Gmail image, single promotion, and multi-product ad formats via template ads.
Dynamic remarketing ads have new placeholder fields for setting upgraded URL attributes such as tracking templates, custom parameters, and final URLs.
Active View reporting. New fields for Active View viewable impressions, measurable impressions, measurable cost, and measurability are now available in multiple reports.

If you’re using v201502 of the AdWords API, please note that it’s being sunset on November 12th, 2015. We encourage you to skip v201506 and migrate straight to v201509. If you’re using v201506, be aware it’s now marked deprecated and will be sunset on April 11th, 2016.

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

- Josh Radcliff, AdWords API Team

A note on ad size and mediating smart banners

2015-10-01T16:55:00.000-07:00

Smart banners are a handy thing for publishers. You can drop an AdMob smart banner into a layout or storyboard, and it’ll stretch or squeeze itself at runtime until it’s just the right size for the device, then request an ad to match. They’re a great feature with all the extra work hidden under the hood.

If you’re building an Android mediation adapter or custom event, though, things aren’t quite as simple -- after all, you’re under that hood, too! A common rough spot for developers is retrieving a smart banner’s size. Because the Google Mobile Ads SDK uses constants to internally represent a smart banner’s height and width, the getHeight and getWidth methods of a smart banner’s AdSize will return those constants (they’re negative numbers, so they’re quite hard to miss). That means relying on calls to getHeight and getWidth to determine a smart banner’s true size isn’t a workable strategy.

So how should adapter and custom event developers calculate sizes correctly? By avoiding getHeight and getWidth, and instead asking for pixel counts using getHeightInPixels and getWidthInPixels, two other methods offered by AdSize. You can scale their return values according to the device’s metrics and end up with the same kind of DPI values returned by getWidth and getHeight for other ad sizes. Here’s a code snippet that shows how it’s done:


// Get the raw pixel counts.
int widthInPixels = size.getWidthInPixels(context);
int heightInPixels = size.getHeightInPixels(context);

// These metrics include screen density, which is what we’re after.
DisplayMetrics displayMetrics = Resources.getSystem().getDisplayMetrics();

// These are values you can send to your mediated network’s SDK.
int widthInDpi = Math.round(widthInPixels / displayMetrics.density);
int heightInDpi = Math.round(heightInPixels / displayMetrics.density);

Once you finish the math, you’ll have proper DPI values that can be sent to whichever network you’re mediating. The calls to getHeightInPixels and getWidthInPixels require a valid Context, but you can use the one provided as a parameter to the requestBannerAd methods in MediationBannerAdapter and CustomEventBanner.

Now you know the best way to gauge the size of a smart banner! Use this approach and it’ll help keep your mediation running smoothly.

If you have technical questions about this (or anything else relating to the Google Mobile Ads SDK) stop by our forum.

- Andrew Brogdon, Mobile Ads Developer Relations

Creating native creatives with the DFP API

2015-09-24T11:51:00.001-07:00

Recently, we announced the availability of native ads for apps in DFP. Here, we’re going to introduce you to creating native creatives with the DFP API using the ads Java client library. A native creative consists of a set of assets (headline, image, etc.) which are sent to mobile apps for custom rendering in their own code (see our Android and iOS developer guides for details).

Native creatives are actually just another type of template-based creative. While the DFP UI abstracts this, in the API you create a native creative using a TemplateCreative with the system-defined native template ID. The creative template IDs available in your network can be retrieved by the getCreativeTemplatesByStatement method in the CreativeTemplateService. You can also view these IDs in the UI under Delivery > Creatives > Native ad formats (see the ID below each native ad format name in the table). The native app install template ID is 10004400.


    TemplateCreative nativeAppInstallCreative = new TemplateCreative();
    nativeAppInstallCreative.setCreativeTemplateId(10004400L);

Because native creatives do not have a predetermined size, you need to set a placeholder size of 1x1.


    Size size = new Size();
    size.setWidth(1);
    size.setHeight(1);
    size.setIsAspectRatio(false);
    nativeAppInstallCreative.setSize(size);

Finally, specify a name and destination URL; this example is for the Pie Noon app:


    nativeAppInstallCreative.setName("Pie Noon native ad");
    nativeAppInstallCreative.setDestinationUrl(
        "https://play.google.com/store/apps/details?id=com.google.fpl.pie_noon");

Settings specific to native creatives are set via template variables. An app install native creative requires the following unique template variable names to be set:

Headline
Body
Image
Price
Appicon
Calltoaction
Starrating
Store
DeeplinkclickactionURL

Note that creative template variables are case sensitive and those of type AssetCreativeTemplateVariableValue (“Image” and “Appicon”) must have a unique filename.

You can find the full Java example on how to create native creatives in our GitHub repository here. All of our other ads client libraries have similar examples.

As always, 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

Register now for Fall 2015 AdWords API Workshops!

2015-09-23T02:21:00.001-07:00

Fall 2015 AdWords API Workshop registration is now open. Access the registration forms on the workshop website at www.adwordsapiworkshops.com.

Once you choose a location we'll send you an email confirming your registration.

Workshops will be held on the following dates and locations:

New York City: October 20
San Francisco: October 22
London: October 27
Hamburg: October 29
Tokyo: October 29
Amsterdam: November 3

These workshops are technical in nature and are ideal for API developers. We hope to see you at these events. Register today!

If you have any questions about the AdWords API Workshops, you can post them on our forum. Check out our Google+ page for AdWords API updates.

—AdWords API Team.

Support for v201506 reports in AdWords Scripts

2015-09-21T11:28:00.000-07:00

We have added support for AdWords API v201506 reports in AdWords Scripts. This version adds support for FINAL_URL_REPORT, the Upgraded URLs-compatible replacement for the DESTINATION_URL_REPORT.

This version also introduces several changes to the reporting columns

Gmail Sponsored Promotion ad stats are now available in multiple reports in the following columns: GmailForwards, GmailSaves, GmailSecondaryClicks.
The DURING clause is now optional in AWQL report definitions when not segmenting by Date or Week.

The following new columns have been added to the existing reports:

Column	Reports
AdGroupStatus	PLACEHOLDER_FEED_ITEM_REPORT
CampaignName	CAMPAIGN_NEGATIVE_KEYWORDS_PERFORMANCE_REPORT CAMPAIGN_NEGATIVE_LOCATIONS_REPORT CAMPAIGN_NEGATIVE_PLACEMENTS_PERFORMANCE_REPORT
CampaignStatus	CAMPAIGN_NEGATIVE_KEYWORDS_PERFORMANCE_REPORT CAMPAIGN_NEGATIVE_LOCATIONS_REPORT CAMPAIGN_NEGATIVE_PLACEMENTS_PERFORMANCE_REPORT CAMPAIGN_SHARED_SET_REPORT PLACEHOLDER_FEED_ITEM_REPORT
EndDate	CAMPAIGN_PERFORMANCE_REPORT
FinalUrl	SEARCH_QUERY_PERFORMANCE_REPORT
StartDate	CAMPAIGN_PERFORMANCE_REPORT

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


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

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

Referer changes for ad clicks

2015-09-18T07:08:00.000-07:00

We are updating the referer of ad clicks to improve security and system reliability for users searching on Google. Starting within October, the referer for many ad clicks will only contain the Google domain from which the click occurred (domains like https://www.google.com or https://www.google.ca). This means that we will no longer be communicating specific paths such as “google.com/aclk” or “googleadservices.com/pagead/aclk.”

While the referer will no longer differentiate Google’s organic search clicks from ad clicks, and in some cases may be absent entirely, there are still multiple strategies to track the origin of your clicks. Recommended strategies include:

This change is a continuation of our general user security efforts. Users are safer when sites use HTTPS instead of HTTP, which is why we encourage the use of HTTPS. In fact, in August 2014 we began to use HTTPS as a ranking signal.

By default, browsers do not pass a referer from HTTPS sites to HTTP sites. To minimize advertiser disruption, we implemented a custom ads solution back when the Google search page migration to HTTPS took place. Now, many modern web browsers provide better control over referer behavior via the meta referer tag. This development is an improvement over our previously-implemented custom ads solution both in terms of reliability and latency.

Posted by Christopher Souvey, Senior Software Engineer, AdWords

AdWords API Fall 2015 Workshops Announced

2015-09-15T10:23:00.000-07:00

The AdWords API Workshops are back, and the registration form and agenda will be available on the website soon: www.adwordsapiworkshops.com. In the meantime, you may review the site Resources section for previous event presentations.

These workshops are a series of technical events, ideal for those who are working with the AdWords API.

Workshops will be held on the following dates and locations:

New York City - October 20
San Francisco - October 22
London - October 27
Hamburg - October 29
Tokyo - October 29
Amsterdam - November 3

Stay tuned and keep an eye on the website for more details on how to register.

--AdWords API Team

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