Tag Archives: deprecation

Important upcoming breaking changes to DFP reporting

Now that it’s spring again (in the Northern Hemisphere at least), it’s time for DFP’s annual spring cleaning! In this edition, we’ll be doing some pruning of our ReportService. What does this mean for you? We’re sunsetting some reporting dimensions, attributes, and metrics in existing versions (before the version is fully sunset), so your reports will break if you don’t migrate before the shutoff dates. I know what you’re wondering: “should I panic?”. Absolutely not. This type of behavior rarely occurs, so as long as you phase out usage for these particular fields, you should be fine moving forward.

Merged Metrics

Remember when Doubleclick for Publishers was called DART? I, too, get nostalgic about our old ad server, but it’s been a couple of years since we transitioned to the new DFP platform, and it’s just about time when the merged reporting columns are no longer useful (these columns only existed so you could continue reporting on delivery that spanned DART and DFP). In all versions after v201502, we will no longer provide merged reporting columns and dimension attributes in the API, that is, anything starting with 'MERGED_' or contains '_LIFETIME_MERGED_.' After August 1, 2015, these columns and dimension attributes will stop returning data entirely and will return INVALID_COLUMNS in all versions that still include them.

There are three scenarios in which you’re using these columns:

  1. Just for fun.
  2. Because you forgot you’re using them.
  3. Because you have lifetime line items that have carried over from DART (in which case you’ll have to recreate these). To give you an example, if the metric you care about is impressions, you can get the DART delivery portion by subtracting the portion of delivery from DFP Premium (AD_SERVER_IMPRESSIONS) from the MERGED value (MERGED_AD_SERVER_IMPRESSIONS) which represents the aggregate DART and DFP Premium volume. Additionally, you should make the switch to the non-merged columns and dimension attributes as soon as possible.

Dimension Filters

But wait, there’s more! Our next API version (v201505) will be the last to support some of our infrequently used dimensionFilters.

  • MOBILE_LINE_ITEMS
  • WEB_INVENTORY_UNITS
  • MOBILE_INVENTORY_UNITS
  • WHOLE_NETWORK
  • PARTNER_STATS_TYPE_ESTIMATED
  • ACTIVE_ADVERTISERS
  • PARTNER_STATS_TYPE_RECONCILED
  • WEB_LINE_ITEMS
  • ALL_SALESPEOPLE

In each of the cases above, the filters either no longer provide meaningful information (as is the case with mobile vs. web line items and ad units with platform unification complete), or weren’t being used at all.

Similar to the changes above, after August 1, 2015, these dimension filters will return an INVALID_DIMENSION_FILTERS error in any version that still includes them.

So if you’re using any of the reporting features above, consider this an early heads up (and an opportunity) to refactor some of your code for spring cleaning.

As usual, if you have any questions, comments, or concerns, don’t hesitate to let us know on the forums.

 - , DFP API Team

AdsPyGoogle Sunset on January, 5 2015

As an avid reader of this blog, you have undoubtedly already seen the announcement that our dear old friend, the client library known as ‘AdsPyGoogle,’ will be sunset on January 5, 2015. Yes—we too at Google are very sad about this.

Fret not! In its place, we have a more than capable replacement in the form of our new GoogleAds Python client library which is more lightweight, has far fewer dependencies, boasts improved utilities and functionality, and perhaps most importantly, supports Python 2.7 as well as 3.x.

If you need a starting point on how to perform this switch, we have a blog post detailing the differences between the two, as well as a nifty migration guide on Github.

As usual, if you have any questions, feedback, or comments, please don’t hesitate to reach out on the DFP or AdWords forums.

 - Nicholas Chen, DFP API Team

Sunset of DFP API v201311 and earlier, and the removal of ClientLogin

This is a friendly reminder that, on February 27, 2015, we will sunset DFP API versions v201311, v201308, and v201306. At that point, requests to these versions will fail. We'll also remove them from our online documentation and the client libraries. If you are currently using one of these versions, this is an excellent time to begin migrating to a supported version. See the release notes for a list of the many new features in our recent API versions.

Going forward, all DFP API versions will follow a consistent deprecation schedule: versions will be supported for one year, deprecated for one quarter, then sunset. This means each of our quarterly API versions will be available for 15 months from the time of release. This deprecation schedule enables us to spend more time improving the latest versions with new features.

Note that v201311 is the last version that supports ClientLogin, which was officially deprecated across all of Google on April 20, 2012. If your application is not yet using OAuth2, you must migrate before Feb 27, 2015.

If this task seems daunting, don't fret, we have you covered. On our Developer page, we have a helpful OAuth2 guide to make sure the transition is as smooth as possible. As an added reason to switch, the DFP API now supports OAuth2 service accounts. You can add service account users directly in the DFP UI. For more information, see here for a guide on how to use a service account user with the DFP API.

If you have any feedback or comments about this deprecation, or the API in general, please feel free to leave them on our forum.

 - , DFP API Team

Reminder: DFP API v201302 and earlier will be deprecated on August 1, 2014

After successfully removing several older versions of the DFP API earlier this month, we’re continuing our 'Spring Cleaning' by reminding everyone that support for version v201302 or earlier of the DFP API will end on August 1st, 2014. If you are still using one of those versions after that date, all requests will fail and your application will cease to work until you migrate to a supported version. Please reference the release notes for all changes to the API when migrating to a newer version.

In addition, please note that ClientLogin support is being phased out and that you will have to migrate to OAuth 2.0 in order to authenticate starting with v201403. Please reference our OAuth 2.0 implementation guide for help with this process.

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

 - , DFP API Team

Announcing Deprecation of the Standalone Android Google AdMob SDK

Since joining Google Play services back in October 2013, Google Mobile Ads has added support for the following products:

  • AdMob
  • DoubleClick for Publishers
  • DoubleClick Ad Exchange

The new Google Mobile Ads APIs also offer additional features that the standalone Android SDK doesn’t have:

  • The new library has full support for the Android Advertising ID, and is compliant with the latest Google Play Ad Policy.
  • Google Play services offers automatic service updates via the Google Play store, so you get the benefit of always being on our latest and greatest mobile ads library without the hassle of having to update your apps.
  • The DoubleClick Ad Exchange JavaScript adapter is now included in the Google Play services library. This means you have one less dependency in your application, and you can be sure that the adapter will always be compatible with future Google Play services updates.

As part of the Google Play services 4.2 update, we are deprecating the standalone Android SDK in favor of the Google Play services library. The deprecation allows us to focus our development efforts on Google Play services and offer additional exciting features going forward. Here is the deprecation timeline:

  • On August 1, 2014, the Play Store will stop accepting new or updated apps that use the standalone Google AdMob SDK. The standalone SDK does not use the Advertising ID, and will therefore be non-compliant with the Google Play Ad Policy on this date.
  • We will stop offering technical support for questions specifically related to the standalone Android SDK on August 1, 2014.
  • Ad serving through the standalone SDK will continue to work after August 1, 2014.

There are currently no plans to stop serving ads through the standalone SDK, but we strongly encourage you to update your apps sooner rather than later to avoid the August 1, 2014 deadline. Note that the Google Play services library still supports the same devices -- you can still serve ads through this library even on devices that don’t have the Google Play store installed.

Be sure to refer to our migration guide to help you upgrade. If you have any questions about the deprecation or how to upgrade, post them on our forum. You can also stay tuned to ads-related SDK updates on the Google Ads Developers +Page.

 - , Mobile Ads Developer Relations

Ending support for iOS 5 in the IMA SDK

On February 18, 2014, we will stop providing forum support or bug fixes for iOS IMA SDK issues specifically related to iOS 5. This applies to the current beta of the iOS IMA SDK as well as all future releases.

What does this mean if an app is currently targeting iOS 5?

  • There will be no specific SDK change on February 18th that will break compatibility, so the iOS IMA SDK should continue to work with iOS 5 in the short term. However, after that date, the SDK won't be guaranteed to work for iOS 5 apps. 
  • Bugs that only affect iOS 5 will no longer be prioritized. 
  • If a specific iOS IMA SDK release significantly breaks functionality in iOS 5, it will be documented in the release notes. 
  • This support change will not require you to make any changes to your app specific to the iOS IMA SDK, but you may have to make some changes to your app to set its Deployment Target to iOS 6+. 

What about other iOS versions?

We periodically stop supporting older iOS versions when adoption levels fall below a small threshold. Any time we are preparing to end support for a major iOS release, we will make an early announcement on our blog and release notes page.

If you need any help with iOS IMA SDK issues encountered when targeting your application for iOS 6, or about the iOS IMA SDK in general, let us know on the IMA SDK forum or check out the IMA SDK iOS Quick Start Guide. Follow our Google+ page for other announcements and updates.

 - , IMA SDK Team

What to watch? Our APIs can help!

It’s an age-old question: what to watch? Applications that integrate with YouTube have access to countless hours of videos, and, as a developer, you have an interest in helping your users find the videos and channel most relevant to them. This blog post will walk you through a few ways that you can use the latest YouTube Data API to discover great content.

If you have an OAuth 2 token for the current user, your application can make a call to youtube.activities.list(part=”snippet”, home=true) to get back a list of videos and channels similar to the recommendations that the user would see on the YouTube.com home page. These results are customized for each individual user, and the list is kept fresh automatically, so it’s a great way to present your users with content they’re likely to enjoy.

Even if your users are not logged in, there are still are a few charts and guides at your disposal to aid in discovery.

To find popular videos your users might want to watch, youtube.videos.list(part=”snippet”, chart=”mostPopular”) is the basic API call to use. By default, it will return a list of videos in any category that are considered popular globally. If this is too broad a list, though, you can narrow things down using the regionCode or videoCategoryId (or both) parameters. regionCode can be set to a two-letter country code to retrieve a list of videos popular in that specific country (though not every country is currently supported). videoCategoryId needs to be set to an ID corresponding to one of our existing video categories—you can retrieve a list of valid categories and their corresponding IDs via youtube.videoCategories.list(part=”snippet”, regionCode=”XX”), where “XX” is also a two-letter country code.

There’s an analogous set of API calls that you could make to find channels your users might be interested in. youtube.guideCategories.list(part=”snippet”, regionCode=”XX”) will return a list of all the channel categories that are available in a given country. Once a user has chosen a category, you can get back a list of the most relevant channels in that category via a call to youtube.channels.list(part=”snippet”, categoryId=”CATEGORY_ID”), where “CATEGORY_ID” is the ID of the guide category you’re interested in. At that point, you could display a list of the most recent videos associated with each channel, and give your users the option of subscribing (assuming they grant OAuth 2 authorization first).

All of these examples assume that you’re using the latest version of the YouTube Data API, v3. Developers still using the Data API v1 or v2 should be aware of some recent changes to our older content discovery mechanism, standard feeds. As explained in the documentation, all of the previous different types of standard feeds are now returning the equivalent of the most_popular feed, with the time parameter set to “today”. If you are still using v1 or v2, there’s no time like the present (time=”today”, if you will) to make the switch to v3.

Update: For a walkthrough and demos of all the API calls, please watch this episode of YouTube Developers Live:



Cheers,