Subscribe: AdWords API Blog
Added By: Feedage Forager Feedage Grade A rated
Language: English
account  ads  adwords api  adwords  api  content  cookie reach  dfa cookie  dfa  dfp api  impression reach  new  reach dfa  reach 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: AdWords API Blog

Google Ads Developer Blog

The official blog for information about the AdWords, AdSense, DoubleClick and AdMob APIs and SDKs.

Updated: 2018-04-23T11:01:28.342-07:00


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.

Content API for Shopping Roundup


There have been some smaller API updates and announcements that we'd like to let you know about!

If you have any questions or feedback about these items or any other questions about the Content API for Shopping, please let us know on 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 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.


Improvements to the DFP API documentation


An API is only as good as its documentation, which is why we’re pleased to announce some exciting improvements to the DFP API documentation based on user feedback. We hope these changes will make your workflow a little easier.

Additional information on report entities. We have added documentation for each Dimension, DimensionAttribute, and Column that states its UI name. This mapping from API entity names to UI entity names should make it easier to mimic report queries from the UI. Also, each of these report entities now has a list of compatible report types to help you determine which entities can be used with each other before running a report query.

Filtering report entity tables. There are a large number of Dimensions, DimensionAttributes, and Columns over which you can query a report. Also, as mentioned, we have added even more useful information to these entities. In order to better navigate this large body of documentation, you can now filter these entities on their name or description by entering keywords in the textbox that appears above each table.


Overall DFP documentation search. In addition to the reporting documentation improvements, we have also improved the overall search functionality on the DFP API documentation site. When you type a query into the search bar at the top of each page, the list of suggested results are now pulled only from the latest version, which allows more results to be shown instead of showing the same result across multiple versions.

As always, if you have any questions or suggestions, feel free to reach out to us on our forum.


Sunset of DFP API v201705


On Thursday, May 31, 2018, in accordance with the deprecation schedule, v201705 of the DFP API will be sunset. At that time, any requests made to this version will return errors.

If you’re still using this version, now’s the time to upgrade to the latest release and take advantage of new features such as Preferred Deal support, reporting time zone configuration, and reporting currency configuration.

In order to upgrade, check the release notes to identify any breaking changes, grab the latest version of your client library, and update your code.

Significant changes include:

This is not an exhaustive list, so as always, don't hesitate to reach out to us with any questions. To be notified of future deprecations and sunsets, join the DFP API Sunset Announcements group and adjust your notification settings.


AdWords and DFP client library for Java will soon require Java 8+


Starting on July 1, 2018, all releases of the Google Ads API Client Library for Java will only be compatible with Java 8 (1.8) and higher.

Why this change is happening
The primary reasons for this change are:
Next steps
If you are using Java 8 or higher, no action is required.

If you are still using Java 7, you'll have to migrate your runtime to Java 8 or higher. Check out the Java 8 adoption guide from Oracle to get started.

Still have questions? Feel free to file an issue on the library's issues page or contact us via our Google+ page.

Support for v201802 reports in AdWords scripts


We have added support for AdWords API v201802 reports in AdWords scripts. The key changes in this release include:
  • A new report type, LANDING_PAGE_REPORT, to provide performance stats for the pages that receive traffic from your ads.
  • ConversionLagBucket field added to various reports to help you determine how long it takes customers to convert.
  • New fields added to support Gmail ads.
Read the AdWords API release notes for complete details, including additional features not listed here.

If you use API versioning in your reports, you need to modify your code to use v201802:

var report =, {
apiVersion: 'v201802'
If you don't use API versioning, no code changes are required. We are updating the default reporting version to v201710 along with this change, and your reports will upgrade automatically.

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

Onboarding for local inventory ads via the Content API for Shopping


Today, we're announcing the ability to configure your local inventory ads (LIA) settings and link Google My Business (GMB) accounts via the Content API for Shopping. This allows you to onboard accounts for LIA programmatically, instead of needing to manually configure each account separately via the Merchant Center website.

The new Liasettings service lets you perform the following actions via the Content API: In addition, the new googleMyBusinessLink field in the Accounts resource states which business account should be linked. After setting this field, you can provide inventory information for the locations in that business account by uploading product and inventory information either through local product feeds and local product inventory feeds or through the Content API for Shopping with the channel field set to "local".

If you have any questions or feedback about these new features or any other questions about the Content API for Shopping, please let us know on the forum.

Google Media Framework for Android is Deprecated


As previously announced, as of March 15th, 2018, the Google Media Framework (GMF) for Android is deprecated in favor of the IMA ExoPlayer plugin. All development and support for GMF has been halted. If you are a GMF Android user, we recommend you migrate to the IMA ExoPlayer plugin at your earliest convenience. Alternatively, to keep using GMF Android, you will have to fork and maintain it yourself.

Note: We are NOT deprecating GMF for iOS.

If you have any questions, feel free to contact us via the IMA SDK developer forum.


Ad Exchange Seller REST API Deprecation Reminder


The Ad Exchange Seller REST API is deprecated. Existing API clients should migrate to the DoubleClick for Publishers API before July 26, 2018. After this date, all requests to the Ad Exchange Seller REST API will return errors.

This migration guide provides instructions for getting started, as well as a mapping of each Ad Exchange reporting metric to its equivalent in the DFP API.

For more details about reporting in the DFP API, see the reporting guide.

For general assistance with the DFP API or your migration, reach out on our developer forum.


Changes to inactive AdWords accounts


What's changing?Beginning March 26, 2018, once an AdWords account reaches 15 months without any spend, it will be canceled in order to speed up the AdWords experience and help users stay within the manager account limits. This also means that right now, if your account has reached 15 months without spend, it meets the criteria and will be canceled. After an account is canceled: get requests for ManagedCustomerService will no longer return the account.Any AdWords API request that specifies the account's customer ID in the clientCustomerId header will fail with an AuthorizationError.CUSTOMER_NOT_ACTIVE starting with v201802 and an OperationAccessDenied.ACTION_NOT_PERMITTED error for earlier versions of the AdWords API.Any unspent prepaid amount will be refunded back to the advertiser.All ads in your account will stop automatically within 24 hours.Note: Test accounts will not be canceled.What should you do?If your application issues AdWords API requests against inactive accounts, make sure you download any relevant data for those accounts before the cancellation process starts. For example, you may want to run reports to gather historical stats for the date range where the account had activity.If you are using an inactive account in order to test your integration with the AdWords API, consider creating a test account instead. Test accounts will not be canceled by the ongoing cancellation process.To avoid issues once the cancellation process starts, you can proactively cancel accounts as follows: Log into your manager account.Go to the Accounts page, where you can adjust the date range and review the performance metrics for each account under the manager account to help you identify inactive accounts.Check the box next to each account you want to cancel.Select Edit -> Cancel account.To reactivate an account, follow the instructions in the AdWords Help Center. If you are logged in as a manager account, you can show canceled accounts by adjusting the filter in the upper left corner as follows: Note: If the account is under one or more manager accounts, you will only be able to reactivate the account if doing so will not exceed the manager account limits.If you have any questions, please contact us via the forum. - Josh Radcliff, AdWords API Team[...]

AdWords API v201705 and v201708 sunset reminder


Both AdWords API v201705 and v201708 will be sunset on March 28, 2018. After this date, all v201705 and v201708 API requests will begin to fail. If you haven't already migrated to v201710, we recommend that you skip v201710 and migrate directly to v201802. Please migrate prior to March 28, 2018 to ensure your API access is unaffected.

We've prepared the following resources to help you with the migration: As always, if you have any questions about this migration, please contact us via the forum.

Announcing v201802 of the AdWords API


Today we’re announcing the release of AdWords API v201802. Here are the highlights: Global site tags and event snippets. The AdWords API now supports global site tags and event snippets, which offer more streamlined tagging for website conversions. You can find more details in the updated conversion tracking guide. Feed item targeting. The new FeedItemTargetService provides more flexible targeting options for feed items. Check out the updated feeds services guide for details. New landing page report. The new LANDING_PAGE_REPORT gives a performance breakdown for the pages where customers land after clicking your ads. Gmail ads. The AdWords API now supports an easier way to create Gmail ads with the GmailAd type. The ads overview guide contains step-by-step instructions to help you get started. 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[...]

Upcoming changes to ad network type columns in AdWords API and Scripts reports


On March 19, 2018, we are updating how AdNetworkType1 and AdNetworkType2 columns report zero impression rows related to video networks.

Currently, if you request AdNetworkType1 or AdNetworkType2 columns and request zero impression rows by setting the includeZeroImpressions flag to true, you get back zero impression rows for YOUTUBE_SEARCH and YOUTUBE_WATCH values only if you target these networks in your Advertiser account. After this change, we will always return zero rows corresponding to these network types irrespective of whether you advertise on these networks. Other network types are not affected by this change.

This change makes the behavior of YOUTUBE_SEARCH and YOUTUBE_WATCH network types consistent with the behavior of other network types. Once this change goes live, you may start seeing a higher number of zero impression rows than what you see today when requesting AdNetworkType1 or AdNetworkType2 columns along with zero impression rows.

If you have any questions about these changes, post them in our developer forum.

Announcing the IMA SDK AMP Extension


We’re excited to announce that we’ve teamed up with the Accelerated Mobile Pages team to bring you amp-ima-video, an IMA-SDK-enabled video player extension for AMP pages. This extension has been an AMP experiment for the past few months, but today we’re moving from experiment to public release.

amp-ima-video provides an AMP-enabled video player with the IMA SDK pre-integrated, so you can easily play and monetize content on your AMP pages. Simply provide your content URL and an ad tag, and we’ll handle playing back the video and ad(s). The extension currently supports linear in-stream single ads and VMAP playlists. To see it in action, check out the AMP by Example page for the extension.

If you have any questions or issues with the extension, please file them via the AMP issue tracker on GitHub.


Announcing v201802 of the DFP API


Today we’re pleased to announce several additions and improvements to the DFP API with the release of v201802. Here are the highlights: LineItemService: The API now supports the Preferred Deals lineItemType, which allows you to programmatically offer inventory to specific buyers. Check out our Preferred Deals overview for more information. PublisherQueryLanguageService: There are several new columns available through PQL in v201802. In the Audience_Segment PQL table, the newly added PpidSize column contains the number of unique viewers in a segment. In the Programmatic_Buyer PQL table, the new EnabledForPreferredDeals and EnabledForProgrammaticGuaranteed columns allow you to validate whether a buyer can be associated with a proposal based on the types of proposal line items it contains. ReportService: A number of reporting features have made it from the UI into the API in v201802. The Demand Channel dimension is now available through the API via DEMAND_CHANNEL_NAME and DEMAND_CHANNEL_ID. Also, the Request Type can be accessed via REQUEST_TYPE. You can now filter proposal line items with the PROPOSAL_LINE_ITEM_TYPE dimension attribute. Finally, you can specify the currency type with adxReportCurrency for Ad Exchange Historical reports. You can read more on how Ad Exchange report currency works in Help Center. For a full list of API changes in v201802, see the release notes. Like sands through the hourglass, so are the deprecations of our lives. If you're using v201705 or earlier, it's time to look into upgrading. Also, remember that v201702 will be sunset at the end of March 2018. As always, if you have any questions, feel free to reach out to us on the DFP API forums.  - Donovan McMurray, DFP API Team[...]

Ending support for iOS 8 in the IMA SDK


With the release of v3.7.0 of the IMA iOS SDK, we will stop providing forum support and bug fixes for iOS IMA SDK issues specifically related to iOS 8 and below.

What does this mean if an app is currently targeting iOS 8?

  • There are no changes in v3.7.0 specifically designed to break compatibility, so the iOS IMA SDK will continue to work with iOS 8 in the short term. However, future releases are not guaranteed to continue to work with iOS 8.
  • Bugs that only affect iOS 8 will no longer be investigated.
  • If you are using our GoogleAds-IMA-iOS-SDK CocoaPod and want to update to v3.7.0, you'll need to start targeting iOS 9+.

What about other iOS versions?

We periodically stop supporting older iOS versions when adoption levels fall below a certain level. Whenever we end support for a major iOS release, we make announcements on our blog and release notes page.

As always, if you have any questions, feel free to reach out to us on our support forum.


Upcoming changes to reach report metrics in DCM


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:overlapTotalRea[...]

Announcing service account creation in the Merchant Center


Today we're pleased to announce that you can now create service account keys to access the Content API for Shopping directly in the Merchant Center!
Even if you've already set up service accounts for your solutions, you can still create a new service account key here if you'd like to switch to managing your service account keys directly in the Merchant Center. See the Retrieve a service account key for authentication section of the Get Started guide for more details.

Note: This feature does not remove the other ways to create and manage Content API authentication. If you'd prefer to manage your Google API Console project and service accounts yourself, you can still follow the steps in the Service Accounts guide. If you are accessing others' Merchant Center accounts using OAuth 2.0, you'll still want to follow the steps in the Authorize Requests guide instead of using service accounts.

If you have any questions or feedback about the new service account management in the Merchant Center, or any other questions about the Content API for Shopping, please let us know on the forum.

Simpler Native Ads Implementation with the Unified Native Ads API


Today we're pleased to announce the release of the Unified Native Ads API, an easier way to implement AdMob Native Ads Advanced. This feature is now available in Google Mobile Ads for iOS, as of version 7.28.0. The Android version will be made available in an upcoming release. With this feature, the existing native ad formats in Native Ads Advanced — GADNativeAppInstallAdand GADNativeContentAd— are replaced by a single format, GADUnifiedNativeAd. The corresponding views, GADNativeAppInstallAdViewand GADNativeContentAdView, are replaced by a single corresponding view, GADUnifiedNativeAdView. Using the Unified Native Ads API, you no longer need to create UIs for ad content and app install ad formats separately. Instead you will create one UI for unified native ads, saving you time from developing and maintaining two separate UIs and associated code for the two previous ad formats, while still getting the same ad demand. Here's a short code example showing how your implementation might change when migrating from the separate formats to the new unified format: @implementation ViewController- (void)viewDidLoad { [super viewDidLoad];// Note here we request only `kGADAdLoaderAdTypeUnifiedNative` and no// longer request both `kGADAdLoaderAdTypeAppInstall` and// `kGADAdLoaderAdTypeContentAd` self.adLoader = [[GADAdLoader alloc] initWithAdUnitID:YOUR_AD_UNIT_ID rootViewController:self adTypes:@[ kGADAdLoaderAdTypeUnifiedNative ] options:nil]; self.adLoader.delegate = self; [self.adLoader loadRequest:[GADRequest request]]; }}#pragma mark - GADUnifiedNativeAdLoaderDelegate- (void)adLoader:(GADAdLoader *)adLoader didReceiveUnifiedNativeAd:(GADUnifiedNativeAd *)nativeAd { // A unified native ad has loaded, and can be displayed.}// Note that the two separate ad type delegate callbacks are no longer needed.#pragma mark - GADNativeAppInstallAdLoaderDelegate- (void)adLoader:(GADAdLoader *)adLoader didReceiveNativeAppInstallAd:(GADNativeAppInstallAd *)nativeAppInstallAd { // An app install ad has loaded, and can be displayed.}#pragma mark - GADNativeContentAdLoaderDelegate- (void)adLoader:(GADAdLoader *)adLoader didReceiveNativeContentAd:(GADNativeContentAd *)nativeContentAd { // A content ad has loaded, and can be displayed.} With the Unified Native Ads format, you still need to respect the required and recommended assets for display, and check the availability of certain assets when displaying the Unified Native Ad. For detailed documentation on how to implement Unified Native Ads, refer to the developer documentation and the updated sample code. If you have any questions about this feature in the Google Mobile Ads SDK, please drop us a line at the developer forum.  - Samuel Stow, Mobile Ads Developer Relations[...]

Changes to issue reporting in the Content API for Shopping


What's changed?There are two major changes to the resource returned by Productstatuses: a new format for product-level issues changes to the destination-specific statuses for each product A new format for product-level issuesWe've added a new itemLevelIssues field to the productStatus resource. This field contains a sequence of issue entries, similar to the dataQualityIssues field, but each entry contains different information. For now, the Content API returns both fields (see the "What do I need to do?" section for more details). Here is an example of the same issue in the old format and the new format: dataQualityIssues { "id": "validation/missing_required", "severity": "critical", "location": "title", "detail": "Invalid or missing required attribute: title"} itemLevelIssues { "code": "item_missing_required_attribute", "servability": "disapproved", "resolution": "merchant_action", "attributeName": "title", "destination": "Shopping"} As shown above, each entry in the itemLevelIssues field contains the following information: code: The issue ID Note: This ID may differ from the ID provided for the same issue in the dataQualityIssues field, as in the example above. servability: The serving status of the product based on this issue. May be one of the following string values: "disapproved": This issue has caused the associated product to be disapproved. "unaffected": This issue has not affected the servability of the associated product. resolution: Whether or not the issue requires the merchant to take action. May be one of the following string values: "merchant_action": This issue requires action on the part of the merchant to resolve. "pending_processing": This issue requires further processing from Google to resolve this issue, and you do not need to do anything. attributeName: The name of the product attribute that caused this issue, if applicable. For the "item_missing_required_attribute" issue example above, this field contains the value "title" since the product data triggering this issue did not include a title. destination: The destination to which this issue applies. For example, a given issue may affect the servability of the product for Shopping campaigns (the "Shopping" destination), but not the servability for Display Ads (the "DisplayAds" destination). Note: If an issue applies to multiple destinations, then there will be separate issue entries for each destination. To summarize, the new issue format makes explicit whether a given issue affects the servability of the product and whether or not merchant action is required to resolve the issue. Note: Currently, an entry in itemLevelIssues does not contain human-readable descriptions of the issue (e.g., the detail field in dataQualityIssues entries). This work is ongoing, and new fields that contain this information will be added in the near future. We will post another blog entry describing those fields when they are available. Changes to destination-specific product statusesWe have also added a new approvalPending field to the destinationStatuses field. If set to true, then the approvalStatus of the entry may change due to further processing. This corresponds to the pending status of products when viewed in the Merchant Center. The approvalPending field is true only if there are no issues for that product that require action by the merchant. Here's a concrete example of a destinationStatuses entry for a product that has "Shopping" as an int[...]

Sunset of DFP API v201702


On Friday, March 30, 2018, which is a one-month extension from the traditional deprecation schedule, v201702 of the DFP API will be sunset. At that time, any requests made to this version will return errors.If you’re still using this version, now’s the time to upgrade to the latest release and take advantage of new features such as support for creating ImageOverlayCreatives, and new Ad Exchange reporting dimensions and columns. In order to upgrade, check the release notes to identify any breaking changes, grab the latest version of your client library, and update your code.Significant changes include:Reporting dimensions and columns are now at parity with Ad Exchange.Editing AdUnit assignments to Placements now happens in the Placement service.AdUnit.inheritedAdSenseSettings has been replaced with AdUnit.adSenseSettings and AdUnit.adSenseSettingsSource.The AdUnit fields mobilePlatform, partnerId, isSharedByDistributor, and crossSellingDistributor have been removed.Placement fields adSenseTargetingLocale, isAdsenseTargetingEnabled, targetingDescription, targetingSiteName, and targetingAdLocation have been removed to align with the UI.Company.Type enumerations AFFILIATE_DISTRIBUTION_PARTNER and CONTENT_PARTNER have been removed. CrossSellingDistributor has been removed.Old partner metrics have been replaced by new PARTNER_MANAGEMENT fields.This is not an exhaustive list, so as always, don't hesitate to reach out to us with any questions. To be notified of future deprecations and sunsets, join the DFP API Sunset Announcements group and adjust your notification settings. - Gabe Rives-Corbett, DFP API Team[...]

Update to Engagement Reporting for Bumper Ads


Historically, AdWords API reporting has not included engagements for bumper ads. Bumper ads are video ads that are 6 seconds or shorter, appear at the beginning of a YouTube video, and can't be skipped.

Bumper ads support “drawer open” engagements, where a user can mouse over the ad to expand a widget with more information. These engagements were previously not included in the Engagements and EngagementRate fields in reports. Starting in mid-February 2018, we are going to be changing this behavior for all historical and future bumper ad reporting to include these engagements. This brings bumper ads in line with other types of video ads, which already reported these engagements.

This means that your historical reporting data, starting up to two years ago in January 2016, will be updated to include this statistic to bring it inline with future data.

If you have any questions about this migration, please contact us via the forum.

Use ad content filtering to help improve your users’ ad experience


Cross posted from the AdMob blog.

Optimizing the ad experience on your app for a varied audience can be difficult. Showing users ads that are a better fit can improve their overall ad experience and help maximize your app’s revenue.

AdMob has launched a new feature that allows you to specify the content rating for Google ads served in your app. With the new max_ad_content_rating signal, you can now choose the content rating of Google demand that you want to deliver on a per-request basis.

Four content rating choices offer you the granularity you need to provide users at each level with a better user experience. The four new content rating choices are:

  • G: Content suitable for general audiences
  • PG: Content suitable for most audiences with parental guidance
  • T: Content suitable for teen and older audiences
  • MA: Content suitable only for mature audiences

You can start sending the new max_ad_content_rating signal in the Google Mobile Ads SDK by following these Android and iOS guides. To learn more about the new signal and the content rating choices, visit the AdMob help center or contact your Google account team.

Posted by Alexa Haushalter, Product Manager, AdMob


Upcoming sunset of review extensions in February 2018


Shortly after the release of AdWords API v201802, review extensions will be sunset from both extension settings services and feed services for all API versions. What will happen?For extension settings services (AdGroupExtensionSettingService, CampaignExtensionSettingService, CustomerExtensionSettingService): You will not be able to create a new ReviewFeedItem using any of the extension settings services. No ReviewFeedItems will be returned for get() or query() requests to any of the extension settings services. For feed services (FeedService, FeedItemService, FeedMappingService): You will not be able to pass ID 8 to placeholderType of FeedMapping when creating a new feed mapping. Feeds, feed items and feed mappings related to review extensions will still be returned for get() or query() requests to FeedService, FeedItemService and FeedMappingService, respectively. For CampaignFeedService, AdGroupFeedService and CustomerFeedService: You will not be able to pass ID 8 to placeholderType of CampaignFeed, AdGroupFeed or CustomerFeed. All CampaignFeed, AdGroupFeed and CustomerFeed that are associated with review extensions (have ID 8 in their placeholderTypes) will not be returned for get() or query(). Note that you can still find historical stats for your review extensions after the sunset in PLACEHOLDER_REPORT and PLACEHOLDER_FEED_ITEM_REPORT. What should you do?If you have code that retrieves, adds or updates review extensions using any services above, please review your code before March 1 to ensure that the changes above won’t have a negative impact on your application. As always, if you have any questions, please post on the forum.  - Thanet Praneenararat, AdWords API Team[...]