Today we’re announcing the release of AdWords API v201605. This is the third release that follows the new release schedule announced in January 2016. Here are the highlights:
  • Expanded Text Ads and responsive ads for Display. Support was added for creating the new ExpandedTextAd and ResponsiveDisplayAd ad types in test accounts. Give these new formats a try with your test accounts. This functionality will be made available for production accounts over the next few months.
  • Campaign bid estimates by platform. Inclusion of campaign estimates by platform was added to TrafficEstimatorService. Check out the updated Estimating Traffic guide for more details.
  • Bid modifiers for all platforms (test accounts only). Campaign and ad group bid modifiers for all platforms are now supported across all versions, but only in test accounts. Previously, platform bid modifiers were only supported for the HighEndMobile (30001) platform. This functionality will be made available for production accounts over the next few months, as mentioned in a recent Inside AdWords blog post.
  • Improved reporting on quality score. The new HasQualityScore field lets you filter reporting rows based on the presence or absence of quality score data for each criterion. In addition, the QualityScore field will now have a value of '--' on rows where HasQualityScore = false. Previously, these rows had a QualityScore value of 6 for Search campaigns, and 0 (zero) for Display campaigns.
  • Image dimensions in reports. The ImageCreativeImageHeight and ImageCreativeImageWidth fields were added to the Ad Performance report so you can retrieve image dimensions for all image ads without making multiple AdGroupAdService requests.
If you’re using v201601 of the AdWords API, please note that it’s now deprecated and will be sunset on August 23, 2016. We encourage you to skip v201603 and migrate straight to v201605.

As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201605 migration guide. The updated client libraries and code examples will be published shortly.

If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.

- Josh Radcliff on behalf of the AdWords API Team
Labels: , ,

The Mobile Ads Garage is a new series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick For Publishers. Each episode will cover one aspect of the SDK, break down the feature, and show screencasts of real implementations on both Android and iOS – all in a friendly format.

The Mobile Ads Garage is a new series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick For Publishers. Each episode will cover one aspect of the SDK, break down the feature, and show screencasts of real implementations on both Android and iOS – all in a friendly format.

With two episodes on banner ads on the books, the Mobile Ads Garage now turns its focus to interstitial ads.

Andrew and Gary the Graphics Guy are back this week with a detailed explanation of the interstitial ad lifecycle, how to load ads, and how to display at just the right time. Along the way you'll get screencasts of Android Studio and Xcode, plus links to guides, samples, and other resources.


If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

 - , Mobile Ads Developer Relations
Labels: , , , ,

One of the most frequently asked questions is how to tackle the problem of replicating the 'copy creatives' functionality in the DFP UI. While most of the time it's as simple as this trio-trio-trio of steps:

One of the most frequently asked questions is how to tackle the problem of replicating the 'copy creatives' functionality in the DFP UI. While most of the time it's as simple as this trio-trio-trio of steps:

  1. Fetch a creative using getCreativesByStatement.
  2. Give it a unique name.
  3. Create a new copy on the DFP server.

Some creative types are weak against copying techniques such as making a copy of an image creative with existing assets. The process might be a bit more complicated, but I promise you, we won’t let you walk in the tall grass alone. In the past, the asset information lived in a variety of different places. Custom, image, and template creatives all had assets defined specifically for their type, nested in non-standard locations. You then had to go and look for an assetUrl to download into a byte array so that you could set it on a new asset object. On top of this, not every creative had an assetUrl. So in some cases, the task was all but impossible.

The good news is, we’ve refactored our creative types to use the CreativeAsset object, so that each is in a more canonical location, as well as to allow for the reuse of assetIds. Rather than having an assortment of fields - different for each creative type - you have one neat asset object to encapsulate all of them. What does this mean for you? You can reuse your assets across multiple types of creatives without having to write code to handle each different type of creative. All you have to do is extract the CreativeAsset object, leaving the ID, and set it on a new creative.

You can mimic this by following an example (like this one for Java) for copying assets between image creatives.

It's super effective.

As usual, remember that no question is too Farfetch'd and feel free to reach out to us with any questions or concerns you have!

 - , DFP API Team

Labels:

AdWords API v201509 will be sunset on June 21, 2016, after which all v201509 API requests will begin to fail. This version was deprecated on February 2, 2016. If you are still on v201509, we recommend that you skip v201601 and migrate directly to v201603. Please be sure to migrate prior to sunset to ensure your API access is unaffected.

We've prepared various resources to help you 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
Labels: , ,

Today we’re pleased to announce the release of the v201605 DFP API. This release focuses on new features for reporting and sales manager.

For a full list of API changes in v201605, see the release notes.

Today we’re pleased to announce the release of the v201605 DFP API. This release focuses on new features for reporting and sales manager.

For a full list of API changes in v201605, see the release notes.

Reporting

We’ve added two new reporting features in v201605 to bring the API closer to the UI query tool. The first is a filter for First Look rows in your report. This only applies if you’re running reports on networks that are using the First Look feature. In the API, this is available as a dimension called IS_FIRST_LOOK_DEAL.

Here is a breakdown of how this dimension behaves:

  • If this dimension is not included in a report, then your report will contain First Look rows. This is the default behavior.
  • If this dimension is included and set to true, then your report will contain only First Look rows to enable you to look at First Look metrics in isolation.
  • If this dimension is included and set to false, then your report will not contain any First Look rows.

You can read more about DFP First Look and how it affects the query tool in our help center article.

The second reporting feature is more time zone settings in sales reports. For this, we’ve added a ReportQuery flag called useSalesLocalTimeZone. This option only applies to reports containing sales attributes and metrics. When set to true, all applicable attributes or metrics will be displayed or calculated using proposal or proposal line item time zones, instead of the network time zone.

Sales manager

For sales manager, we’ve added a field called nameSource on products to make it clear if the product’s name is the default name generated from its template, or has been overridden. This also allows you to revert an overridden product’s name to use the default name generated from the template.

We’ve also added the long awaited workflowProgress indicator to proposals. The WorkflowProgress contains information such as which step or rule a proposal’s workflow is currently on. This information is equivalent to the progress bar you see in the DFP web UI when viewing a proposal.

Finally, proposals now have a field called offlineErrors that contains errors that might have occurred in background processes. For example, if a proposal failed to reserve inventory, this field will be populated with an error. Proposal.hasOfflineErrors has been added to help you find proposals that have offline errors.

Deprecation

With each new release comes a new deprecation. If you're using v201505 or earlier, it's time to look into upgrading. API version v201502 will be sunset at the end of May 2016, and v201505 will be sunset at the end of August 2016.

Also, please remember that we are tightening our sunset schedule. DFP versions v201508 and v201511 will both be sunset at the same time at the end of November 2016.

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.

 - , DFP API Team

Labels:

If you've been following the AdWords API sunset and release announcements, you know that there have been some changes to batch processing: The planned sunset date of version v201601 is August, 2016, after which MutateJobService will no longer be available.

What do I need to do?
If you are still using MutateJobService, please migrate to BatchJobService ahead of August, 2016.

How do I migrate?
The migration from MutateJobService to BatchJobService is relatively straightforward and covered in the migration section of the batch processing guide. The guide also contains code examples for each client library to help you get started.

If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.

- Josh Radcliff, AdWords API Team
Labels: , , ,

In a perfect world, every creative loads instantly and renders perfectly. Unfortunately, the real world is a little more complicated. Creative performance is a real concern - slow ads can hurt user trust. Thankfully you can utilize existing tools, such as the DFP API, to help test and validate a creative's performance before it serves.

In a perfect world, every creative loads instantly and renders perfectly. Unfortunately, the real world is a little more complicated. Creative performance is a real concern - slow ads can hurt user trust. Thankfully you can utilize existing tools, such as the DFP API, to help test and validate a creative's performance before it serves.

As a starting point, let's call out a feature you may already be aware of: DFP Preview URLs. These allow you to preview a creative either on its own or in your site, before it starts serving.

Both types of preview URLs can be retrieved using the DFP API. Every creative has a previewUrl field, and you can generate in-site previews using the LineItemCreativeAssociationService's getPreviewURL method.

Using these, you can programmatically get a URL for every creative in your network and keep tabs on new or updated creatives by filtering with lastModifiedDateTime. You can test every new creative that comes into your network and make sure it's up to your standards - the files aren't too large, it renders properly, it loads quickly, and so on.

Here's what your application might look like:

As you can see, we're still missing a couple pieces of the puzzle. How do you programmatically load the preview URLs in a browser and get the measurements we want? What measurements do we want?

The first question has a straightforward answer: WebDriver. You can load the preview URL with the browser automation tool. It can take screenshots, click on elements, and extract information from a web page.

When it comes to what metrics you want to collect, it's entirely up to you. Modern browsers log a wealth of information about page performance and network timing. ChromeDriver even has an extension that sends these performance logs back to your WebDriver application in the form of logs. Using these logs you can get whatever metrics are important to you, including page load or network events.

If the performance logs are too granular, you can leverage existing tooling instead. The Google Publisher Console is great for investigating and debugging a creative's performance. Just append a URL parameter and you get access to a debugging console by pressing Ctrl+F10 (⌘+F10 on Mac).

Both of these can be done through WebDriver. Add the same URL parameter when you create an in-site preview URL (the one you create with the LineItemCreativeAssociationService) and send the key presses through WebDriver.

Let's see it in action. To test this, create a blank test page and tag it. Then use the API to get any new creatives and associate them with a test line item. Finally, use the LineItemCreativeAssociation service to get a preview URL for WebDriver.

The implementation details are up to you, but when you mix the DFP API with a browser automation tool like WebDriver, it opens up a world of testing possibilities.

 - , DFP API Team

Labels:

Ever wondered about the best ways to monetize with banner ads while maintaining a great user experience? If so, the Mobile Ads Garage is here to help. In the third episode, Andrew and Gary the Graphics Guy cover how to integrate banner ads into a mobile app's UX, with a little help from Aunt Betty, hairless cats, and discount moose repellent. You'll see detailed breakdowns of things to avoid, plus reliable best practices that you can take back to your own apps. As always, links to guides, samples, and other resources are included.

Ever wondered about the best ways to monetize with banner ads while maintaining a great user experience? If so, the Mobile Ads Garage is here to help. In the third episode, Andrew and Gary the Graphics Guy cover how to integrate banner ads into a mobile app's UX, with a little help from Aunt Betty, hairless cats, and discount moose repellent. You'll see detailed breakdowns of things to avoid, plus reliable best practices that you can take back to your own apps. As always, links to guides, samples, and other resources are included.


If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum.

 - , Mobile Ads Developer Relations
Labels: , , , , ,

The old DFP API OAuth2 scope has been deprecated. Any API requests using this scope after December 31, 2016 will fail authentication. OAuth2 requests must use the current DFP API scope (https://www.googleapis.com/auth/dfp) after that time.

The old DFP API OAuth2 scope has been deprecated. Any API requests using this scope after December 31, 2016 will fail authentication. OAuth2 requests must use the current DFP API scope (https://www.googleapis.com/auth/dfp) after that time.

How can I tell if this impacts me?

If you generated your OAuth2 refresh token after the release of v201408, no action is required. If you're a long-time API user who hasn't updated their refresh token in the last year, you need to generate a refresh token using the current DFP API scope.

If you use a service account to authenticate instead of a refresh token, verify that the scope you use to create credentials is: https://www.googleapis.com/auth/dfp.

If you're still unsure if this affects you, you can follow the steps below anyway with no negative impact.

What action do I need to take?

You have two options to ensure uninterrupted API use:
  1. Use a service account for authentication and set the current DFP API scope. Service accounts simplify the OAuth2 flow by using a public/private key pair instead of a refresh token.
  2. Use the utility provided by your client library to generate a new refresh token using your current client ID and secret. These utilities will use the current scope: After running the utility, update your credentials with the newly generated refresh token.

If you're using a different OAuth2 authentication flow, consult the documentation for your scenario and identify where the scope is being set. If you need clarification, reach out on our developer forum for additional assistance.

Why is this happening?

The OAuth2 scope for DFP was changed in v201408 to better align with the naming conventions of other Google APIs. All versions of the API that were released with the old scope have now been sunset, so the scope is now being sunset. If you have any questions, don't hesitate to post on our DFP API forum.

 - , DFP API Team

Labels: , ,

Today we're releasing v2.5 of the DCM/DFA Reporting and Trafficking API. This release includes some exciting enhancements and functionality promoted from our previous open beta, such as:

Today we're releasing v2.5 of the DCM/DFA Reporting and Trafficking API. This release includes some exciting enhancements and functionality promoted from our previous open beta, such as:

Details of these and other improvements are covered in our release notes.

Deprecation and sunset reminder

In accordance with our deprecation schedule, this release marks the beginning of the deprecation period for v2.3, which will sunset on August 31st, 2016. After this date, any requests made against v2.3 will begin returning errors.

Also be aware that the v2.2 deprecation period has been extended slightly to allow users more time to migrate. The new sunset date for v2.2 is June 7th, 2016. To avoid an interruption in service, all users must migrate off of this version by the new sunset date.

Learn More

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

- Jonathon Imperiosi, DCM API Team

Labels: ,

What is changing?

Starting June 30, 2016, you will no longer be able to upload Flash display ads in AdWords. By January 2, 2017 existing Flash ads will no longer serve on the Google Display Network. In order for your ads to keep serving, you will need to migrate any existing Flash ads to HTML5. If you need help migrating, check out the Help Center Article on updating Flash ads to HTML5 ads.

If you have video ads built in Flash, they will not be affected at this time. You do not need to migrate these ads.

Where can I learn more? Questions? Visit us on the AdWords API Forum or our Google+ page.

Nadine Sundquist, AdWords API Team
Labels: , ,

We have added support for AdWords API v201603 reports in AdWords scripts. The major changes in this release are: See the AdWords API release notes for more details.

Starting from this release, we will not switch to the latest reporting version on the day of the release by default. Instead, we will keep the previous report version as the default version for a while before switching to the latest reports version. This will give you enough time to verify your scripts and make sure it works with the latest report version.

If you use API versioning in your reports, you need to modify your code to use v201603 as shown below. 
var report = AdWordsApp.report(query, {
   apiVersion: 'v201603'
});
If you don’t use API versioning, no code changes are required. Your reports will continue using v201601 for now, and switch to v201603 when we make v201603 the default version on May 17, 2016.

If you have any questions about these changes or AdWords scripts in general, you can post them on our developer forum.

 - , AdWords Scripts Team
Labels: , ,

As you may have heard, streamlined creative types are coming to DCM. The centerpiece of this effort is the new display creative, which supports HTML5, images, and Flash. To learn more, visit our DCM user support site.

As you may have heard, streamlined creative types are coming to DCM. The centerpiece of this effort is the new display creative, which supports HTML5, images, and Flash. To learn more, visit our DCM user support site.

How does this affect DCM/DFA Reporting and Trafficking API users?

Part of this streamlining effort involves renaming some existing creative types. To minimize disruptions to our API users we will not be modifying any Creatives service types for currently released API versions. These types will only be updated for future API versions, beginning with the the v2.5 release. Due to this, current users may notice the following discrepancies between values returned by the DCM API, DCM UI, and DDM Reports:

API type Old UI & Report type New UI & Report type
CUSTOM_INPAGE Custom in-page Custom display
CUSTOM_INTERSTITIAL Custom interstitial Custom display interstitial
ENHANCED_BANNER Enhanced banner Display
ENHANCED_IMAGE Enhanced image Display image gallery
REDIRECT Redirect Display redirect
RICH_MEDIA_EXPANDING Rich media expanding Rich media display expanding
RICH_MEDIA_INPAGE Rich media in-page Rich media display banner
RICH_MEDIA_INPAGE_FLOATING Rich media in-page with floating Rich media display banner with floating
RICH_MEDIA_INTERSTITIAL_FLOAT Rich media floating Rich media display interstitial
RICH_MEDIA_MULTI_FLOATING Rich media multi-floating Rich media display multi-floating interstitial
VPAID_LINEAR Rich media VPAID linear VPAID linear video
VPAID_NON_LINEAR Rich media VPAID non-linear VPAID non-linear video

What can API users do now to prepare?

As you may have spotted in the table above, display creatives are actually an extension of an existing creative type: enhanced banner. In fact, all current and newly created enhanced banner creatives will map directly to this new type. Thanks to this, existing API versions already have full support for display creatives!

As display creatives replace the need to use HTML5 banner, Image, and Flash in-page creative types, support for inserting these legacy types will be removed in an upcoming API release. To prepare for this, API users are strongly encouraged to begin transitioning to the new display type now. We've updated our code examples to illustrate how current API versions can use display creatives to begin replacing these legacy types today:

Language Examples
.NET HTML 5 Banner Image Flash In-page
Java HTML 5 Banner Image Flash In-page
PHP HTML 5 Banner Image Flash In-page
Python HTML 5 Banner Image Flash In-page
Ruby HTML 5 Banner Image Flash In-page>

Questions about this or anything else DCM API related? Contact us via our support forum.

- Jonathon Imperiosi, DCM API Team

Labels:

If you submit AdWords API exemption requests for policy violations, then you may need to modify your application as a result of these recently announced policy changes.

What is changing?
For some policy violations, the values of the externalPolicyName, externalPolicyUrl, and externalPolicyDescription fields on PolicyViolationError will change.

What is not changing?
The policyName field value on PolicyViolationError.key will not change.

Could you remind me what a PolicyViolationError looks like?
Absolutely - glad you asked! In the following sample, after the policy changes go live, the content in externalPolicyName, externalPolicyUrl, and externalPolicyDescription may change, but the policyName field will stay the same. 
<errors xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="PolicyViolationError">
  <fieldPath>operations[0].operand.ad.headline</fieldPath>
  <trigger/>
  <errorString>AdPolicyError.POLICY_ERROR</errorString>
  <ApiError.Type>PolicyViolationError</ApiError.Type>
  <key>
    <policyName>nonstandard_punctuation</policyName>
    <violatingText>!!!</violatingText>
  </key>
  <externalPolicyName>Non-standard punctuation</externalPolicyName>
  <externalPolicyUrl/>...</externalPolicyUrl>
  <externalPolicyDescription>Google ads aren't allowed to have excessive or unnecessary punctuation or symbols such as the following:
    ...
    &lt;a href="https://support.google.com/adwordspolicy/answer/176095" target="_blank"&gt;See the full policy&lt;/a&gt;
  </externalPolicyDescription>
  <isExemptable>true</isExemptable>
  <violatingParts>
    <index>18</index>
    <length>3</length>
  </violatingParts>
</errors>
What should you do?
If your application looks for specific values of externalPolicyName, externalPolicyUrl, or externalPolicyDescription to decide if a failed AdGroupAdOperation should be resubmitted with one or more ExemptionRequests, please make the following changes:
  1. Modify your application to use the policyName instead of one of the externalPolicy fields. The values for policyName are non-localized constants, so this is a more reliable field for this use case.
  2. In early June, 2016, monitor your logs for occurrences of PolicyViolationError. Look for any new policyName values that you may want to incorporate into your application's logic for submitting exemption requests.
If you have any questions or need help, please post on the forum or the Ads Developers Plus Page.

- Josh Radcliff, AdWords API Team
Labels: ,

We’re pleased to announce the second round of workshops for AdWords scripts in 2016. The workshops will be held at the following locations: This round of workshops will cater to both novice and experienced scripters. We'll have code labs where you’ll build your own scripts from scratch with help from the Scripts team. Bring your laptop and some scripting ideas, and we’ll turn them into reality!

Whether you’re an advertiser who wants to learn about how scripts can automate your account management tasks, a developer who wants to polish your scripting skills, or a scripts enthusiast who wants to bounce around some ideas, you can find it all in these workshops.

Visit our website to check out the full agenda and sign up.

If you have any questions about the workshops, you can post them on our forums. Check out our Google+ page for AdWords Scripts updates.

Anash P. Oommen, AdWords Scripts Team
Labels: ,