Tag Archives: Developer

FeedMappings for location targeting available via the AdWords API

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

You will start seeing these objects if either of the following is true:
  • You created a Feed linked to your Google My Business account.
  • You created a Location targeting feed through the AdWords user interface, under Shared library -> Business data.
Why the change?
Starting with v201506, LocationGroups.feedId is required if your matching function includes a LocationExtensionOperand.

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

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

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

Learn more
Check out the following resources for more information on Location Groups: Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.
- Josh Radcliff, AdWords API Team

DFA API sunset reminder

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

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

 - , DCM API Team

Removal of MatchType.BROAD_SESSION in AdWords API reports

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

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

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

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

- Michael Cloonan, AdWords API Team

Improved Upgraded URLs validation in AdWords API

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

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

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


- Michael Cloonan, AdWords API Team

AdWords API v201409 Sunset Reminder

AdWords API v201409 will be sunset on July 28, 2015, after which all v201409 API requests will begin to fail. This version was deprecated on March 5, 2015. With the release of v201506, you now have less than 5 weeks to migrate directly to v201506 and skip v201502 entirely. Please make 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

Some minor DFP API changes related to creatives

Hello, DFP API developers! We just wanted to let you know of some minor DFP API changes that affect all versions of the API. Most likely these won’t affect your integration with DFP, but we’re announcing them here for transparency.

Deleted line item creative associations (LICAs) are no longer persisted

Deleted LICAs are no longer persisted in the product. This will affect all versions of the API. There are two things to be aware of as a result of this. First, the method getLineItemCreativeAssociationsByStatement will no longer include these deleted LICAs. Second, if you’re syncing your LICAs daily, you may notice fewer LICAs coming back. As a reminder, you can always use the action DeactivateLineItemCreativeAssociations if you want to keep them around, but not use them. This change is already in effect.

Creative placeholders are no longer assigned an ID

We are also getting rid of CreativePlaceholder.id because it is not used or referenced anywhere in the API. This field will be removed in v201508. For all versions prior to v201508, this ID now comes back as 0, instead of an ID assigned by Google. This change is also already in effect.

If you have any concerns or questions about these changes, you can always contact us on the DFP API forums and we’ll be glad to help you out.

 - , DFP API Team

Announcing v201506 of the AdWords API

Today we're announcing the release of AdWords API v201506. Here are the highlights:
  • Location extensions within a geographic area is now configurable through the API, which in previous versions was a read-only feature. LocationGroups provides a feedIdthat is now required when specifying a LocationExtensionOperand in the matching function.
  • Updates to reporting. Gmail Sponsored Promotion stats are now available in reporting. We’ve added new columns to existing reports, including the Final Url column to the Search Query report and start and end dates to Campaign Performance report. See the release notes for the complete list.
  • Improved ConstantDataService. CriterionUserInterest objects now have a new parent ID attribute that allows for navigation of the user interest taxonomy hierarchy.
  • AWQL improvements. You can now explicitly include or exclude zero impression rows when requesting reports using AWQL. Also, the DURING clause became optional when defining ALL_TIME reports. Shared set services were extended with the AWQL query() method. 
  • Improvement to labels. You can now programmatically set label descriptions and colors using the API.
If you're using v201409 of the AdWords API, please note that it's being sunset on July 28th, 2015. We encourage you to skip v201502 and migrate straight to v201506. If you're using v201502, be aware it's now marked deprecated and will be sunset on November 5th, 2015.

As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201506 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.
 - , on behalf of AdWords API Team.

IMA HTML5 Rendering

The HTML5 SDK has two main ways to render ads: what we call “standard” rendering and “custom ad playback.” To avoid confusion and to keep you all informed, here’s a breakdown of those rendering modes and how the SDK decides which to use.

Standard Rendering

If you're using the HTML5 SDK you probably have a web page playing your content in a <video> element. In standard rendering, the SDK will create another <video> element and render it in the ad display container div you provided, which should be placed on top of your video player. The ads will then play in this SDK-owned video player on top of your content player. To the user, it looks like one video player switching from content to an ad, but in reality it’s another video player appearing on top of your content to play an ad and then disappearing. For a visual representation of what’s going on, see the image below.

Why use standard rendering?

The main benefit to this standard rendering involves buffering. Using a separate video player to render ads allows us to preserve your content buffer while ads are playing. If you’re playing a pre-roll, you can start loading your content when the ad starts and buffer the content the whole time the ad is playing. For mid-rolls, the separate player allows you to preserve your content buffer while ads are playing - if your viewer has buffered 10 minutes of your content, and you play an ad at the 5 minute mark, they won’t lose the content in the buffer for 00:05:00-00:10:00.

Custom Ad Playback

As avid blog readers will know, we recommend always passing in your content video element as the custom playback element. If you’re not already doing this, check out our guide to custom ad playback. The HTML5 SDK will intelligently use custom ad playback only when it deems necessary, as described below. When it’s not necessary, it will use standard ad playback.

What is custom ad playback?

When the SDK decides to use custom playback mode, it renders video ads in the same player as your content. This means you lose the buffer-related benefits of standard rendering. If your viewer has buffered 10 minutes of your content, and you play an ad at the 5 minute mark, they will lose the content in the buffer beyond the ad. Certain ad formats (such as AdSense) require an SDK-owned player and can't play in your content player.

Why use custom ad playback?

Simply put, some platforms do not support multiple, simultaneous, active video elements. On those platforms, the SDK can’t create its own ad player because the one allotted video player slot per page is already occupied by your content player. If the SDK tries to play an ad in a second video player, it will either fail to play (freezing the player) or make it impossible for the content to restart after the ad is finished (again freezing the player). Thus we must show the ad and video content in the same player.

How does the SDK know when to use custom ad playback?

The HTML5 SDK looks at the UserAgent string of each browser on which it’s loaded. When it sees a browser that it knows has trouble with multiple video elements, it uses custom ad playback. Currently those browsers are limited to Android and iPhone. We’re in the process of phasing out custom ad playback on Android 4.0+ to bring the benefits of standard playback to users.

Now you know all there is to know about HTML5 video ad rendering. As always, if you have any questions feel free to contact us via the support forum.
 - , IMA SDK Team

Google Mobile Ads Unity Plugin v2.3.0

We’re excited to announce the v2.3.0 release of the Google Mobile Ads Unity Plugin! The new release brings support for AdMob in-app purchase ads to the Unity game engine. You can grab the updated Unity package on GitHub.

In-app purchase ads in Unity with AdMob

In-app purchase (IAP) ads are interstitial ads that display offers for your in-app products. They allow users to make purchases directly from within your app as part of your normal ad flow.

Note: The plugin currently only supports IAP ads on Android. iOS support is not yet available.

Before integrating IAP ads into your app, make sure you’ve set up an IAP house ad campaign and created an IAP house ad. You should also install the plugin as explained in the AdMob Unity Quick Start guide.

Once you’ve set up your campaign, there are five steps to integrate IAP ads:

  1. In the AndroidManifest.xml in Assets/Plugins/Android/GoogleMobileAds/Plugin, uncomment the following line to enable billing permissions: 
    <!--<uses-permission android:name="com.android.vending.BILLING"/> -->
  2. Create a class that implements the IInAppPurchaseHandler interface. See GoogleMobileAdsDemoScript.cs for an implementation example. You need to define the following methods:
    1. OnInAppPurchaseFinished -- here you credit the user with the purchase, and then call result.FinishPurchase() to finish the transaction.
    2. IsValidPurchase -- check the SKU against valid SKUs and return true if this purchase is valid.
    3. AndroidPublicKey { get; } -- return the public key for your Android app, which you obtain from the Google Play console.
  3. Pass in the above implementation of IInAppPurchaseHandler to InterstitialAd.SetInAppPurchaseHandler.
  4. Make sure you request an in-house IAP ad by setting the correct adUnitId when creating the InterstitialAd. See In-App Purchase Overview for detailed instructions on how to set up IAP house ads in your AdMob account.
  5. Add the Conversion Tracking and Remarketing SDK to the Plugins/Android directory.

That’s it!

An example IAP ad.

If you have any questions, please drop by our forum.

 - , Mobile Ads Team

Temporary limits on ad uploads in AdWords API

To ensure reliable performance for all advertisers during advanced URL upgrades, the AdWords API has placed a temporary limit on the number of AdGroupAd ADD operations that can be performed on an advertiser account per day. Other types of requests are not affected by this change. Please review the RateLimit documentation and make sure your code handles the RateExceededError properly.

During most normal operations, you won’t run into these limits. However, if you are uploading a very large amount of new ads in a short period of time and find yourself running into this error frequently, let us know on our forum and we will work with you to address the issues.

Anash P. Oommen, AdWords API Team