[go: up one dir, main page]

What’s changing?

As announced last year, Google will stop serving political advertising in the European Union ahead of new regulation in October 2025. Today, we’re releasing updates to the Campaign Manager 360 API v4 to support this change. We’re also announcing the release of v5.

For details on the changes related to euPoliticalAdsDeclaration, continue reading this post. For details on all other changes, and the v5 release, see the release notes.

v4 Deprecation and sunset reminder

In accordance with our deprecation schedule, the v5 release marks the beginning of the deprecation period for v4, which will sunset on Feb 26, 2026. After this date, any requests made against v4 will begin returning errors.

See the migration guide for details. In most cases, you will just need to upgrade to the latest version of your preferred client library. We recommend that you review the release notes to learn about important changes you might need to be aware of.

If you have questions about this or anything else Campaign Manager 360 API related, feel free to reach out to us on our support forum.

Background

Campaign Manager 360 will require self-declaration for EU political ads. You must declare whether or not a campaign contains EU political ads when creating it.

You can also make this declaration for the advertiser as a whole. This declaration will state whether any campaigns under the advertiser will contain EU political ads. We recommend that you make the declaration at the advertiser level using the Campaign Manager 360 API or under the advertiser Properties settings in the Campaign Manager 360 UI.

Campaign Manager 360 API v4 and v5 will support the ability to declare whether a campaign contains EU political ads.

Campaign Manager 360 API

Campaign Manager 360 will start requiring declarations for new campaigns and for existing campaigns when adding a new placement, ad, or creative.

Campaign Manager 360 API v5 will require the field euPoliticalAdsDeclaration for new campaign resources and for existing campaign resources when adding a new placement, ad, or creative.

The field euPoliticalAdsDeclaration will be added to the following API objects in v4 and v5 to surface self-declaration at different resource levels:

  • Campaign objects for getting and setting the declaration at the campaign level.
  • Advertiser for getting and setting the declaration at the advertiser level.

The following table lists the values that can be set for this field on Advertiser resources.

Value
ADVERTISER_PLANS_TO_SERVE_EU_POLITICAL_ADS
ADVERTISER_DOES_NOT_PLAN_TO_SERVE_EU_POLITICAL_ADS

The following table lists the values that can be set for this field on Campaign resources.

Value
CONTAINS_EU_POLITICAL_ADS
DOES_NOT_CONTAIN_EU_POLITICAL_ADS

If you set the euPoliticalAdsDeclaration field to ADVERTISER_DOES_NOT_PLAN_TO_SERVE_EU_POLITICAL_ADS for the parent advertiser, the field will be backfilled for existing campaigns to match and new campaigns will use that value if another is not set at creation.

What do I need to do?

We recommend that you make the declaration at the advertiser level. You can do this either by setting the euPoliticalAdsDeclaration field using the API when calling the advertisers.insert, advertisers.patch or advertisers.update methods, or in the Campaign Manager 360 UI under the advertiser Properties setting.

If you can’t declare at the advertiser level or have declared that EU political ads may be served under your advertiser, you will need to provide declarations at the campaign level by updating your use of the following API methods:

How will this affect my campaign serving?

Refer to the Campaign Manager 360 Help center article to learn more about how this declaration affects your ad serving.

Learn More

As with every new version of the Campaign Manager 360 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!

Campaign Manager 360 API v3.5 will sunset on Feb 20th, 2023. After this date, all requests made to v3.5 of this API will fail. If you're still using this version, you must migrate to the most current release to avoid an interruption in service.

See the migration guide for details. Most likely, you just need to adopt the latest version of your preferred client library. However, all users are advised to review the release notes to learn about important version differences you may need to be aware of.

If you have questions about this or anything else Campaign Manager 360 API related, feel free to reach out to us on our support forum.

Today we're releasing v4 of the Campaign Manager 360 API. This release adds support for the following Billing Services:
  • Advertiser Invoices
  • Billing Assignments
  • Billing Profiles
  • Billing Rates
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 depreciation period for v3.5, which will sunset on Feb 15, 2023. After this date, any requests made against v3.5 will begin returning errors.

See the migration guide for details. For most, you just need to upgrade to the latest version of your preferred client library. We recommend you to review the release notes to learn about important changes you might need to be aware of.

If you have questions about this or anything else Campaign Manager 360 API related, feel free to reach out to us on our support forum.

Learn More
As with every new version of the Campaign Manager 360 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!

Campaign Manager 360 API v3.4 will sunset on Jan 10th, 2022. After this date, all requests made to v3.4 of this API will fail. If you're still using this version, you must migrate to the most current release to avoid an interruption in service.

See the migration guide for details. Most likely, you just need to adopt the latest version of your preferred client library. However, all users are advised to review the release notes to learn about important version differences you may need to be aware of.

If you have questions about this or anything else Campaign Manager 360 API related, feel free to reach out to us on our support forum.

Today we're releasing v3.5 of the Campaign Manager 360 API (previously 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 reminderIn accordance with our deprecation schedule, this release marks the beginning of the depreciation period for v3.4, which will sunset on Dec 24, 2021. After this date, any requests made against v3.4 will begin returning errors.

As a reminder, Campaign Manager 360 API v3.3 will sunset on June 30th, 2021. After this date, all requests made to v3.3 of this API will fail. If you're still using this version, you must migrate to the most current release to avoid an interruption in service.

See the migration guide for details. For most, migrating will be as easy as adopting the latest version of your preferred client library. However, all users are advised to review the release notes to learn about important version differences you may need to be aware of.

If you have questions about this or anything else Campaign Manager 360 API related, feel free to reach out to us on our support forum.

Learn MoreAs with every new version of the Campaign Manager 360 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!

Update (Sep 1, 2020): Support for path and path attribution report types is now available in v3.4. It has been added back to this post.

Update (Aug 7, 2020): Support for path and path attribution report types, originally listed in this blog post, was not included in the initial release of v3.4 of the DCM/DFA Reporting and Trafficking API. It has been removed from this post.

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

Details of these and 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.3, which will sunset on February 28, 2021. After this date, any requests made against v3.3 will begin returning errors.

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!

On July 14th, 2020, we will begin enforcing stricter validation for requests to the DCM/DFA Reporting and Trafficking API. This change will initially be introduced for 5% of API traffic during the week of July 14, 10% the week of July 21, 30% the week of July 28, and all requests by August 7th, 2020
As a result, your requests might begin returning additional errors. Please update your requests, as needed. 

The following list includes the error codes that you might see, as well as the recommended solutions:
  • "Invalid value - Enum" - Ensure you are using valid enum values. For more information, see the API Reference.
  • "Invalid value - Bool" - Ensure boolean fields in the request are set to true/false, rather than empty string.
  • "Invalid value - Integer ####.0" - Ensure integer fields in the request are set to valid integers.
  • "Invalid JSON Payload - NaN" - Ensure NaN does not appear in the request payload.
  • "Invalid JSON payload received. - not repeating" - Do not use arrays for non-array fields.
Method specific errors:
  • dfareporting.reports.run: "Invalid JSON payload received. Unexpected end of string. Expected a value" - Ensure the request body is completely empty.
  • dfareporting.reports.list: "Request contains an invalid argument." - Ensure that empty fields in the response contain a valid value. For example, empty array fields must be specified by an empty array, rather than an empty string or object.
  • dfareporting.files.get and dfareporting.reports.files.get: "OAuth token was passed in the query parameter. Please send it in Authorization header instead." - Requests must use the HTTP header Authorization: Bearer [ACCESS_TOKEN] to pass OAuth credentials.

Why is this changing?
Stricter validation helps ensure that problematic requests are not silently ignored, and aligns the behavior of the DCM API with that of other Google APIs.

In accordance with our deprecation schedule, we will be sunsetting version 3.2 of the API on August 31, 2019. Requests to version 3.2 will no longer work after this date, preventing you from updating and accessing information in Campaign Manager. To avoid an interruption in service, you must migrate to a newer API version as soon as possible.

To learn about changes between versions and get tips for migrating, visit the API developer site. Also consider subscribing to this blog to stay up to date about new releases, upcoming sunsets, and changes to the API.

If you have technical questions regarding new versions of the API, please reach out via the developer forum.

(If you want to continue getting email updates about our blog posts, read on. If you don't want email updates from this blog, you can skip this post.)

For some products, the Google Ads Developer team has used Google groups as a way to allow API users to subscribe and get new relevant blog posts delivered to their email address. Starting now, the way you can get email updates about blog posts is changing. We will no longer send an email to the Google group for each new blog post. We will continue to use the Google groups for other important updates, however.

For users who still want email updates, we've introduced new FeedBurner links on the right-hand panel of our blog homepage. You can subscribe to the RSS feed by clicking on the link for the product you're interested in, or subscribe by email by clicking on the [+] link to the right of the product name.

If you use any of the APIs that we discuss on this blog, make sure you subscribe to the feed to keep up with the latest news and updates:

Today we're releasing v3.3 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.2, which will sunset on August 31, 2019. After this date, any requests made against v3.2 will begin returning errors.

As a final reminder, API version 3.1 will be sunset on February 28, 2019. 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!

DCM/DFA Reporting and Trafficking API v3.0 will be sunset on November 30th, 2018. From this date onwards, all requests made against v3.0 of this API will fail. If you're still actively working with this version, we strongly encourage you to begin migrating to the most current release to avoid an interruption in service.

For most, migrating will be as easy as adopting the latest version of your preferred client library. However, all users are advised to review the release notes to learn about important version differences you may need to be aware of.

If you have questions about this or anything else DCM API related, feel free to reach out to us on our support forum.


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!

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!


Beginning the week of February 20, a number of reach report metrics in DCM will be renamed. This renaming will modify both API names and column header names in generated report files. These changes are being made to prevent confusion as new reach reports and metrics are developed. The changes are as follows:

Reach Metrics

Old API name Old column header New API name New column header
dfa:activeViewViewableImpressionReach Active View: Viewable Impression Reach dfa:activeViewViewableImpressionCookieReach Active View: Viewable Impression Cookie Reach
dfa:averageImpressionFrequency Average Impression Frequency dfa:cookieReachAverageImpressionFrequency Cookie Reach: Average Impression Frequency
dfa:clickReach Click Reach dfa:cookieReachClickReach Cookie Reach: Click Reach
dfa:impressionReach Impression Reach dfa:cookieReachImpressionReach Cookie Reach: Impression Reach
dfa:incrementalImpressionReach Incremental Impression Reach dfa:cookieReachIncrementalImpressionReach Cookie Reach: Incremental Impression Reach
dfa:incrementalClickReach Incremental Click Reach dfa:cookieReachIncrementalClickReach Cookie Reach: Incremental Click Reach
dfa:incrementalTotalReach Incremental Total Reach dfa:cookieReachIncrementalTotalReach Cookie Reach: Incremental Total Reach
dfa:totalReach Total Reach dfa:cookieReachTotalReach Cookie Reach: Total Reach
dfa:duplicateClickReach Duplicate Click Reach dfa:cookieReachDuplicateClickReach Cookie Reach: Duplicate Click Reach
dfa:duplicateClickReachPercent Duplicate Click Reach Percent dfa:cookieReachDuplicateClickReachPercent Cookie Reach: Duplicate Click Reach %
dfa:duplicateImpressionReach Duplicate Impression Reach dfa:cookieReachDuplicateImpressionReach Cookie Reach: Duplicate Impression Reach
dfa:duplicateImpressionReachPercent Duplicate Impression Reach Percent dfa:cookieReachDuplicateImpressionReachPercent Cookie Reach: Duplicate Impression Reach %
dfa:duplicateTotalReach Duplicate Total Reach dfa:cookieReachDuplicateTotalReach Cookie Reach: Duplicate Total Reach
dfa:duplicateTotalReachPercent Duplicate Total Reach Percent dfa:cookieReachDuplicateTotalReachPercent Cookie Reach: Duplicate Total Reach %
dfa:exclusiveClickReach Exclusive Click Reach dfa:cookieReachExclusiveClickReach Cookie Reach: Exclusive Click Reach
dfa:exclusiveClickReachPercent Exclusive Click Reach Percent dfa:cookieReachExclusiveClickReachPercent Cookie Reach: Exclusive Click Reach %
dfa:exclusiveImpressionReach Exclusive Impression Reach dfa:cookieReachExclusiveImpressionReach Cookie Reach: Exclusive Impression Reach
dfa:exclusiveImpressionReachPercent Exclusive Impression Reach Percent dfa:cookieReachExclusiveImpressionReachPercent Cookie Reach: Exclusive Impression Reach %
dfa:exclusiveTotalReach Exclusive Total Reach dfa:cookieReachExclusiveTotalReach Cookie Reach: Exclusive Total Reach
dfa:exclusiveTotalReachPercent Exclusive Total Reach Percent dfa:cookieReachExclusiveTotalReachPercent Cookie Reach: Exclusive Total Reach %
dfa:overlapClickReach Overlap Click Reach dfa:cookieReachOverlapClickReach Cookie Reach: Overlap Click Reach
dfa:overlapClickReachPercent Overlap Click Reach Percent dfa:cookieReachOverlapClickReachPercent Cookie Reach: Overlap Click Reach %
dfa:overlapImpressionReach Overlap Impression Reach dfa:cookieReachOverlapImpressionReach Cookie Reach: Overlap Impression Reach
dfa:overlapImpressionReachPercent Overlap Impression Reach Percent dfa:cookieReachOverlapImpressionReachPercent Cookie Reach: Overlap Impression Reach %
dfa:overlapTotalReach Overlap Total Reach dfa:cookieReachOverlapTotalReach Cookie Reach: Overlap Total Reach
dfa:overlapTotalReachPercent Overlap Total Reach Percent dfa:cookieReachOverlapTotalReachPercent Cookie Reach: Overlap Total Reach %

Unique Reach (Beta) Metrics

Old API name Old column header New API name New column header
dfa:uniqueReachClick Unique Reach: Click dfa:uniqueReachClickReach Unique Reach: Click Reach
dfa:uniqueReachImpression Unique Reach: Impression dfa:uniqueReachImpressionReach Unique Reach: Impression Reach
dfa:uniqueReachTotal Unique Reach: Total dfa:uniqueReachTotalReach Unique Reach: Total Reach

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

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!

DCM/DFA Reporting and Trafficking API v2.7 will be sunset on December 7th, 2017. From this date onwards, all requests made against v2.7 of this API will fail. If you're still actively working with this version, we strongly encourage you to begin migrating to the most current release to avoid an interruption in service.

For most, migrating will be as easy as adopting the latest version of your preferred client library. However, all users are advised to review the release notes to learn about important version differences you may need to be aware of.

If you have questions about this or anything else DCM API related, feel free to reach out to us on our support forum.

Beginning in August 2017, DoubleClick Campaign Manager (DCM) will no longer export standard tags for placements larger than 1x1. This is the next step in a phased rollout of changes aimed at aligning DCM's impression counting methodology with the latest Interactive Advertising Bureau and Media Rating Council guidelines. A full overview of these changes can be found in the DCM partner help center.

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

On August 22, 2017, the API's placements.generatetags endpoint will stop returning standard tags (PLACEMENT_TAG_STANDARD) for non-1x1 placements. Users will still be allowed to include this tag format in all generatetag requests without error, however responses will only contain standard tag data for 1x1 placements. This will be a retroactive change affecting all API versions.

What can API users do to prepare?

Users should begin updating their API workflows to request alternative tag formats, such as PLACEMENT_TAG_JAVASCRIPT or PLACEMENT_TAG_IFRAME_JAVASCRIPT, for all non-1x1 placements. Although standard tags will still be returned for 1x1 placements after August 2017, users leveraging pixels for impression tracking are encouraged to use tracking ads for this purpose, instead.

Existing non-1x1 placements trafficked using standard tags will continue to serve until October 2017. Any such placements which are part of a campaign ending later than this must be re-trafficked using an alternative tag format. Instructions for identifying these placements can be found in the DCM partner help center.

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

Today we're releasing v2.8 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 v2.7, which will sunset on November 30th, 2017. After this date, any requests made against v2.7 will begin returning errors.

As a final reminder, API version 2.6 will be sunset on May 31st, 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!

Starting in March, DoubleClick Campaign Manager (DCM) will be undergoing scheduled maintenance to make important updates to our systems. Every DCM account will be assigned a single maintenance window. However, these windows may be on different days for different accounts. More information about how this will affect the DCM product can be found in our help center.

How will this affect API users?

Maintenance is expected to last up to 8 hours per account. During that time DCM Trafficking will be read-only. While in read-only mode, all API delete, insert, patch, and update methods requiring the DCM Trafficking scope will be disabled. See the Scheduled Maintenance page on our developer site to learn more about the methods that will be impacted and the errors you may encounter.

What can API users do to prepare?

If your application accesses a single DCM account, we recommend simply planning ahead to avoid running workflows that use affected API methods during your account's maintenance window. Details of when this window will occur will be communicated in advance via in-product notification.

If your application accesses multiple DCM accounts, you may be subject to multiple maintenance windows. If it's not possible to plan around these windows, you should prepare your application to catch and handle maintenance related errors. Recommended error handling strategies include:

  • For user initiated requests, return an error to the user along with instructions to wait up to 8 hours before retrying the request.
  • For server initiated requests, retry automatically using an exponential backoff strategy. For example: pause 30 seconds before the first retry, 1 minute before the second, 2 minutes before the third, and so on up to a maximum of 8 hours. This strategy helps ensure you're not calling the API too aggressively and that your request quota is not being wasted.

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

In accordance with our deprecation schedule, we'll be sunsetting versions 2.5 and 2.5beta1 of the DCM/DFA Reporting and Trafficking API on February 28th, 2017. On this date, all requests made against these versions will begin returning HTTP 403 errors.

If you're still working with these versions, we strongly encourage you to begin migrating to the most recent release to avoid an interruption in service. If you're not sure, or would like to know more about the migration process, refer to the migration guide.

As always, feel free to reach out to us with any questions that you have.