Subscribe: AdWords API Blog
http://adwordsapi.blogspot.com/rss.xml
Added By: Feedage Forager Feedage Grade A rated
Language: English
Tags:
ads  adwords api  adwords  api  content  cookie reach  cookie  dfa cookie  dfa  express  new  reach dfa  reach  release  sdk 
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-02-14T14:59:01.705-08:00

 



Announcing the IMA SDK AMP Extension

2018-02-13T13:57:37.120-08:00

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.

(image)



Announcing v201802 of the DFP API

2018-02-13T10:19:27.244-08:00

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

2018-02-12T11:05:46.954-08:00

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.

(image)



Upcoming changes to reach report metrics in DCM

2018-02-07T11:03:38.441-08:00

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



Announcing service account creation in the Merchant Center

2018-02-06T10:48:17.256-08:00

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!
(image)
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.
(image)



Simpler Native Ads Implementation with the Unified Native Ads API

2018-02-06T10:01:40.376-08:00

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

2018-02-06T04:56:11.238-08:00

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 intended destination with approval pending on further processing: { "destination": "Shopping", "intention": "required", "approvalStatus": "disapproved", "approvalPending": true} In addition, the destinationStatuses field contains only entries for intended destinations. That is, this field will no longer contain statuses for excluded destinations. Due to this, the intention field[...]



Sunset of DFP API v201702

2018-01-31T13:29:48.521-08:00

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

2018-01-24T10:26:52.696-08:00

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.
(image)



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

2018-01-18T16:52:26.353-08:00

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

(image)



Upcoming sunset of review extensions in February 2018

2018-01-12T08:54:46.314-08:00

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



AdWords API v201702 sunset reminder

2018-01-10T10:41:11.939-08:00

AdWords API v201702 will be sunset on February 14, 2018. After this date, all v201702 API requests will begin to fail. Given the upcoming sunset of v201705 and v201708 simultaneously in March of 2018, we strongly recommend that you skip v201705 and v201708 and migrate directly to v201710. Please migrate prior to February 14, 2018 to ensure your API access is unaffected.

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



Simpler testing with new AdMob test ads

2018-01-03T15:38:00.827-08:00

Today we're announcing a behavior change when requesting test ads using the Google Mobile Ads SDK. It enables you to test your own ad units while also ensuring that you are in test mode. When using the Google Mobile Ads SDK during development, we recommend that you configure your device to request test ads. Always testing with test ads is important so you avoid having your account flagged for invalid activity. Previously, enabling test ads resulted in the same sample ad like this one being shown in your app: While this worked well as a basic check, it didn't allow for testing what real ads would look like in a production environment. For example, you couldn't test your mediation configurations or the different types of banner and interstitial formats that AdMob offers. The update we're rolling out addresses these problems. New Test Ad BehaviorStarting today, apps built against Google Mobile Ads SDK 11.6.0 or higher on Android or 7.26.0 or higher on iOS can take advantage of the new behavior of test ads, which serves production-looking ads without charging advertisers. With this change, you can safely test the clickthrough behavior of your ads without your account getting flagged for invalid activity. Banner, interstitial, and rewarded test ads now show a "Test Ad" label in the top-middle of the ad to give you a visual indicator that the ad returned is actually a test ad. Sample 300x250 Banner ad For native advanced test ads, the headline asset has the text "Test Ad" prepended. Sample native content ad.Test ads with MediationWhen using mediation, ads shown from third-party ad networks won't display the test ad label. Only Google ads show the test ad label. You are responsible for ensuring that your testing of third-party ad networks is compliant with their stated policies. See each mediation network's respective mediation guidefor more information on how to enable test ads on those networks. See the testing guide (Android | iOS) for more information on how to enable test ads in the Google Mobile Ads SDK. If you have any questions, contact us on the developer forum.  - Eric Leichtenschlag, Mobile Ads Developer Relations[...]



Invalid inserted products no longer result in immediate errors

2017-12-21T08:09:56.592-08:00

In July, there was a change in how the Content API for Shopping responds when inserting products that contain validation errors due to work related to advanced feed management. What changed?Here are the changes in behavior when inserting product information that contains validation errors and would result in an invalid product: Before After Inserting new product Error (inserted) Success (inserted) Updating invalid product Error (inserted) Success (inserted) Updating valid product Error (not inserted) Error (not inserted) That is, before the Content API would return an error whenever the new product information contained validation errors. Now, an error is returned only if the product information cannot be updated because it would invalidate the currently valid product. Note: With this change, the Content API now returns an error response to product insertion only when the returned error response contains the not_inserted error. Since this error is now redundant, we plan to remove it in the future. Why has this behavior changed?With the new advanced feed management features, the products inserted via the Content API may be augmented with information from associated supplemental feeds. This means that a product that would normally be invalid from just the information provided by the Content API may become valid when the information is combined with supplemental feeds to produce the final version of a product. For example, suppose you submit product information via the Content API that lacks needed GTIN information. You then submit the GTIN information for your products separately via a supplemental feed that is connected to the Content API feed in Merchant Center. The products inserted by the Content API are not valid products due to the lack of GTIN information, but once the GTIN information from the supplemental feed is added, the resulting products are valid. What do I need to do?If you depend on error responses from Products.insert to detect validation issues, then you should instead also check your Content API feed for validation issues by using either Productstatuses or Accountstatuses. This will catch products that were inserted with invalid information and have not been made valid after insertion via supplemental feeds. Note: If you are using Productstatuses.list to check all the products in a given account, you'll need to set the includeInvalidInsertedItems parameter to return products with validation errors. If you have any questions or feedback about this change or any other questions about the Content API for Shopping, please let us know on the forum.  - Stevie Strickland, Content API for Shopping Team[...]



Changes to autoplay in Safari 11 for desktop

2017-12-13T12:46:31.577-08:00

MacOS High Sierraincludes a new version of Safari, Safari 11. This new version by default will remove support for auto-playing videos unless they are muted. If your desktop site currently autoplays unmuted video with the IMA SDK, your users will see the first frame of the ad, but the ad will not play. To resolve this, you can either change your implementation to click-to-play, or attempt to autoplay and revert to click-to-play if that fails. We've also added a new error that will fire if the SDK is asked to autoplay an ad but is prevented from doing so by the browser. Continue reading for more info on these solutions.

Click-to-play

The simple, advanced, and playlist IMA SDK samples use this click-to-play functionality. In short, you add a play button to your UI, and render that play button on page load. Your code should then delay calls to adDisplayContainer.initialize(), adsManager.init()and adsManager.start()until the user clicks that play button.

Attempt to autoplay

We've added a new sample to our GitHub repo, Attempt to Autoplay. This sample will autoplay ads if allowed, and if not, will follow the above click-to-play workflow. The sample starts by attempting to autoplay the content video. If autoplay succeeds, it pauses the content to play a pre-roll. This happens in an instant, so the users will not see any content actually play before the ads. If this autoplay attempt fails, the sample renders a play button and waits for the user to click that button to initialize the ad display container and play ads.

New error for failed autoplay

We've added AdError.ErrorCode.AUTOPLAY_DISALLOWED which the SDK will fire if it is asked to autoplay an ad but is prevented from doing so by the browser. You should not see this error if you've properly implemented one of the solutions above. This error is wrapped in a VIDEO_PLAY_ERROR; you can look for it as follows:

onAdError(adErrorEvent) {
if (adErrorEvent.getError().getInnerError().getErrorCode() ==
google.ima.AdError.ErrorCode.AUTOPLAY_DISALLOWED) {
// The browser prevented the SDK from autoplaying an ad.
}
}

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

(image)



Upcoming changes to AdWords OAuth Scope

2017-12-11T07:15:16.907-08:00

We are making the following changes to AdWords OAuth Scopes during the week of January 8, 2018.

Invalid OAuth scopes will no longer be supported
One mistake that developers make when obtaining an OAuth2 access or refresh token for AdWords API is to use the service URL prefix (e.g. https://adwords.google.com/api/adwords/cm/v201708, https://adwords.google.com/api/adwords/reportdownload/v201708) as OAuth2 scope. When we switched to OAuth2, this was a common source of confusion for AdWords API users, so we allowed developers to use these scopes. Since most users are now using the new scope, we are sunsetting these old scopes. Any refresh tokens authorized with the old scopes will stop working with an invalid_scope error. If this error occurs, you will have to re-authorize your users with the proper AdWords scope (https://www.googleapis.com/auth/adwords) to continue making API calls.

Change to permitted OAuth 2.0 scopes when creating Location Extension feeds
When creating a Feed for Location Extensions, make sure you set the OAuthInfo object’s httpRequestUrl field to the AdWords API scope (https://www.googleapis.com/auth/adwords). In the past, we also supported using the Google My Business scope (https://www.googleapis.com/auth/plus.business.manage) for this field; we are sunsetting support for this scope. Similarly, the httpAuthorizationHeader field must have an access token that is authorized for the AdWords API scope.

While we don’t expect most users to be affected by these changes, make sure you review your code and make necessary changes if needed. As always, if you have any questions, let us know on the AdWords API forum.
(image)



Deprecating GMF for Android

2017-12-08T09:41:44.025-08:00

On March 15, 2018, we are stopping development and support for Google Media Framework (GMF) for Android in favor of the new ExoPlayer IMA extension. GMF's technology and approach are based on an older version of ExoPlayer.

The new v2 version of ExoPlayer and the ExoPlayer IMA Extension make basic integration simple enough that a layer between ExoPlayer and the IMA SDK is no longer necessary. The new approach is cleaner, requires less code, and uses the most up-to-date version of ExoPlayer.

Support for GMF for Android will end on March 15, 2018, after which we will no longer respond to issues or make any further releases of GMF for Android. The repository will also be shut down at this time. If you want to access the code, you can clone the repository before the March 15, 2018 shutdown date.

Note: We are NOT deprecating GMF for iOS.

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

(image)



Announcing RTB troubleshooting resources for the DoubleClick Ad Exchange Buyer REST API

2017-12-07T13:37:13.947-08:00

You can now access RTB Breakout metrics programmatically with new RTB troubleshooting resources added to the DoubleClick Ad Exchange Buyer REST API. These include the following:
  • filterSets
  • filterSets.bidMetrics
  • filterSets.bidResponseErrors
  • filterSets.bidResponsesWithoutBids
  • filterSets.filteredBidRequests
  • filterSets.filteredBids
  • filterSets.filteredBids.creatives
  • filterSets.filteredBids.details
  • filterSets.impressionMetrics
  • filterSets.losingBids
  • filterSets.nonBillableWinningBids
RTB troubleshooting resources are placed hierarchically under both bidders and bidders.accounts. For more information about these resources and how they differ when used at the bidder or account level see the RTB troubleshooting guide.

If you have any feedback or questions about the RTB troubleshooting resources, feel free to reach out to us via the DoubleClick Ad Exchange Buyer API support forum.

(image)



Loading multiple native ads in the Google Mobile Ads SDK

2017-12-07T10:36:29.061-08:00

In the Google Mobile Ads SDK Android version 11.2.0 and iOS version 7.21.0, we added multiple native ads, a new feature for AdMob Native Ads Advanced. This feature lets you load up to five unique native ads with a single request. If you're showing native ads in a scrolling feed, this will allow you to get a batch of ads different from one another. It also means fewer network calls, which improves latency. If you're displaying multiple native ads in a feed and loading ads one by one, converting to the new API should be fairly straightforward. First, make a decision about how many ads you wish to fetch in one request. This is a function of how frequently you display ads in your feed. If you request five ads, AdMob will return the top five ads, ordered by eCPM value. If only three ads are available for the ad unit, only three ads will be returned. iOS ImplementationBefore initializing your ad loader, you need to create an instance of GADMultipleAdsAdLoaderOptionsand set the numberOfAdsproperty. Then include this object in the array of options when calling GADAdLoader's initializer: override func viewDidLoad() { super.viewDidLoad() let multipleAdsOptions = GADMultipleAdsAdLoaderOptions() multipleAdsOptions.numberOfAds = 5 adLoader = GADAdLoader(adUnitID: YOUR_AD_UNIT_ID, rootViewController: self, adTypes: [GADAdLoaderAdType.nativeContent, GADAdLoaderAdType.nativeAppInstall], options: [multipleAdsOptions]) adLoader.delegate = self adLoader.load(GADRequest()) }When requesting multiple native ads, you will still get individual callbacks when each ad is loaded. For example, for an app install ad you will have a callback to -adLoader:didReceiveNativeAppInstallAd:, and for a content ad -adLoader:didReceiveNativeContentAd:. This way you don't need to change the way the ads are received and shown. To determine when ads have finished loading, there are two new APIs available: On the GADAdLoaderobject, a new property, loading, has been added. It returns true if a request is in progress, and false otherwise. You can check this property after each ad has loaded to find out if loading ads has completed. On the GADAdLoaderDelegate, the adLoaderDidFinishLoading:method has been added. It's invoked when all ads for a request have been returned.Android ImplementationThe Android implementation is similar to iOS. There's a new method on AdLoader, loadAds() which accepts the number of ads to load. There's also a new isLoading()method that indicates whether a request is currently in progress. For a detailed walkthrough of the implementations, see the AdMob Native Ads Advanced implementation guides (iOS| Android). 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[...]



AdWords scripts now supports v201708 and v201710 in reports

2017-11-29T08:03:40.397-08:00

We have added support for AdWords API v201708 and v201710 reports in AdWords scripts.

The major changes in v201708 are:
  • New fields in various report types.
  • The TABLE_EXTENSION enum value for ClickType was renamed to PRICE_EXTENSION.
  • See the full AdWords API release notes for more details.
The major changes in v201710 are:
  • The Automated field was added to the AD_PERFORMANCE_REPORT.
  • The EnhancedCpvEnabled field was removed from all reports.
  • See the full AdWords API release notes for more details.
In addition to these changes, v201705 is now the default version for reports. You can use one of the newly supported versions instead by specifying the apiVersion in your report request:
var report = AdWordsApp.report(query, {
apiVersion: 'v201710'
});

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



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

2017-11-16T12:17:24.886-08:00

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!
(image)



Announcing v201711 of the DFP API

2017-11-14T12:07:41.775-08:00

Today we're pleased to announce several additions and improvements to the DFP API with the release of v201711. This release includes a new service, CdnConfigurationService, which manages the configuration of DAI(Dynamic Ad Insertion) content ingestion and delivery networks.

Please note that Ad Exchange historical reports will be run in the Pacific timezone in v201711. This will allow you to report on Bid and Deals metrics. If you need to continue running Ad Exchange historical reports in your network timezone, please stay on v201708. Future versions will support both options.

Additionally, the release adds the ability to generate in-site preview URLs for native styles, and you can now determine if an AdUnitsupports fluid sizes by looking at the new isFluidattribute.

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

With each new release comes a deprecation. If you're using v201611 or earlier, it's time to look into upgrading. Also remember that v201702 will be sunset at the end of February 2018.

As always, if you have any questions, feel free to drop us a line on the DFP API forum.

(image)



Changes to AdWords Express campaigns in AdWords API reports

2017-11-30T09:28:17.225-08:00

If you use AdWords API reports to retrieve performance statistics for AdWords Express campaigns, please read on as these changes will affect you. What's changing?In preparation for upcoming improvements, an ongoing migration process is modifying campaigns managed by AdWords Express. Currently, when you enable an AdWords Express promotion, it creates up to two AdWords campaigns: A Search Network campaign with: AdvertisingChannelType = SEARCH (appears as Search) AdvertisingChannelSubType = SEARCH_EXPRESS (appears as Search Express) A Display Network campaign with: AdvertisingChannelType = DISPLAY (appears as Display) AdvertisingChannelSubType = DISPLAY_EXPRESS (appears as Display Express) As part of the migration, the two campaigns above will be paused and replaced by a single AdWords campaign with: AdvertisingChannelType = EXPRESS (appears as Express) AdvertisingChannelSubType = UNKNOWN (appears as an empty string) After the campaigns for a promotion are migrated, performance statistics for the AdWords Express promotion will be available in reports as follows: Performance statistics for dates prior to the migration will be attributed to the original campaigns with SEARCH / SEARCH_EXPRESS and DISPLAY / DISPLAY_EXPRESS. Performance statistics for dates after the migration will be attributed to the new campaign with EXPRESS / UNKNOWN. The new campaign will only appear in the CAMPAIGN_PERFORMANCE_REPORT. For example, assume an AdWords Express promotion manages the following two AdWords campaigns today: Campaign ID Campaign Status Advertising Channel Type Advertising Channel Sub Type 1000 ENABLED SEARCH SEARCH_EXPRESS 2000 ENABLED DISPLAY DISPLAY_EXPRESS After the migration, the account will contain the following campaigns for the AdWords Express promotion: Campaign ID Campaign Status Advertising Channel Type Advertising Channel Sub Type Performance statistics 1000 PAUSED SEARCH SEARCH_EXPRESS Before the migration 2000 PAUSED DISPLAY DISPLAY_EXPRESS Before the migration 3000 ENABLED EXPRESS UNKNOWN After the migration What should you do?Ensure that your application properly handles all three combinations of AdvertisingChannelType and AdvertisingChannelSubType. For example: If your application inspects AdvertisingChannelType or AdvertisingChannelSubType to handle AdWords Express campaigns, please adjust the logic to handle the new combination of EXPRESS / UNKNOWN. If you use predicates on AdvertisingChannelType or AdvertisingChannelSubType to include or exclude AdWords Express campaigns, make sure that your predicate takes the new combination into account. Reminder: The AdWords API only supports retrieving AdWords Express entities. You cannot modify AdWords Express entities in your account using the AdWords API. If you have any questions about this change, please contact us via the forum. - Josh Radcliff, AdWords API Team [...]



DCM/DFA Reporting and Trafficking API v2.7 sunset reminder

2017-11-08T11:56:00.112-08:00

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.
(image)



Search impression share data will be updated more frequently

2017-11-07T11:52:02.885-08:00

Starting mid-November, we’ll be updating AdWords API impression share reporting data more frequently. As a result, you'll be able to get the previous day's data by 12 PM (your local time). Previously, you might have had to wait up to 48 hours for the previous day’s data. This change affects the following reporting fields:
  • SearchBudgetLostImpressionShare
  • SearchExactMatchImpressionShare
  • SearchImpressionShare
  • SearchRankLostImpressionShare
With this change, you may see data fluctuate for report definitions that contain any of the above fields along with one of the following date ranges:
  • YESTERDAY, TODAY, LAST_7_DAYS, THIS_MONTH, ALL_TIME, LAST_14_DAYS, LAST_30_DAYS, THIS_WEEK_SUN_TODAY, THIS_WEEK_MON_TODAY
  • CUSTOM_DATE that includes the current date or the day before the day when you make a report request
This change allows for more real-time monitoring of search impression share. If you prefer to see more stable values, make sure the date range in your request doesn’t include the current date or yesterday if it’s not yet 12 PM in your time zone.

As always, if you have any questions, please post on the forum.
(image)