Google Ads Developer Blog: August 2015

Handling App Transport Security in iOS 9

Wednesday, August 26, 2015

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

Tuesday, August 25, 2015

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

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 ManagerReconciliationLineItemReportServiceAdditionally, 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. ReportingDimensionFiltersearlier this yearORDER_DELIVERY_STATUSAGGREGATED_DEMAND_CHANNELNIELSEN_OCR_*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

Wednesday, August 19, 2015

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

Tuesday, August 18, 2015

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

Friday, August 14, 2015

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

Friday, August 14, 2015

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 BetaMRAID 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 AndroidIn 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 settingsThis 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

Thursday, August 13, 2015

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!

Wednesday, August 12, 2015

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

Tuesday, August 11, 2015

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

Thursday, August 6, 2015

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

Wednesday, August 5, 2015

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:

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

Tuesday, August 4, 2015

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!

Tuesday, August 4, 2015

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!