We’ve upgraded the AwReporting tool to use the latest AdWords API version, v201502. The code changes were made according to the migration guide.

Note that besides code changes, the database tables’ column names have also been updated to reflect the new report field names. Since these changes are scattered around many tables, you can run this version of AwReporting on a new database schema, then use the schema generation command to generate both database schemas and compare them. You can also create SQL scripts to import data from old database tables to new ones with updated column names.

We’ve put the code changes in the v201502_upgrade branch. Please feel free to pull this branch and give it a try. Remember to update the properties file to use the new report field names. This upgrade branch will be merged into the master branch at the end of May.

If you have any questions or feedback regarding this upgrade, let us know via the project’s issue tracker.

Zhuo Chen, AdWords API Team
žymės: ,

As part of our ongoing effort to improve app promotion features in AdWords, we are making some changes to mobile app install ads (also known as click-to-download ads) on the Search Network. Starting July 1, 2015, we will support the creation of app install ads for the Search Network only in the Search Network only - Mobile app installs campaign type. In addition, app install ads created for the Search Network outside of this campaign type will stop running in July 2015. This includes any app install ads running together with website text ads in a Search Network only - All features campaign.

If you are a developer who manages app install ads for the Search Network using the AdWords API, you need to perform the following changes on your end:
  • When creating new app install ads for the Search Network, make sure you create them only within Search Network only - Mobile app installs campaigns. These campaigns have their advertisingChannelType set to SEARCH and advertisingChannelSubType property set to SEARCH_MOBILE_APP.
  • If you have app install ads in your regular search campaigns, you need to move them to a Search Network only - Mobile app installs campaign. This may be done as follows:
    • Retrieve your Search campaigns containing app install ads.
    • For each campaign, create a new campaign with similar settings (such as location targeting, device targeting, ad delivery, etc.) with the advertisingChannelSubType changed to SEARCH_MOBILE_APP.
    • Mirror over your ad groups in the old campaign to the new campaign.
    • Mirror over your app install ads from the first campaign to the second campaign, in the corresponding ad groups.
    • Run an ad performance report to see how much you’ve spent on app install ads during the last month. Update your campaign budgets as follows:
      • new_campaign_daily_budget = app_install_cost / 30
      • old_campaign_daily_budget = old_campaign_daily_budget - new_campaign_daily_budget
  • [Optional] Delete or pause app install ads in the old campaign.
See our Help Center guide for more details.

To ensure uninterrupted serving of app install ads on the Search Network, make sure you move them to a Search Network only - Mobile App installs campaign before July 1, 2015.

If you have any further questions about this change, let us know via our forum or Google+ page.

Anash P. Oommen, AdWords API Team
žymės: ,

Today we’re announcing the release of beta version 13 of the IMA SDK for iOS. This release includes two new major features:

  1. The SDK can be included as a framework in your project.
  2. The SDK now supports ad playing in the background.

Today we’re announcing the release of beta version 13 of the IMA SDK for iOS. This release includes two new major features:

  1. The SDK can be included as a framework in your project.
  2. The SDK now supports ad playing in the background.

Importing the SDK as a Framework

Prior to today’s release, importing the SDK involved manually adding every header file to your project, importing every header file individually in your source, and manually including the required frameworks. With the new framework model, you can add a single .framework file to your app and replace all of your header import source lines with a single import statement.

For CocoaPods Users

If you use CocoaPods, your build will fail after you update to beta 13. But fear not, you can fix this in a matter of seconds with the following steps:

  1. Locate and remove each instance of an imported IMA header file in your source (these will look like #import “IMA<something>.h”).
  2. Add the following line to the first header or implementation file to access an IMA object: 
    @import GoogleInteractiveMediaAds;

For Manual Importers

If you don’t use Cocoapods, your path to upgrade is slightly different. You can update using the following steps:

  1. Remove all of the IMA header files and the IMA library file from your project.
  2. Under "Build Phases” > “Link Binary With Libraries”, click the plus sign, select “Add Other...”, and navigate to the downloaded and extracted SDK files. Select GoogleInteractiveMediaAds.framework from whichever folder applies to your implementation (with or without AdMob) and click “Open”.
  3. Follow the two steps above for CocoaPods users.

Background Ad Playback

Since our launch, one of the most requested features has been background ad playback. Suppose, for example, you author a music streaming app, and you want to be able to request and play ads in the background. With today’s release, however, we now support requesting and playing ads in a background service. For more info and implementation instructions, see our Background Ad Playback guide.

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

 - , IMA SDK Team
žymės: ,

Do you use LocationGroups in CampaignCriterion? If so, read on to learn about a new key in the Forward Compatibility Map to identify whether a Location Group is compatible with the AdWords user interface or the API.

Through the Campaign Settings tab of the user interface and the AdWords API CampaignCriterionService, you can create a LocationGroups campaign criteria to target locations within a specific radius around all of your campaign's location extensions.


The user interface also allows you to further restrict the LocationGroups criterion to location extensions within geographical targets or Cities-DMA regions. However, the AdWords API does not currently support modifying these additional settings.

To indicate in the AdWords API that someone created a configuration of the latter form through the user interface, the CampaignCriterion.forwardCompatibilityMap has a new key called LocationGroups.locationId.

Key
Read-Only
Value Description
IMPORTANT
Service
CampaignCriterionService
Entity
CampaignCriterion
Key Name
LocationGroups.locationId
Yes
The Location criterion ID chosen for the LocationGroups criterion from Geographical Targeting or Cities-DMA Regions. For example, an ID of 2752 indicates targeting around location extensions within Sweden.
If this key appears in CampaignCriterion .forwardCompatibilityMap, then re-adding the LocationGroups after removal or using a copy of the LocationGroups may result in a loss of configuration information.

We’re working to support the geographical targets and Cities-DMA regions option in future API versions.

Be on the lookout for an upcoming addition to the Forward Compatibility Map regarding which feed ID will be used for proximity targeting.

Questions? Visit us on the AdWords API Forum or our Google+ page.

Nadine Sundquist, AdWords API Team
žymės: , , ,

It's that time again - time to say goodbye to another version of the DFP API. In accordance with our deprecation schedule, v201403 has been deprecated and is scheduled for sunset on Tuesday, June 30 2015. At that time, any requests made to v201403 will return errors.

It's that time again - time to say goodbye to another version of the DFP API. In accordance with our deprecation schedule, v201403 has been deprecated and is scheduled for sunset on Tuesday, June 30 2015. At that time, any requests made to v201403 will return errors.

If you're currently using v201403, there's still time to migrate to the latest and greatest v201502. To do so, check the release notes to identify any breaking changes, grab the latest version of your client library, and update your code!

Things to look out for include:

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

 - , DFP API Team

žymės: , ,

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.

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

žymės: , , ,

Since 2008 we’ve been working to make sure all of our services use strong HTTPS encryption by default. That means people using products like Search, Gmail, YouTube, and Drive will automatically have an encrypted connection to Google. In addition to providing a secure connection on our own products, we’ve been big proponents of the idea of “HTTPS Everywhere,” encouraging webmasters to prevent and fix security breaches on their sites, and using HTTPS as a signal in our search ranking algorithm.

This year, we’re working to bring this “HTTPS Everywhere” mission to our ads products as well, to support all of our advertiser and publisher partners. Here are some of the specific initiatives we’re working on:
  • We’ve moved all YouTube ads to HTTPS as of the end of 2014.
  • Search on Google.com is already encrypted for a vast majority of users and we are working towards encrypting search ads across our systems.
  • By June 30, 2015, the vast majority of mobile, video, and desktop display ads served to the Google Display Network, AdMob, and DoubleClick publishers will be encrypted.
  • Also by June 30, 2015, advertisers using any of our buying platforms, including AdWords and DoubleClick, will be able to serve HTTPS-encrypted display ads to all HTTPS-enabled inventory.
Of course we’re not alone in this goal. By encrypting ads, the advertising industry can help make the internet a little safer for all users. Recently, the Interactive Advertising Bureau (IAB) published a call to action to adopt HTTPS ads, and many industry players are also working to meet HTTPS requirements. We’re big supporters of these industry-wide efforts to make HTTPS everywhere a reality.

Our HTTPS Everywhere ads initiatives will join some of our other efforts to provide a great ads experience online for our users, like “Why this Ad?”, “Mute This Ad” and TrueView skippable ads. With these security changes to our ads systems, we’re one step closer to ensuring users everywhere are safe and secure every time they choose to watch a video, map out a trip in a new city, or open their favorite app.

Neal Mohan, VP Product Management, Display and Video Ads
Jerry Dischler, VP Product Management, AdWords
žymės: ,

We have launched the Google Mobile Ads Unity Plugin v2.2.1. The updated v2.2.1 Unity package is available for download on GitHub here.

Multiple ad positions

Google Mobile Ads Unity Plugin v2.2.1 introduces support for additional banner position locations. The full list of banner positions is as follows:

We have launched the Google Mobile Ads Unity Plugin v2.2.1. The updated v2.2.1 Unity package is available for download on GitHub here.

Multiple ad positions

Google Mobile Ads Unity Plugin v2.2.1 introduces support for additional banner position locations. The full list of banner positions is as follows:

  • Top
  • Bottom
  • TopLeft
  • TopRight
  • BottomLeft
  • BottomRight

The additional positions are specified by setting the AdPosition value when instantiating a bannerView:

//Create a banner at the top-right of the screen.
BannerView bannerView = new BannerView(adUnitId, AdSize.Banner, AdPosition.TopRight);

iOS Ads SDK 7.0.0 Compatibility

With the v7.0.0 release, the iOS Ads SDK became a module framework and Google Mobile Ads Unity Plugin v2.2.1 complies with this change. For modules to work, you must enable them in the project build settings. Search for "modules", and set Enable Modules to YES. The Link Frameworks Automatically option should be set to YES as well.

Unity 5.0 and ARC

Unity 5.0 has moved out of beta and brings with it support for Automatic Reference Counting (ARC) for iOS. v2.2.1 of the Unity plugin takes advantage of ARC with no additional changes in project settings or code.

The source code and a sample app for the plugin are available on our GitHub repo. A changelog for this release is listed here. If you have any questions about Unity integration, you can reach us on our forum. Remember that you can also find us on Google+, where we have updates on all of our Google Ads developer products.

 - , Mobile Ads Developer Relations
žymės: ,

Today we're pleased to announce v2.1 of the DCM/DFA Reporting and Trafficking API. This release introduces some exciting new functionality, including: All users are encouraged to adopt this new version and begin making use of its enhanced feature set. If you're still working with the legacy DFA API, please note that it will be sunset on September 30th, 2015. We recommend that these users skip v2.0 and migrate straight to v2.1.

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 getting 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!

 - , DFA API Team
žymės:

A few weeks back we hosted a workshop for the Display Ads APIs and SDKs where we gave presentations on the DFP API, IMA SDK, and Mobile Ads SDK. If you weren’t able to attend, or want a refresher on something you saw that day, you can check out our presentation videos and slides. If you have any questions about those videos, feel free to ask on our respective forums:

A few weeks back we hosted a workshop for the Display Ads APIs and SDKs where we gave presentations on the DFP API, IMA SDK, and Mobile Ads SDK. If you weren’t able to attend, or want a refresher on something you saw that day, you can check out our presentation videos and slides. If you have any questions about those videos, feel free to ask on our respective forums:

 - , IMA SDK Team
žymės: , ,

Starting today, the DCM/DFA Reporting and Trafficking API is available as an advanced Google service in Google Apps Script. This service allows users to easily integrate their DCM reporting and trafficking data with Google Docs and Sheets, schedule updates using triggers, and much more.

Accessing the API from Apps Script is simple: just enable the service and it's ready to use. Authentication is handled automatically and editor conveniences such as autocomplete make it easy to start writing code right away. As an example, here's a snippet of code that shows how to list all user profiles available to your Google account: 
function listUserProfiles() {
  // Retrieve the list of available user profiles
  var profiles = DoubleClickCampaigns.UserProfiles.list();

  if (profiles.items) {
    // Print out the user ID and name of each
    for (var i = 0; i < profiles.items.length; i++) {
      var profile = profiles.items[i];
      Logger.log('Found profile with ID %s and name "%s".',
        profile.profileId, profile.userName);
    }
  }
}
To get started, check out the service documentation, which contains additional examples, as well as the full API reference documentation. If you have any questions, visit the API forum or reach out to Google Apps Script support.

 - , DFA API Team
žymės: ,

Imagine you’ve just finished creating a line item targeting mobile devices in DFP, and your manager comes to you and says, “Bad news! Our Android developer was just eaten by a bear, so now it’s your job to get that line item into our new app.” Don’t worry! Displaying DFP ads in Android applications is surprisingly easy.

Imagine you’ve just finished creating a line item targeting mobile devices in DFP, and your manager comes to you and says, “Bad news! Our Android developer was just eaten by a bear, so now it’s your job to get that line item into our new app.” Don’t worry! Displaying DFP ads in Android applications is surprisingly easy.

First, check your configuration

If you’re already using the Mobile Ads SDK in your project, you’re ready to go. If not, check our quick starts for Android Studio and Eclipse to learn the best way to include the SDK.

Retrieve your ad unit ID and size

To display your new line item, you’ll need to retrieve its ad unit ID from DFP. Log into your account, locate the ad unit that targets the new line item, and look for a “Generate tags” button to the right of its name. Clicking that button will display a dialog with some options for the type of tag to generate:

Select “Mobile applications” in the Tag Type dropdown, and you’ll see the correct ad unit ID and ad unit size for your line item. Armed with those two pieces of info, you’re ready to start coding.

Place a PublisherAdView

DFP banner ads are displayed with the PublisherAdView class. It’s possible to create instances on the fly and add them to a layout programmatically, but the better practice is to define them in your XML layout files. Here’s an example element:

<com.google.android.gms.ads.doubleclick.PublisherAdView
    android:id="@+id/banner_ad"
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    ads:adSize="320x50"
    ads:adUnitId="/1234567890/DemoAccount/BearRepellent"/>

Note the adSize and adUnitId attributes. These should be set to match the ad unit ID and size shown in the Generate Tags dialog. See our banner guide for more information about setting custom or multiple sizes.

Request an ad

With the PublisherAdView defined in your layout file, you just need to add a few lines of code to its corresponding Java class:

PublisherAdView adView = (PublisherAdView)findViewById(R.id.banner_ad);
PublisherAdRequest request = new PublisherAdRequest.Builder().build();
adView.loadAd(request);

PublisherAdRequest.Builder is a factory class that builds PublisherAdRequest objects. This example uses a simple, unmodified request, but there are a number of ways to add custom targeting, network extras, and test device information when building your own. See the targeting section of our banner guide for details.

Enjoy your line item

With the layout updated and request code in place, your app is ready to show an ad!

Feel free to use the code from this example in your own applications, and if you have any questions, come and see us on our forum.

 - , Mobile Ads Developer Relations
žymės: , ,