Tag Archives: release

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!


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.

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.

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.

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!

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.

AdWords API release and sunset schedule in 2018

In 2016 and 2017 we supported at least three versions of the AdWords API at any given time and four versions for a brief period after each new release. This led to older versions of the API supporting outdated functionality and lacking new features.

To improve your AdWords API experience, we will be updating our release schedule. Starting in March 2018 we will only support two releases concurrently at all times, and three releases for a brief period of four weeks, allowing developers to skip a version. To get us back on schedule, we will concurrently sunset v201705 and v201708 in March 2018. This brings the average lifespan of every API version released in 2018 down to nine months.

Additionally, we will be moving back to a schedule that releases three versions per year. The 2018 releases are scheduled for February, June and September.

As usual, make sure to check our deprecation schedule for more details on sunsets. If you have any questions about the new schedule, please reach out to us on the AdWords API forum or the Ads Developers Plus Page.

Announcing v201708 of the AdWords API

Today we’re announcing the release of AdWords API v201708. Here are some of the highlights for key AdWords features: If you’re using v201609 of the AdWords API, please note that it will be sunset on October 2, 2017. We encourage you to skip v201702 and v201705 and migrate straight to v201708. Please note that v201702 is deprecated and will be sunset on February 14, 2018.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201708 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.

Announcing v201705 of the AdWords API

Today we're announcing the release of AdWords API v201705. Here are the highlights:

If you're using v201607 of the AdWords API, please note that it will be sunseton June 27, 2017. We encourage you to skip v201609 and v201702 and migrate straight to v201705. If you're using v201609, be aware it's now marked deprecated and will be sunset on October 2, 2017.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201705 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.