Tag Archives: release

Announcing v3.2 of the DCM/DFA Reporting and Trafficking API


Today we're releasing v3.2 of the DCM/DFA Reporting and Trafficking API. Highlights of this release include:
Details of these and all other changes 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 v3.1, which will sunset on February 28, 2019. After this date, any requests made against v3.1 will begin returning errors.

As a final reminder, API version 2.8 will be sunset on August 31, 2018. To avoid an interruption in service, all users are required to migrate to a newer version before the 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

Announcing v201806 of the AdWords API

Today we’re announcing the release of AdWords API v201806. Here are the highlights:
  • Mutable ads. The new AdService allows you to edit ads in place and retain performance stats for ETA, DRA, Showcase ads, and responsive search ads. Check out the updated ads overview for details.
  • Responsive search ads (beta). This new ad format allows you to provide multiple headlines and descriptions in one creative. These assets are then combined into ads that can accommodate more content -- up to 3 headlines and 2 description lines -- and can improve performance. Responsive search ads are available to whitelisted users and in test accounts.
  • Responsive display ads (beta). This new type of display ad is available to whitelisted users and will be fully supported when it launches later this summer. Responsive display ads allow you to provide multiple text and image assets in one creative, and then AdWords combines and tests these assets to show the most relevant ads to your customers across the Google Display Network.
  • Smart display campaigns (beta). The AdWords API now supports creation and management of Smart display campaigns by whitelisted users, and will also be fully supported when it launches later this summer. The new accompanying guide covers all the details.
  • Offline conversion adjustments. The new OfflineConversionAdjustmentFeedService allows you to apply conversion adjustments using the AdWords API. The updated conversions guide has more details to help you get started with this new service.
  • Dynamic Search Ads criteria. WebpageConditions for Webpage criteria now support parameters based on an exact match of URLs.
  • New promotion extension occasions. Several new occasions were added for promotion extensions.
If you’re using v201710 of the AdWords API, please note that it will be sunset on July 25, 2018. We encourage you to skip v201802 and migrate straight to v201806. If you're using v201802, be aware it's now marked deprecated.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201806 migration guide. The updated client libraries and code examples will be published within the next 48 hours.

If you have any questions or need help with migration, please contact us via the forum.
- Josh Radcliff on behalf of the AdWords API Team

Announcing v0_1 of the Google Ads API

Today we’re announcing the beta release of Google Ads API v0_1. With minor updates like this one, you’ll continue to point to v0 as your endpoint, but you will want to update your client libraries. Here are the highlights:
  • Recommendations. Recommendations provide customized suggestions to help increase your campaigns' performance. This is the first time Recommendations is being brought to you through an API.
    • The four Recommendations we currently provide in the API are:
      • Bid more efficiently with target CPA
      • Add new keywords
      • Add ad suggestions
      • Fix campaigns that are limited by budget
    • Search for Recommendations using GoogleAdsService.Search, which supports filtering and selecting with ad group, campaign, and campaign budget for supported Recommendations.
    • Retrieve and apply Recommendations using RecommendationService.
  • PHP client library. In the v0 release, we released Java, C#, and Ruby client libraries. We’re releasing a PHP client library shortly after this version.
To get started with the API, our team has put together these resources: If you have any questions or need help, please contact us via the forum.
Nadine Sundquist, on behalf of the AdWords API Team

Announcing v3.1 of the DCM/DFA Reporting and Trafficking API

Today we're releasing v3.1 of the DCM/DFA Reporting and Trafficking API. Highlights of this release include:



Details of these and all other changes 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 v3.0, which will sunset on November 30, 2018. After this date, any requests made against v3.0 will begin returning errors.

As a reminder, API version 2.8 will be sunset on August 31, 2018. To avoid an interruption in service, all users are required to migrate to a newer version before the 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

Join the beta for the new AdWords API

Today we’re announcing the beta release of Google Ads API v0. The Google Ads API is the next generation of our current AdWords API, and it can be accessed via gRPC and JSON REST from a variety of client environments. As this API gradually rolls out, it will reach full parity with the current API.

What’s in the beta?
For the beta, you have the ability to manage search campaigns from creation all the way to reporting. By getting in early, you’ll get to:
  • Integrate newer technologies like gRPC or JSON REST into your product sooner.
  • Provide feedback when requested on the beta in order to influence the new Google Ads API.
  • Try out features such as the new Google Ads Query Language that gives more querying flexibility.
  • Start using the API to query metrics with the accompanying resources and then mutate those resources. For example, you can query all the keywords that have zero impressions and then immediately mutate those keywords to change their bids.
The functionality for Google Ads API v0 includes:
  • Creating, updating, and removing search campaigns.
  • Managing campaign budgets.
  • Managing ad groups in search campaigns.
  • Managing 5 different kinds of ads in search campaigns.
  • Setting shared and portfolio bidding strategies.
  • Setting up targeting using keywords in search campaigns.
  • Retrieving detailed advertiser information.
  • Reporting on various metrics for search campaigns.
Please see the release notes for more details.

How do I join the beta?
Anyone with an existing developer token can apply to join this beta by submitting an application. People who join the beta are expected to submit feedback in order to help us make improvements.

Once you are approved, start with the Get Started guide, and get familiar with our other guides. We’ve also created client libraries for Java, C#, and Ruby with examples to help get you started.

Where do I learn more?
To get started with the API, our team has put together resources: If you have any questions or need help, please contact us via the forum.
Nadine Sundquist, on behalf of the AdWords API Team

Structured Data Files v4 now available in the DoubleClick Bid Manager API


Today we're announcing the general availability of Structured Data Files (SDF) v4 in the DoubleClick Bid Manager API. Highlights of this release include support for:
  • Bid Multipliers
  • TrueView bumper ads
  • Enhanced YouTube tracking
  • Exchange Targeting settings inheritance

Details of these features and all other changes can be found in the release notes.

All SDF users are encouraged to begin requesting v4 files to take advantage of these new features. To do so, simply pass 4 as the value of version when calling Sdf.download. For users with workflows that are dependent on older SDF formats, details of the file format changes between versions can be found in the release notes.

- Jonathon Imperiosi, DBM API Team

Announcing v201802 of the AdWords API

Today we’re announcing the release of AdWords API v201802. Here are the highlights: In addition to the above changes for v201802, the following improvements were made in all versions of the AdWords API:
  • Click types for Shopping Showcase ads. The list of click types in reports now includes values for Showcase Shopping ads interactions.
  • Member uploads by mobile ID/IDFA and address. All users of the AdWords API can now upload mobile ID/IDFA and address member data to CrmBasedUserList. Previously, these features were only available to whitelisted users.
If you’re using v201705 or v201708 of the AdWords API, please note that they will be sunset on March 28, 2018. We strongly encourage you to skip v201705, v201708, and v201710 and migrate directly to v201802. If you're using v201710, be aware it's now marked deprecated and will be sunset on July 11, 2018.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201802 migration guide. The updated client libraries and code examples will be published within the next 48 hours.

If you have any questions or need help with migration, please contact us via the forum.
- Josh Radcliff on behalf of the AdWords API Team

Announcing v3.0 of the DCM/DFA Reporting and Trafficking API

Today we're releasing v3.0 of the DCM/DFA Reporting and Trafficking API. Highlights of this major version release include: Although we strive to maintain backwards compatibility between releases, a number of enhancements in this release necessitated breaking changes to existing API workflows. Details of these and all other changes 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.8, which will sunset on August 31st, 2018. After this date, any requests made against v2.8 will begin returning errors.

As a final reminder, API version 2.7 will be sunset on December 7th, 2017. To avoid an interruption in service, all users are required to migrate to a newer version before the 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

Introducing container-diff, a tool for quickly comparing container images

The Google Container Tools team originally built container-diff, a new project to help uncover differences between container images, to aid our own development with containers. We think it can be useful for anyone building containerized software, so we’re excited to release it as open source to the development community.

Containers and the Dockerfile format help make customization of an application’s runtime environment more approachable and easier to understand. While this is a great advantage of using containers in software development, a major drawback is that it can be hard to visualize what changes in a container image will result from a change in the respective Dockerfile. This can lead to bloated images and make tracking down issues difficult.

Imagine a scenario where a developer is working on an application, built on a runtime image maintained by a third-party. During development someone releases a new version of that base image with updated system packages. The developer rebuilds their application and picks up the latest version of the base image, and suddenly their application stops working; it depended on a previous version of one of the installed system packages, but which one? What version was it on before? With no currently existing tool to easily determine what changed between the two base image versions, this totally stalls development until the developer can track down the package version incompatibility.

Introducing container-diff

container-diff helps users investigate image changes by computing semantic diffs between images. What this means is that container-diff figures out on a low-level what data changed, and then combines this with an understanding of package manager information to output this information in a format that’s actually readable to users. The tool can find differences in system packages, language-level packages, and files in a container image.

Users can specify images in several formats - from local Docker daemon (using the prefix `daemon://` on the image path), a remote registry (using the prefix `remote://`), or a file in the .tar in the format exported by "docker save" command. You can also combine these formats to compute the diff between a local version of an image and a remote version. This can be useful when experimenting with new builds of an image that you might not be quite ready to push yet. container-diff supports image tarballs and the registry protocol natively, enabling it to run in environments without a Docker daemon.

Examples and Use Cases

Here is a basic Dockerfile that installs Python inside our Debian base image. Running container-diff on the base image and the new one with Python, users can see all the apt packages that were installed as dependencies of Python.


And below is a Dockerfile that inherits from our Python base runtime image, and then installs the mock and six packages inside of it. Running container-diff with the pip differ, users can see all the Python packages that have either been installed or changed as a result of this:


This can be especially useful when it’s unclear which packages might have been installed or changed incidentally as a result of dependency management of Python modules.

These are just a few examples. The tool currently has support for Python and Node.js packages installed via pip and npm, respectively, as well as comparison of image filesystems and Docker history. In the future, we’d like to see support added for additional runtime and language differs, including Java, Go, and Ruby. External contributions are welcome! For more information on contributing to container-diff, see this how-to guide.

Now that we’ve seen container-diff compare two images in action, it’s easy to imagine how the tool may be integrated into larger workflows to aid in development:
  • Changelog generation: Given container-diff’s capacity to facilitate investigation of filesystem and package modifications, it can do most of the heavy lifting in discerning changes for automatic changelog generation for new releases of an image.
  • Continuous integration: As part of a CI system, users can leverage container-diff to catch potentially breaking filesystem changes resulting from a Dockerfile change in their builds.
container-diff’s default output mode is “human-readable,” but also supports output to JSON, allowing for easy automated parsing and processing by users.

Single Image Analysis

In addition to comparing two images, container-diff has the ability to analyze a single image on its own. This can enable users to get a quick glance at information about an image, such as its system and language-level package installations and filesystem contents.

Let’s take a look at our Debian base image again. We can use the tool to easily view a list of all packages installed in the image, along with each one’s installed version and size:


We could use this to verify compatibility with an application we’re building, or maybe sort the packages by size in another one of our images and see which ones are taking up the most space.

For more information about this tool as well as a breakdown with examples, uses, and inner workings of the tool, please take a look at documentation on our GitHub page. Happy diffing!

Special thanks to Colette Torres and Abby Tisdale, our software engineering interns who helped build the tool from the ground up.

By Nick Kubala, Container Tools team


Announcing v201710 of the AdWords API

Today we’re announcing the release of AdWords API v201710. Here are some of the highlights for key AdWords features: If you’re using v201702 of the AdWords API, please note that it will be sunset on February 14, 2018. We encourage you to skip v201705 and v201708 and migrate straight to v201710. Please note that v201705 is deprecated. As mentioned in the recent blog post on the sunset and release schedule, both v201705 and v201708 will be sunset on March 28, 2018.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201710 migration guide. The updated client libraries and code examples will be published within the next 48 hours.

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