[go: nahoru, domu]

Believe it or not, the DFP API Team eat, breathe, and live the DFP API. We wake up in the morning thinking, "How can I make the DFP API even better?" Seriously, I have had dreams about the API. It’s weird, but I’m not embarrassed to admit that.

In an effort to delight our developers even more, we’re turning the proverbial mic over to you - our customers - to help us help you. Here’s your chance to let us know how we could be better – better support, better features in the client libraries, better content in workshops, better examples, better haircuts... really, anything. Simply fill out our survey with your thoughts here.

Last week, we released beta version 15 of the IMA SDK for iOS. This release includes two new features:

  • Ad buffer events via IMAAdsManager delegates
  • Debugging mode

Ad buffer events

We’re providing more information on ad buffering by introducing new buffering events via the following optional IMAAdsManagerDelegate methods:

  • adsManagerAdPlaybackReady:
  • adsManagerAdDidStartBuffering:
  • adsManager:adDidBufferToMediaTime:

Collectively, these delegate methods provide more transparency into buffer events, giving you more control over the user’s ad experience. For more detailed information on these new methods, take a look at the reference documentation.

Debugging mode

We’ve introduced a new debugging mode setting to allow for more verbose logging to the console. You can now set IMASettings.enableDebugMode to YES to enable debug mode. This should not be used in production, as it will show a watermark on the ad player.

A note about CocoaPods

If you’re using CocoaPods with the IMA SDK, please make sure to use at least version 0.38.

As always, if you have any questions, feel free to contact us via the support forum.

Have you ever found it frustrating that you can never reuse an AdGroup name after removing the AdGroup, since a removed AdGroup cannot be modified? We have awesome news for you!

Now, AdGroupService doesn’t consider REMOVED AdGroup names when verifying that an AdGroup name is unique within a Campaign. If an AdGroup is in a REMOVED state, then the name of that AdGroup can be reused. This is already the case for Campaigns, and we’ve extended this relaxation of constraints to AdGroups.

If you have questions or need clarification, visit us on the AdWords API Forum or our Google+ page.

For those of you who’d prefer to generate an OAuth refresh token using only a browser, there's a new guide on how to use the OAuth 2.0 Playground:

https://developers.google.com/adwords/api/docs/guides/oauth_playground

The guide walks you through the authorization setup required by the AdWords API for a Web application--via a browser session--without the need to execute any command-line scripts.

More OAuth resources
Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.

What's changing?
Starting on or after July 23, 2015, if you are using v201506 of the AdWords API, then FeedMappingService.get and FeedMappingService.query will return FeedMapping objects created for location targeting. These FeedMapping objects will have criterionType 77, and will not have a value for placeholderType. There will be no change in behavior for v201409 or v201502.

You will start seeing these objects if either of the following is true:
  • You created a Feed linked to your Google My Business account.
  • You created a Location targeting feed through the AdWords user interface, under Shared library -> Business data.
Why the change?
Starting with v201506, LocationGroups.feedId is required if your matching function includes a LocationExtensionOperand.

Specifying a feedId in this situation allows AdWords to target the areas surrounding the locations in a location targeting feed. This may be the same feed you are using for location extensions, or a separate feed containing additional locations you want to use strictly for targeting. The key point is that the Feed referenced by LocationGroups.feedId must have a FeedMapping with criterionType 77.

What should you do?
If your application retrieves FeedMapping objects, make sure it will properly handle objects where placeholderType is null and criterionType is set.

If you want to create LocationGroups objects that use a LocationExtensionOperand, you can now use FeedMappingService to find the ID of feeds that have a FeedMapping with criterionType 77.

Learn more
Check out the following resources for more information on Location Groups: Still have questions? Feel free to visit us on the AdWords API Forum or our Google+ page.

As we announced in December 2014, with the release of the DCM/DFA Reporting and Trafficking API, we will be sunsetting the legacy DFA API on September 30th, 2015. To avoid an interruption in service, all DFA API users are required to update their application to use our new API by this date. If you haven’t yet started migrating, we strongly encourage you to do so.

If you’re new to the DCM/DFA Reporting and Trafficking API, you can use our Get Started guide to get up and running quickly. You can also reference our Migration Guide to help in transitioning legacy DFA API applications to the new API. If you have any other questions, feel free to reach out to us on the developer forum.

On or shortly after August 24th, we will remove the BROAD_SESSION match type label from the MatchType column in the Search Query Performance and Paid & Organic Query reports. Instead, rows that formerly returned "broad (session-based)" will begin returning "broad".

To simplify the way we report on match types, this label will be removed from all of our reports, including historical reports. If you'd like to see how your keywords are currently matching to this label, download a copy of your Search terms report before August 24th, 2015.

This is a reporting change and will have no impact on the broad match serving behavior. You can learn more about the MatchType column in the AdWords Help Center.

As always, if you have any questions, comments, or concerns, please contact us via the forum or the Ads Developers Plus Page.

- Michael Cloonan, AdWords API Team

Waiting to see whether or not your ads have been approved can be time-consuming. That's why we're improving the validation logic during ad creation to “fail fast” for one common invalid URL case.

Currently, with new Upgraded URLs, an ad with a final URL domain that doesn't match the display URL domain will be disapproved. Starting on August 12th, 2015, rather than allowing these ads to be submitted for approval, the AdWords API will return an error for any request attempting to create an ad where the final URL domain doesn't match the display URL domain. This will allow you to fix these issues faster and get your ads up and running sooner.

As usual, if you have any questions, comments, or concerns, please contact us via the forum or the Ads Developers Plus Page.


- Michael Cloonan, AdWords API Team

AdWords API v201409 will be sunset on July 28, 2015, after which all v201409 API requests will begin to fail. This version was deprecated on March 5, 2015. With the release of v201506, you now have less than 5 weeks to migrate directly to v201506 and skip v201502 entirely. Please make sure to migrate soon to ensure your API access is unaffected.

We have prepared various resources to help with the migration: As always, if you have any questions about this migration, please contact us via the forum or the Ads Developers Plus Page.