Google Ads Developer Blog: februari 2018

Announcing v201802 of the AdWords API

woensdag 28 februari 2018

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

dinsdag 20 februari 2018

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.

- Anash P. Oommen, AdWords API Team

Announcing the IMA SDK AMP Extension

dinsdag 13 februari 2018

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.

- Shawn Busolits, IMA SDK Team

Announcing v201802 of the DFP API

dinsdag 13 februari 2018

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

maandag 12 februari 2018

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.

- Shawn Busolits, IMA SDK Team

Upcoming changes to reach report metrics in DCM

woensdag 7 februari 2018

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.

- Jonathon Imperiosi, DCM API Team

Announcing service account creation in the Merchant Center

dinsdag 6 februari 2018

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.

- Stevie Strickland, Content API for Shopping Team

Simpler Native Ads Implementation with the Unified Native Ads API

dinsdag 6 februari 2018

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 — GADNativeAppInstallAd and GADNativeContentAd — are replaced by a single format, GADUnifiedNativeAd. The corresponding views, GADNativeAppInstallAdView and 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

maandag 5 februari 2018

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 issues
We'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 statuses
We 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 of these entries will now always contain the value "required".

What do I need to do?
Currently, no action is needed. We do not expect you to transition to the new issue format yet as it is not on par with the old issue format. For now, we are describing the new issue format so that you get a head start on understanding it and to allow you to transition ahead of time if you do not need the currently missing information.

However, note that we plan to drop support for the old dataQualityIssues field on Aug 1, 2018. Once the new issue format has reached parity with the old issue format, we will update the blog with information about the new changes, and you should transition to the new issue format at that time.

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.