Recently, we announced the availability of native ads for apps in DFP. Here, we’re going to introduce you to creating native creatives with the DFP API using the ads Java client library. A native creative consists of a set of assets (headline, image, etc.) which are sent to mobile apps for custom rendering in their own code (see our Android and iOS developer guides for details).

Native creatives are actually just another type of template-based creative. While the DFP UI abstracts this, in the API you create a native creative using a TemplateCreative with the system-defined native template ID. The creative template IDs available in your network can be retrieved by the getCreativeTemplatesByStatement method in the CreativeTemplateService. You can also view these IDs in the UI under Delivery > Creatives > Native ad formats (see the ID below each native ad format name in the table). The native app install template ID is 10004400.

    TemplateCreative nativeAppInstallCreative = new TemplateCreative();

Because native creatives do not have a predetermined size, you need to set a placeholder size of 1x1.

    Size size = new Size();

Finally, specify a name and destination URL; this example is for the Pie Noon app:

    nativeAppInstallCreative.setName("Pie Noon native ad");

Settings specific to native creatives are set via template variables. An app install native creative requires the following unique template variable names to be set:

  • Headline
  • Body
  • Image
  • Price
  • Appicon
  • Calltoaction
  • Starrating
  • Store
  • DeeplinkclickactionURL

Note that creative template variables are case sensitive and those of type AssetCreativeTemplateVariableValue (“Image” and “Appicon”) must have a unique filename.

You can find the full Java example on how to create native creatives in our GitHub repository here. All of our other ads client libraries have similar examples.

As always, if you have any questions, feel free to drop us a line on the DFP API forums or the Ads Developer Google+ page.


Fall 2015 AdWords API Workshop registration is now open. Access the registration forms on the workshop website at

Once you choose a location we'll send you an email confirming your registration.

Workshops will be held on the following dates and locations:

  • New York City: October 20
  • San Francisco: October 22
  • London: October 27
  • Hamburg: October 29
  • Tokyo: October 29
  • Amsterdam: November 3

These workshops are technical in nature and are ideal for API developers. We hope to see you at these events. Register today!

If you have any questions about the AdWords API Workshops, you can post them on our forum. Check out our Google+ page for AdWords API updates.

We have added support for AdWords API v201506 reports in AdWords Scripts. This version adds support for FINAL_URL_REPORT, the Upgraded URLs-compatible replacement for the DESTINATION_URL_REPORT.

This version also introduces several changes to the reporting columns
If you use API versioning in your reports, then you need to modify your code to use v201506 as shown below. If you don’t use API versioning, no code changes are required.
var report =, {
   apiVersion: 'v201506'
If you have any questions about this feature or AdWords scripts in general, you can post them on our developer forum.

We are updating the referer of ad clicks to improve security and system reliability for users searching on Google. Starting within October, the referer for many ad clicks will only contain the Google domain from which the click occurred (domains like or This means that we will no longer be communicating specific paths such as “” or “”

While the referer will no longer differentiate Google’s organic search clicks from ad clicks, and in some cases may be absent entirely, there are still multiple strategies to track the origin of your clicks. Recommended strategies include: This change is a continuation of our general user security efforts. Users are safer when sites use HTTPS instead of HTTP, which is why we encourage the use of HTTPS. In fact, in August 2014 we began to use HTTPS as a ranking signal.

By default, browsers do not pass a referer from HTTPS sites to HTTP sites. To minimize advertiser disruption, we implemented a custom ads solution back when the Google search page migration to HTTPS took place. Now, many modern web browsers provide better control over referer behavior via the meta referer tag. This development is an improvement over our previously-implemented custom ads solution both in terms of reliability and latency.


The AdWords API Workshops are back, and the registration form and agenda will be available on the website soon: In the meantime, you may review the site Resources section for previous event presentations.

These workshops are a series of technical events, ideal for those who are working with the AdWords API.

Workshops will be held on the following dates and locations:

  • New York City - October 20
  • San Francisco - October 22
  • London - October 27
  • Hamburg - October 29
  • Tokyo - October 29
  • Amsterdam - November 3

Stay tuned and keep an eye on the website for more details on how to register.

--AdWords API Team

AdWords Scripts now support negative keyword and excluded ad placement lists, and the ability to share them across campaigns. Follow these links for implementation details and code examples: We have also released a new solution named Master Negative List that uses this feature to maintain a master list of negative keywords and placements for AdWords accounts. The list of negative criteria can be managed from a spreadsheet. Separate versions are available for AdWords accounts and manager accounts.

Special thanks goes to Terence Nip, who implemented this feature during his summer internship at Google.

Give this feature a try and let us know what you think! You can post your questions and feedback on our developer forum.


Today we’re expanding on our earlier blog post, Manual ad break playback in the IMA SDKs. One of the major benefits mentioned in that blog post is the ability to let your users skip ads they’ve already seen when they resume a video stream they previously suspended. We’re going to show you how to implement that functionality. For the purposes of this demo, we’ll be using the HTML5 SDK, but the principles outlined here can be used to achieve the same functionality in all four of our SDK flavors.


If you’d like to follow along with these samples, you’ll need to first:

  1. Get a copy of our simple sample for HTML5.
  2. Modify that sample to disable automatic playback of ad breaks, as outlined in this guide. Be sure to remove the original call to adsManager.start() in onAdsManagerLoaded!
  3. Change the ad tag to a playlist with multiple mid-rolls (like this one) so you can see the behavior in action.

Step 1: Saving the user’s progress

The first step towards our ultimate goal is to save the current time of the video when the user leaves the page. For simplicity’s sake, we’re going to be using HTML5’s built-in localStorage object. We’re going to override window.onbeforeunload to grab the current time of the video element when the user leaves the page and save it in local storage.

function init() {
  videoContent = document.getElementById('contentElement');
  playButton = document.getElementById('playButton');
  playButton.addEventListener('click', requestAds);

  window.onbeforeunload = onUserExit;

function onUserExit() {
  if (videoContent) {
    localStorage.setItem('watched_time', videoContent.currentTime);

Step 2: Restoring the user’s progress

Now that we’re saving the user’s progress, we’ll want to restore the video to that point when the user returns to the page. We’re going to add some code to the init method to grab the stored current time (if it exists) and seek to that time when our video loads.

function init() {
  videoContent = document.getElementById('contentElement');
  playButton = document.getElementById('playButton');
  playButton.addEventListener('click', requestAds);

  window.onbeforeunload = onUserExit;

  watchedTime = localStorage.getItem('watched_time') || 0;
  videoContent.addEventListener('loadedmetadata', function() {
    videoContent.currentTime = watchedTime;

Step 3: Skipping previously viewed ads

Now that we’re keeping track of the user’s progress and restoring that progress when the user returns, we can skip and ad breaks they watched in a previous visit. To do that, we’ll modify our adBreakReadyHandler to call adsManager.start() only when the loaded ad break is set to play after the user’s most recent saved progress. To ensure the video starts after the skipped ad breaks, we’ll also add a call to when we decide to skip an ad break.

function adBreakReadyHandler(event) {
  if (event.getAdData().adBreakTime >= watchedTime ||
      event.getAdData().adBreakTime == -1) { // -1 ensures we play post-rolls
  } else {;

That’s all there is to it! Try starting your video and watching the first mid-roll break. When you leave the page and come back, clicking the play button will result in the video playing from where you left off. The first ad break you’ll see is the second mid-roll break.

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

Have you ever wanted to advertise to people who previously visited your site or mobile app? This remarketing strategy can be implemented using the AdWords API. For example, you can target ads to people who left your website without buying anything to encourage them to return and make a purchase.

We recently updated our Remarketing and Rule-based Remarketing guides to more clearly show you how to use the API to get started quickly and implement some of the most common remarketing strategies.

Remarketing resources As always, feel free to visit us or ask questions on the AdWords API Forum or our Google+ page.

Following the release of AdWords API v201506, we've added a few additional features that are available immediately:
  • Android App ‘first open’ conversion tracking. Recently available in AdWords, this new conversion tracking solution measures when a user first opens an app after clicking on an ad and completing an Android app install. Check out the new FIRST_OPEN conversion type in the AppConversion tracker that also supports Postback URLs for Android.
  • A new report specific to final URLs: FINAL_URL_REPORT. The report replaces the deprecated DESTINATION_URL_REPORT and provides statistics aggregated at the final URL level.
We also launched account hiding support recently—see this announcement if you missed it. If you have any questions, feel free to reach us on the forum or via the Ads Developers Plus Page.