Posted:
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 feedId that 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.

Posted:

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.

Posted:

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.

Posted:
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.

Posted:
This release of AwReporting introduces new command-line arguments that can be used to import CSV files into AwReporting without using the AdWords API. So you can download reports from the AdWords user interface, even reports not available via the AdWords API like the Video Campaign Report, and import them into your database.

Offline reports

The command-line arguments that allow the tool to import reports directly from downloaded files are:
  • onFileReport, where you specify the Report Type (same ones used in the API).
  • csvReportFile, where you specify the absolute path of the CSV file that will be imported to the database.
Here is a command-line example including the new arguments:
$ java -Xmx1G -jar aw-reporting/target/aw-reporting.jar \
      -startDate YYYYMMDD -endDate YYYYMMDD \
      -file aw-reporting/src/main/resources/aw-report-sample.properties \
      -onFileReport CAMPAIGN_PERFORMANCE_REPORT \
      -csvReportFile 
Keep in mind that AwReporting will only be able to import reports that are mapped in the aw-reporting-model module. You can check out the supported types on the project's GitHub source code page.

The CSV files must be in the same format as the ones downloaded by AwReporting via the API:
  • The first line of the file must contain a string with the file description.
  • The second line must contain the column headers with the field names.
  • The remaining lines contain the report data.
  • The last line will be ignored if it's a Total line.
Here is an example:

"ACCOUNT_PERFORMANCE_REPORT (May 1, 2015-May 10, 2015)"
Customer ID,Day,Account,Cost,Clicks,Impressions
1234,2015-05-01,Test Account,1420000,10,1978
1234,2015-05-02,Test Account,550000,4,2209
1234,2015-05-03,Test Account,1290000,6,3458
1234,2015-05-04,Test Account,320000,2,714
1234,2015-05-08,Test Account,1380000,5,2955
1234,2015-05-09,Test Account,1200000,6,2602
1234,2015-05-10,Test Account,750000,4,2793
Total, --, --,6.91,37,16709
Video Campaign Performance Reports

The AdWords API doesn't support video campaign performance reports, but you can still access the web interface and download the CSV files manually.

With the new offline import feature described above, we have added support for video campaign reports in AwReporting, allowing you to import all available fields in the web interface to the same database where the other reports are stored. We hope that this feature will make it easier to integrate systems and dashboards to the database, including video campaign performance data of clients.

To import a video campaign report CSV file, you just need to specify the report type in the onFileReport property as VIDEO_CAMPAIGN_REPORT, and point to the absolute path of the file in the csvReportFile property. The properties can be found in the source code of the project, in the ReportVideoCampaign.java entity.

Before importing the CSV files downloaded from the web interface, you will need to make sure that they are following the format described above, so AwReporting can understand it. You can find an example that we used on our unit tests in the project's source code.

You can check out these new features and the latest released version on the project's main GitHub page. And because AwReporting is open source, you can experiment with the code itself, by adding new types of reports as you need them. The project's GitHub page also includes the complete installation instructions.

If you have any questions about the tool, have ideas for new features, or find any bugs, you can post them as issues in GitHub. We maintain the tool, and the list of issues on GitHub is our first option when planning for next releases.

And of course, make sure to check out our Google+ page for client library and Ads APIs updates.

Posted:
With destination URLs becoming read-only on July 1, 2015, we’re making your migration to Upgraded URLs simpler. If you come across some extra attributes in Feed and FeedMapping, there’s a good reason for that.

We’re helping you skip the approvals process for existing site links during migration by modifying your Feeds and FeedMappings behind the scenes. The changes are already available, and you should see extra attributes in each of your Feeds and FeedMappings.

Expect to see attributes in Feeds with these FeedAttribute names:
  • SitelinkFinalUrls
  • SitelinkFinalMobileUrls
  • SitelinkTrackingUrl
The FeedMapping attributeFieldMappings now have extra AttributeFieldMappings related to these Sitelinks Placeholders:
  • FINAL URLS
  • FINAL MOBILE URLS
  • TRACKING URL
Your sitelink feeds are now compatible with the new Upgraded URLs.

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

Posted:

If you’re a DFP developer using our API, no doubt you’ve had a question or two at some point during your integration with DFP. You’ve probably visited the DFP API forums, if not posted to them. Today we just wanted to remind you of a few simple things you can do to help us answer your API questions more efficiently.

Let us know who you are

Including the following information with every question you ask helps reduce the turnaround time for your question:

Send us SOAP logs

SOAP logs contain the raw XML that describes the requests and responses of the API calls you make. These logs can help narrow down issues much faster. If you’re using one of our client libraries, you can visit its GitHub page to learn how to enable logging. For example, Java’s is here.

Here are some additional tips around SOAP logging.

  • When sending us logs, try to send the minimal amount of SOAP logs that clearly show the error or issue that’s occurring. If you send your entire SOAP log for the day, it’ll take longer for us to go through and increase your turnaround time.
  • If you’re seeing errors in your production environment and don’t have full SOAP logging enabled due to space constraints, consider logging only request IDs from the SOAP response instead. Not all errors will necessarily have a request ID, but if they do, that ID can help us look up your error.
  • If you’re not comfortable posting SOAP logs on the forums, you can either (1) paste a snippet of your code instead, or (2) reply directly to us by using reply privately to author.

Distinguish a product issue from an API specific issue

Generally, if an error or issue occurs in both the DFP web UI and API, it is most likely a product-level issue and non-specific to the API. To help determine this, you can try reproducing what you’re doing via the API in the web UI to see if you get the same error or issue. Product-level issues are better handled by your account manager or by posting to the DFP product forums.

If you’re still unsure, you can always post your issue in the API forums and we will be glad to help you out.