Subscribe: AdWords API Blog
http://adwordsapi.blogspot.com/atom.xml
Added By: Feedage Forager Feedage Grade A rated
Language: English
Tags:
ads  adwords api  adwords  api team  api  app  campaigns  content api  content  mobile  new  questions  release  sdk  team 
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: 2017-10-19T10:20:55.647-07:00

 



KeywordOptimizer: Call For Feature Requests

2017-10-19T10:20:55.678-07:00

The KeywordOptimizer open-source app demonstrates the exciting possibilities of using the Targeting Idea Service in the AdWords API to identify new keyword suggestions. The app shows how, in combination with estimated traffic volume, to generate new keyword targeting ideas for AdWords using an evolutionary approach. We think that there is a lot more that the tool could do to demonstrate these and other features so we’re asking for your ideas to help shape the future development of the app.

If you’re interested in using KeywordOptimizer or are already using it, we would like to hear your ideas on how we can improve the app. Please submit your suggestions via the GitHub issues page.
(image)



Announcing v201710 of the AdWords API

2017-10-10T11:40:36.015-07:00

Today we’re announcing the release of AdWords API v201710. Here are some of the highlights for key AdWords features: Account-level placement exclusions. The new CustomerNegativeCriterionService allows you to exclude specific criteria across all campaigns in an account. The guide contains step-by-step instructions for using this service. Promotion extensions. You can now create promotion extensions for different languages. Check out the updated Extension Settings guide for examples and instructions. Shared sets for manager accounts. The AdWords API now supports the creation of shared negative keyword sets for manager accounts. Previously, creation of SharedSets via the AdWords API was only supported for client accounts. Ad rotation settings. You can now manage the new ad rotation settings announced in August via the AdWords API. The updated code examples for adding AdGroups demonstrate how to set the new rotation options. Customer match by phone number. You can now include phone numbers when uploading Members of a CrmBasedUserList. The updated remarketing guide contains requirements and details. Batch job support for shared sets. BatchJobService now supports CampaignSharedSetOperations, SharedCriterionOperations, and SharedSetOperations for managing shared sets. Check out the updated Batch Processing guide for details. If you’re using v201702 of the AdWords API, please note that it will be sunset on February 14, 2018. We encourage you to skip v201705 and v201708 and migrate straight to v201710. Please note that v201705 is deprecated. As mentioned in the recent blog post on the sunset and release schedule, both v201705 and v201708 will be sunset on March 28, 2018. As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201710 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 post on the forum or the Ads Developers Plus Page. - Josh Radcliff on behalf of the AdWords API Team[...]



AdWords API release and sunset schedule in 2018

2017-10-09T12:58:33.042-07:00

In 2016 and 2017 we supported at least three versions of the AdWords API at any given time and four versions for a brief period after each new release. This led to older versions of the API supporting outdated functionality and lacking new features.

To improve your AdWords API experience, we will be updating our release schedule. Starting in March 2018 we will only support two releases concurrently at all times, and three releases for a brief period of four weeks, allowing developers to skip a version. To get us back on schedule, we will concurrently sunset v201705 and v201708 in March 2018. This brings the average lifespan of every API version released in 2018 down to nine months.

Additionally, we will be moving back to a schedule that releases three versions per year. The 2018 releases are scheduled for February, June and September.
(image)
As usual, make sure to check our deprecation schedule for more details on sunsets. If you have any questions about the new schedule, please reach out to us on the AdWords API forum or the Ads Developers Plus Page.
(image)



Sunset of DFP API v201611

2017-10-09T10:46:23.716-07:00

On Thursday, November 30th, 2017, in accordance with the deprecation schedule, v201611 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 like support for creating ImageOverlayCreatives, new Ad Exchange reporting dimensions and columns, and the change history table. 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[...]



Google Mobile Ads SDK release 7.24.1 supports iOS 11

2017-09-28T15:44:57.944-07:00

We're happy to announce that with this week's release of version 7.24.1, the Google Mobile Ads SDK is officially iOS 11 ready. You can get the latest version via CocoaPods or via manual download.

Check the release notes for a full list of updates. One prominent issue that this SDK release resolves is the banner ad views rendering out of bounds in some situations on iOS 11.

Stay tuned for another SDK update ahead of the iPhone X release. Speaking of which...

iPhone X

At this year's launch event, Apple announced a new iPhone, the iPhone X. With this new device comes a new form factor and some additional design considerations for developers, as the rounded corners, notch, and soft home button on the extended screen can obscure content.

With this in mind, we want to highlight some best practices for Google Mobile Ads publishers to ensure that ad placement conforms to Apple's new design guidelines for the iPhone X and iOS 11.

Banner and native ads should be placed inside the safe area, a concept new to iOS 11. This ensures that ad content is not obscured. Additionally, the safe area respects UI elements such as navigation bars, the status bar, and tab bars on all iOS 11 devices.

When using autolayout, ensure any constraints are relative to safe area layout guides. If you're using manual layout, check that banners and native ads fit within the safeAreaInsets.

For interstitials and rewarded video ads, we're working to ensure all controls and important content are also placed within the safe area. Keep an eye out for another Google Mobile Ads SDK release ahead of the iPhone X release date.

If you have any questions about iOS 11 support in the Google Mobile Ads SDK, please drop us a line at the developer forum.

(image)



ExoPlayer Releases IMA Extension

2017-09-27T09:49:59.381-07:00

Users of ExoPlayer, an extensible, open-source media player for Android, can now easily integrate with the IMA SDK using the new ExoPlayer IMA extension. The IMA extension, released alongside ExoPlayer 2.5, wraps the IMA SDK for Android and provides seamless ad playback.

The extension ensures that ads are integrated into ExoPlayer's video timeline, and UI components are ad-aware. It also reduces buffering by eliminating the need to swap out and rebuffer the video player's source when transitioning between ads and content.

You can find more details on the extension in ExoPlayer's blog post on Medium, and find the extension on GitHub. If you have any questions or issues, please file them on ExoPlayer's issue tracker.

(image)



Changes to data feed management in the Content API for Shopping

2017-09-25T13:20:29.013-07:00

Starting today, the Datafeeds service will allow you to use the Content API for Shopping to set up data feeds that target multiple countries and/or languages, which a recent update added to the Merchant Center. The update to the Datafeeds service will also allow you more control over the destinations for products in data feeds managed via the Content API. What's changing?To handle feeds that target multiple countries and/or languages, a new targets field is being added. This field contains a list of targets, and each target contains the following fields: country - the target country language - the content language for this target includedDestinations - a list of destinations to include for this target excludedDestinations - a list of destinations to exclude for this target Note: The above links to the reference documentation for the new fields will go live on the same day that the feature is introduced. The following now-redundant fields are being deprecated: targetCountry contentLanguage intendedDestinations Currently, code that uses these deprecated fields will continue to work as before for managing feeds with a single target. Any changes made via these deprecated fields will also appear as a single target in the new targets field, and vice versa if the targets field contains a single target. These deprecated fields will not be returned when retrieving feeds with multiple targets. Since these deprecated fields may be removed in the future, we recommend migrating your code to use the new targets field now. To support feeds that have multiple targets, the Datafeedstatuses.get method now takes two additional parameters: country - the target country language - the content language These new parameters must be supplied for feeds that have multiple targets, since the status of a feed may differ depending on the target. These parameters can be omitted when retrieving the status of a feed with a single target. Similarly, when retrieving all feed statuses using the Datafeedstatuses.list method, you will receive multiple entries for a feed with multiple targets, where each entry corresponds to a particular target. What do I need to do?To manage feeds that use any of the following features, you must update your code to use the new targets field: Feeds that target multiple countries and/or languages Feeds that exclude destinations that are included by default In addition, you must supply the new country and language parameters when retrieving the status of a feed that has multiple targets. Otherwise, your existing code will continue to work as before. However, since we may remove the old fields in the future, we recommend you update your code for managing data feeds to use the new targets field. Note: To use the new targets field and the new country and language parameters if you are using one of the Content API client libraries, update to a version published on or after Sep 21, 2017. If you have any questions or feedback about the changes to data feed management or other questions about the Content API for Shopping, please let us know on the forum.  - Stevie Strickland, Content API for Shopping Team[...]



Upgrade to AdWords Universal App campaigns from mobile app install campaigns before October 16th

2017-09-19T11:43:29.028-07:00

What’s changing?On August 14th, we announced that AdWords users should start migrating their mobile app install campaigns to Universal App campaigns (UACs). Starting on October 16, 2017, all requests to create new mobile app install campaigns will fail, and all requests to add ads and ad groups to these existing campaigns will fail with an ADD_OP_NOT_PERMITTED error. Edits to these existing campaigns will still be allowed. Starting on November 14, 2017, these mobile app install campaigns will be deleted and will stop serving. Reporting stats for these campaigns will still be available. Mobile app engagement campaigns will not be affected. Why is this happening?If you want to learn more about these changes, check out our Propel your mobile app growth with Universal App campaigns announcement. What should I do?To avoid errors when managing your mobile app campaigns, here’s what you need to do by October 16th: Modify your code to enable the creation of Universal App campaigns. Check out our guide on creating Universal App campaigns, which includes code samples in all client library languages. Disable the creation of mobile app install campaigns and adding ad groups or ads in these campaigns. Edits will still be allowed. To keep your ads serving beyond November 14th: Search for all campaigns in your accounts that have campaign status ENABLED or PAUSED with advertisingChannelSubType DISPLAY_MOBILE_APP or SEARCH_MOBILE_APP. After November 14th, these campaigns will have a status of REMOVED because they will be deleted automatically by the AdWords system. Create a new Universal App campaign to replace each campaign you find. Once that Universal App campaign is online and serving, remove the mobile app install campaign. Where can I learn more?Here are a few resources to get you started: Mobile app campaigns guide Universal App campaigns Client Libraries: Code examples are available in Java, PHP, Python, Ruby, Perl, C#, and VB.NET. If you have questions while you’re upgrading, please reach out to us on the AdWords API forum. Nadine Sundquist, AdWords API Team [...]



Changes to sub-account deletion in the Content API for Shopping

2017-08-29T09:39:30.573-07:00


What's changing?

Currently, the Accounts.delete method deletes sub-accounts whether or not they contain products. On Sep 28, 2017, we will change the default behavior of Accounts.delete to only delete empty sub-accounts. We are introducing this change to help avoid accidental deletion of sub-accounts that are still serving products.

To override this behavior, we have introduced a force parameter, which currently defaults to true. On Sep 28, 2017, the default value will change to false. After this change, you must set this parameter to true to delete non-empty sub-accounts. Attempts to delete non-empty sub-accounts with force = false will result in a 403 Forbidden error. The error will also explain how to delete the non-empty account.

What do I need to do?

Right now, we suggest you familiarize yourself with the new force parameter. If you regularly delete non-empty accounts, you should adjust your code to set force to true to avoid errors when the default behavior changes. If you want to inspect the error that you will receive after the default behavior changes, you can manually set the force parameter to false and attempt to delete a non-empty account. (Of course, we suggest you create a new sub-account and add some products to it to try out this new behavior, instead of calling it on an existing live account.)

Once this change is live on Sep 28, 2017:
  • To delete an empty sub-account, you do not need to make any changes.
  • To delete a sub-account that contains products, you must set the new force flag to true when calling Accounts.delete.

Note: If you are using one of the Content API client libraries, you will need to update to a version published after Aug 28, 2017 to take advantage of this new parameter.

If you have any questions or feedback about the changes to account deletion or other questions about the Content API for Shopping, please let us know on the forum.

(image)



AdWords API v201609 sunset reminder

2017-08-24T02:05:05.113-07:00

AdWords API v201609 will be sunset on October 2, 2017. After this date, all v201609 API requests will begin to fail. This AdWords API version was deprecated on May 31st, 2017. If you are still using v201609, we recommend that you skip v201702 and v201705 and migrate directly to v201708. Please migrate prior to October 2, 2017 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)



Share your feedback about the AdWords API

2017-08-16T09:07:58.725-07:00

Since the early days of the AdWords API, we've continually evolved the platform to help you more efficiently and creatively manage large or complex AdWords accounts and campaigns.

To learn more about what's working well and what could be improved, we're running our first AdWords API feedback survey. Your answers will be completely anonymous, so we hope you'll take the opportunity to let us know about any changes you'd like to see to help make managing campaigns even easier.

SHARE YOUR FEEDBACK

The survey will close on August 30, 2017, and should take about 15 minutes to complete. Thanks in advance for sharing your thoughts to help us improve the AdWords API Developer experience for everyone.
(image)



Announcing v201708 of the DFP API

2017-08-15T11:48:55.262-07:00

Today we’re pleased to announce several additions and improvements to the DFP API with the release of v201708. CreativeService: The API now supports the skippableAdType attribute on VideoCreatives and the mezzanineFile asset on VideoRedirectCreatives. CreativeWrapperService: The HTML header and footer fields have been renamed to htmlHeader and htmlFooter, and they are now strings instead of CreativeWrapperHtmlSnippets. ProposalService: Proposals are now automatically synced with marketplace. Therefore, the proposal action SyncProposalsWithMarketplace has been removed (sending this action with performProposalAction is now a no-op in previous API versions). PublisherQueryLanguageService: In v201702 the Change_History table was introduced. Now, new entities for Sales Management have been added to the EntityType column. The new entities are BASE_RATE, PREMIUM_RATE, PRODUCT, PRODUCT_PACKAGE, PRODUCT_PACKAGE_ITEM, PRODUCT_TEMPLATE, PROPOSAL, PROPOSAL_LINK, PROPOSAL_LINE_ITEM, PACKAGE, RATE_CARD, and WORKFLOW. ReportService: DateRangeType now supports a new LAST_3_MONTHS option. Also, several deprecated reporting metrics have been removed. They can be replaced with their corresponding partner management metrics, so you will need to update any code using those fields. For more information, check out the support entry for partner management reporting metrics. For a full list of API changes in v201708, see the release notes. With each new release comes a new deprecation. If you're using v201611 or earlier, it's time to look into upgrading. Also, remember that v201608 will be sunset at the end of August 2017. As always, if you have any questions, feel free to reach out to us on the DFP API forums or the Ads Developer Google+ page.  - Donovan McMurray, DFP API Team[...]



Announcing v201708 of the AdWords API

2017-08-09T11:39:07.993-07:00

Today we’re announcing the release of AdWords API v201708. Here are some of the highlights for key AdWords features: If you’re using v201609 of the AdWords API, please note that it will be sunset on October 2, 2017. We encourage you to skip v201702 and v201705 and migrate straight to v201708. Please note that v201702 is deprecated and will be sunset on February 14, 2018.

As with every new version of the AdWords API, please carefully review all changes in the release notes and the v201708 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 post on the forum or the Ads Developers Plus Page.
(image)



Accountstatuses now includes account-level issues in the Content API for Shopping

2017-08-09T09:21:39.446-07:00

Starting today, calls to the Accountstatuses service return not only product-level issues, but also account-level issues. This means all account-level issues present in the Diagnostics tab of the Merchant Center can now be retrieved using the Content API. Account-level issues are located in a new accountLevelIssues field, so existing code should be unaffected by this change. For more details, see the accountStatus resource representation in the reference documentation.

Note: Some account-level issues, like unclaimed websites, were already returned as product-level issues. Currently, these issues still show up at the product level as well as at the account level, but this may change in the future.

If you have any questions or feedback about the changes to issue reporting or other questions about the Content API for Shopping, please let us know on the forum.
(image)



Upcoming changes to standard placement tags in DCM

2017-07-31T09:56:07.455-07:00

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

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

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

What can API users do to prepare?

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

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

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



AdWords Scripts now integrated with Google Slides API

2017-07-28T12:16:24.512-07:00

Today we’re excited to announce that the Google Slides API has been added as an Advanced API to AdWords scripts. Our Advanced APIs allow you to work with other Google services within the scripts you write. The Google Slides API allows you to create and write presentations programmatically, and with AdWords scripts it can be used to publish your campaign data in a ready-to-be-shown format.

To learn more about using the Google Slides API in your scripts, please refer to our guide to working with Advanced APIs and code snippets. We encourage you to try Slides and our other Advanced APIs and let us know of other APIs you would like to see added.

As always, please leave feedback on our forum so that we may handle bugs and improve usability.

(image)



Update of adGroupType for ad groups containing only Dynamic Search Ad features

2017-07-28T10:13:04.406-07:00

Following the validation rule changes in May 2017, we’re updating ad groups that contain only Dynamic Search Ad features.

Specifically, we’re updating the adGroupType to SEARCH_DYNAMIC_ADS for any ad group that has all of the following properties: After the above-mentioned ad groups have the SEARCH_DYNAMIC_ADS type, you’ll be able to add only DynamicSearchAd and ExpandedDynamicSearchAd objects, and not Keyword objects as BiddableAdGroupCriterion.

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



Upcoming changes to DBM report access

2017-07-27T14:41:42.055-07:00

Back in March, we launched the new Report Builder in DoubleClick Bid Manager (DBM). Over the coming months, we'll be migrating all reports from the legacy reporting platform (v1) to Report Builder (v2). This migration will complete on September 25, 2017, at which point access to v1 reporting will be removed. We'll also be disabling access to the Google Cloud Storage buckets used by v1 reporting on that date.

Once the migration to v2 reporting is complete, the only way to access reports programmatically will be via the DBM API. Users who currently access reports through Google Cloud Storage must migrate to using the API before September 25, 2017 to avoid an interruption in service. To learn more and quickly get started with the API, visit our getting started guide.

If you have questions regarding these changes, please reach out to your DoubleClick account team.
(image)



Changes in retrieving product data from Merchant Center via Content API

2017-07-12T09:44:13.654-07:00

Starting today, we are deprecating the use of the Products.get and Products.list methods for retrieving all product attributes. These methods still work as expected today, but they may change in the future to return only partial information about products. If you want to retrieve all product attributes, you should use the Productstatuses.get and Productstatuses.list methods instead, which now optionally provide product attributes in addition to product issues and approval statuses.

Note that the Productstatuses.get and Productstatuses.list methods still do not return product attributes by default. To request product attributes be included, we have added an optional includeAttributes argument to these methods. When set, the resources returned by Productstatuses.get and Productstatuses.list will contain an additional product field that contains the attribute information.

If you have any questions or feedback about the changes to retrieving products or other questions about the Content API for Shopping, please let us know on the forum.
(image)



Simpler mediation with AdMob and DFP

2017-07-10T11:49:41.334-07:00

Over the past few months, a couple new projects designed to streamline AdMob and DFP mediation have launched: mediation groups, open source adapters, and network-specific guides. Open Source Mediation Adapters on GitHub In partnership with some of our mediation partners, we've open-sourced many of the most popular adapters used with DFP and AdMob mediation. You can see for yourself at our GitHub repos for iOS and Android: https://github.com/googleads/googleads-mobile-android-mediation https://github.com/googleads/googleads-mobile-ios-mediation In addition to adapter source, there's also a project containing example adapter and custom event implementations, plus a test app. Import Mediation Adapters with CocoaPods and Gradle In addition to open-sourcing the adapters, we've also made importing compiled adapters into your projects simpler by uploading them to Bintray and making them available via jCenter and CocoaPods. Rather than downloading and manually including libraries, publishers can get the correct adapter simply by updating their Podfile with a line like this: pod 'GoogleMobileAdsMediationMoPub' ...or their build.gradle file with a line like this: compile 'com.google.ads.mediation:mopub:11.10.1.0' With many ad networks choosing to distribute their SDKs in the same manner, it's frequently possible to bring a new mediation network into an app with nothing more that a Podfile or build.gradle tweak. For instructions on which gradle artifacts and CocoaPods to use, check the AdMob Mediation Overview (iOS, Android) and look for networks in the "Open source and versioned" section. Network-specific guides Each mediated network is a little bit different. They have their own front-end, their own reporting systems, and their own vocabulary including things like "placement," "location," or "zone." Once you start trying to add a second or third network to your mediation waterfall, things can get confusing in a hurry. To help publishers navigate through these details, we've created network-specific guides for the mediation partners who have joined our open source repositories. Each one includes step-by-step instructions (with screenshots) that guide a publisher all the way from configuring their account in the mediated network's web site to setting up their mediation stack and importing the right adapter. For more details, there's no better place to go than the guides themselves. You can find them in the AdMob Mediation Overview (iOS, Android). Questions? If you've got questions about our open source adapters or the best ways to get up and running with mediation, stop by our support forum.  - Andrew Brogdon, Mobile Ads Developer Relations [...]



Register now for the AdWords scripts workshops!

2017-07-28T09:19:45.160-07:00

We’re pleased to announce a new set of workshops for AdWords scripts in 2017. The workshops will be held at the following locations:
  • Hamburg, Germany: 10 August 2017
  • London, UK: 15 August 2017
  • Singapore: 15 August 2017
  • Sydney, Australia: 18 August 2017
  • São Paulo, Brazil: 20 September 2017
  • Buenos Aires, Argentina: 22 September 2017
This round of workshops will cater to both novice and experienced scripters. We'll have code labs where you’ll build your own scripts from scratch with help from the scripts team. Bring your laptop and some scripting ideas, and we’ll turn them into reality!

Whether you’re an advertiser who wants to learn how to use scripts to automate your account management tasks, a developer who wants to polish your skills, or you'd just like to bounce around some ideas, you can find it all in these workshops.

Availability is limited, so be sure to visit our website early to check out the full agenda and sign up.

If you have any questions about the workshops, you can post them on our forum.
(image)



Sunset of DFP API v201608

2017-07-07T04:02:50.438-07:00

On Thursday, August 31st, 2017, in accordance with the deprecation schedule, v201608 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 like support for creating ImageOverlayCreatives, Partner companies, new team actions, and the change history table. To do so, 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.Added actions to support programmatically activating and deactivating teams.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.[...]



Introducing the AdWords API Success Stories hub

2017-06-29T07:18:08.487-07:00

Over the years, many developers have let us know they'd like to see more real-world AdWords API examples to help them drive their own success. To deliver on this, we've worked closely with our partners to share their innovative strategies for using the AdWords API to boost their business.

You can now find these case studies on the developer website. We plan to post more in the future, so check back for fresh insights from digital marketers on making the most of the AdWords API.

If you have any questions or feedback regarding these partner stories, please let us know on the forum.
(image)



New Custom Playback APIs for IMA HTML5 and Mobile Safari

2017-06-27T08:54:18.111-07:00

Starting with iOS 10, Safari on iPhone and iPod supports inline video playback. This opens up some new rendering options for your video player and the IMA SDK, but also introduces some caveats. So what changed?Previously, Safari on iPhone played all video in a fullscreen player. With iOS 10, Safari now supports the playsinline parameter on a video element to play that content inline. Fullscreen playback on iPhone Mobile Safari. The default with iOS 10+ and the only option for iOS <= 10 Inline playback on iPhone Mobile Safari. A new option in iOS 10+ How will the IMA SDK work with inline video playback on mobile Safari?On iPhone Safari, the IMA SDK re-uses your content player to play ads. We call this "custom playback." So if you add the playsinline parameter to your content video tag, IMA ads will also play inline - it's as easy as that. Inline video playback also opens the door for the IMA SDK to play skippable ads on iPhone Mobile Safari. Previously these ads were dropped by the SDK because we could not render a skip button on top of the fullscreen player. If your player is inline, however, we can render that skip button, but there's a catch. So what's the catch?IMA SDK skippable ads are not supported with the "custom playback" method. To use skippable ads, you'll need to use our new API, ImaSdkSettings.setDisableCustomPlaybackForIOS10Plus(). This will cause the IMA SDK to render the ad in its own inline player on top of your content player. That player does support skippable ads. Disabling "custom playback", however, will break your fullscreen implementation for iPhone web. Why do I need custom playback on iOS?The need for "custom playback" on iOS boils down to one thing - fullscreen support. Mobile Safari only supports fullscreen via videoPlayer.webkitEnterFullscreen(). In this mode, the SDK cannot render anything on top of your content player. Therefore, to support fullscreen ad playback we must use "custom playback". What if I want skippable ads and fullscreen support?Unfortunately, this is not possible on mobile Safari today - you must choose between support for skippable ads and support for fullscreen. What's the deal with iOS <10?Prior versions of iOS (<10) do not have support for playsinline, so pages in those environments will always use "custom playback" mode, with support for fullscreen but no support for skippable ads. I'm still confused.That's OK! This is a complicated change with a lot of moving parts. Below is a support matrix outlining what is and is not supported based on your content player's playsinline mode and the "custom playback" mode you've set for the IMA SDK. Remember, this matrix only applies to iOS 10 and above - anything running version iOS 9 or below falls into the top left quadrant of the matrix, as this is the only option.  - Shawn Busolits, IMA SDK Team [...]



New VPAID Sample for the IMA HTML5 SDK

2017-06-15T09:53:24.296-07:00

To help developers integrate with the IMA SDK, we're always looking for ways to provide both basic and advanced examples of features supported by the SDK. Toward this end, we're pleased to release a sample JavaScript VPAID creative and sample ad tag to aid in troubleshooting JavaScript VPAID 2.0 creatives. You can check out the new sample on GitHub, and find the new ad tag in our list of IMA sample tags as 'Sample VPAID 2.0 Linear'.

The VPAID sample plays a linear video ad and demonstrates the use of the video player proxy element required to run a VPAID ad in a secure iframe.

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

(image)