Google Ads Developer Blog: July 2014

Support for v201406 reports in AdWords scripts

Thursday, July 31, 2014

We are announcing support for AdWords API v201406 reports in AdWords scripts. This version introduces several changes to the reporting columns.

Columns and fields cleanup

We've removed duplicates and changed column and display names in some reports:

Column Name	Change	Comments
ValuePerConvManyPerClick	Removed	Use ValuePerConversionManyPerClick instead.
ValuePerConv	Removed	Use ValuePerConversion instead.
TotalConvValue	Removed	Use ConversionValue instead.
PrimaryUserLogin	Removed
AccountId	Removed	Use ExternalCustomerId as unique account ID instead.
TargetingSetting	Removed	This column is now called IsRestrict and returns a proper boolean value.
NonDeletedAdGroupCount	Removed	New column name is NonRemovedAdGroupCount.
NonDeletedAdGroupCriteriaCount	Removed	New column name is NonRemovedAdGroupCriteriaCount.
NonDeletedCampaignCount	Removed	New column name is NonRemovedCampaignCount.

We also made changes to some enumerations for relevance and consistency:

Status value for an enabled object is now ENABLED across all reports. Before, it was ACTIVE for some objects.
Removed objects now have a status of REMOVED instead of DELETED.
The PRODUCT_LISTING_AD_CLICKS display name has changed from Offer to Product listing ad.

If your scripts use these fields in reports, make sure you fix the AWQL when migrating to the new version of the reporting API. Keep in mind that if you don’t use API versioning in your reports, then your code will now be using reports API version v201406 by default.

New report fields

Several new report fields were introduced:

Report Name	New columns
Campaign Performance Report	ServingStatus
Click Performance Report	UserListId
Product Partition Report	date fields, CampaignName, AdGroupName
Multiple reports	ExternalCustomerId, IsRestrict, BiddingStrategyType
Campaign, AdGroup, Ad, and Keyword Performance Reports	Labels

You can refer to https://developers.google.com/adwords/api/docs/appendix/reports for the list of supported reports and columns.

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

Anash P. Oommen, AdWords Scripts Team

AdWords API Workshops: Feedback in Action!

Tuesday, July 29, 2014

If you’ve attended one of our AdWords API Workshops, you will know how important we think your feedback is to the growth of the API. We also have surveys you can fill in to let us know what you think. Many of the changes brought about in AdWords API v201406 were influenced by your requests, including:

Labels have been introduced to the API, for filtering and in reporting, which has been our most asked for feature for over a year now.
Destination URL customization has been improved, which along with greater Analytics functionality, improves your ability to track and manage actions from your Ads.
The Status fields of all the entities have been made more consistent. This has meant changing some enumeration fields, for instance, but the result should cause less confusion going forward.
Shared Sets are back - currently for whitelisted customers only.
Managed Customer Service can now move whole subMCC trees between MCCs.

We want to thank you again for your feedback, and ask that you continue to let us know what you need to use the API more effectively. Your input really does matter, and makes things happen.

Finally, if you want to see the content of our last AdWords API Workshops round, we’ve recorded a series of videos of the presentations we gave. We hope you find them useful and interesting.

- Mark R. Bowyer, AdWords API Team

Reminder: AdWords Migration to Search Network with Display Select

Tuesday, July 29, 2014

In April, we announced that Search Network with Display Select support would begin in AdWords API v201402. Now that all previous API versions have been sunset, we’re on schedule to begin migrating all Search and Display Network campaigns to Search Network with Display Select beginning September 16, 2014.

This blog post will walk through everything you need to know about setting up your campaigns, including what this migration means for your campaign-creation code. You can proactively migrate your campaigns by setting their displaySelect property to true.

Remember, this will not affect Search-only or Display-only campaigns. Only campaigns that target both networks simultaneously will be migrated.

If you have any questions about this change, please contact us on the forum or via our Google+ page.

- Michael Cloonan, AdWords API Team.

Real-time Bidding with OpenRTB and DoubleClick Ad Exchange

Monday, July 28, 2014

Working with multiple exchanges is a key pain point for those developing real-time bidders. To-date, individual exchanges have used their own distinct protocols requiring the time-consuming development of a separate model for each exchange. In response, the OpenRTB consortium introduced standards for communication in real-time bidding that greatly simplifies the process of adding support for new exchanges. That’s why we are pleased to announce two new open source libraries that implement the OpenRTB specification and are now available on GitHub—google/openrtb and google/openrtb-doubleclick.

The openrtb library provides support for the core OpenRTB model and was designed with extensibility in mind to support the development of libraries for other exchanges. The openrtb-doubleclick library is an extension of openrtb for DoubleClick Ad Exchange that provides interoperability between the OpenRTB model and DoubleClick's Real-Time Bidding protocol. The library also includes DoubleClick-specific utilities. In summary, these libraries provide the following:

The model - The RTB model, as seen in the OpenRTB specification.
The mapper - Translates DoubleClick’s native model to/from OpenRTB.
The serializer - Translates JSON to/from the OpenRTB model.
DoubleClick Ad Exchange utilities - Utilities to handle bid validation, DoubleClick crypto and metadata.

For more information about the OpenRTB specification, check out the documentation on their Github page.

- Mark Saniscalchi, Ad Exchange Team

Ad Exchange Real-Time Bidding Optimization Series: Video Best Practices

Wednesday, July 23, 2014

Two years ago, we introduced the Ad Exchange Real-Time Bidding Optimization Series on the developer's blog with our first post on post-filtered bids. Since then we’ve added tons of new formats and options for buying. Today, we’ll direct you to our Developers site for more information about how the video review process works, how throttling and filtering occur and highlight best practices to ensure smooth delivery.

The first step is to know your video-specific terms. Check out the in-stream video glossary to find definitions for terms with which you’re not familiar. Once you've created your in-stream video ad, you will need to monitor your video ads. The Video Best Practices Guide provides a list of ways to confirm your video ads are serving:

Have questions or feedback? Reach out to your Ad Exchange account team.

Posted by the Ad Exchange Team

AdWords API - Upgrading to account-level location extensions

Wednesday, July 23, 2014

Update: All new location extensions created on or after October 16th, 2014 can only be created as new account-level feed-based location extensions.

On July 14th, 2014, AdWords announced upgraded location extensions, a more efficient way to manage and use business locations in ads by linking Google My Business and AdWords accounts.

The upgrade is taking place in phases for AdWords accounts throughout the coming months. The next phase of account upgrades is scheduled to start on August 25, 2014. All AdWords accounts will to be upgraded by November, 2014.

The upgrade has direct impact to AdWords API client applications. If you are using the CampaignAdExtensionService to manage LocationExtensions or LocationSyncExtensions, then you’re using the legacy location extensions that are being phased out. After an account is upgraded, you’ll need to use the new account-level feed-based location extensions.

How will existing location extensions be upgraded by Google?

Please review the AdWords Help Center article for all upgrade scenarios. For AdWords API developers, most accounts will fall into one of these scenarios:

Accounts that don’t have any existing legacy location extensions.
Accounts that have existing legacy location extensions not sourced from a Google My Business account (i.e., using LocationExtensions only).
Accounts that have existing legacy location extensions sourced from a Google My Business account (i.e., using LocationSyncExtensions).

If you programmatically create AdWords accounts that are not associated with any user, please get in touch with your Google representative for migration support.

Accounts that don’t have any existing legacy location extensions

For accounts that aren’t using any LocationExtensions or LocationSyncExtensions but will begin using location extensions, you should use feed-based location extensions instead.

Accounts that have existing legacy location extensions not sourced from a Google My Business account

If you’re using LocationExtension entities to manage individual locations, the automatic upgrade process will perform the following:

A Google My Business account will be created and linked with the AdWords account. All administrators of that AdWords account will have access to locations in the linked Google My Business account.
A CustomerFeed with the Location placeholder type will be created.
Existing locations in LocationExtension entities will be copied into the Google My Business account. Existing LocationExtension entities will then be removed.
Ads in all campaigns will be served with locations from the linked Google My Business account (you can create a CampaignFeed to further filter or disable location extensions served for a given campaign).

Accounts that have existing legacy location extensions sourced from a Google My Business account

If you’re using LocationSyncExtension to link campaigns to a Google My Business account, then the automatic upgrade process will perform the following:

The campaign-level links to the Google My Business account will be switched to a single link at the account level.
- A CustomerFeed with the Location placeholder type will be created for the account.
Any existing LocationExtension entities will be removed, so make sure they’re copied to the linked Google My Business account before the upgrade.
Ads in all campaigns will be served with locations from the linked Google My Business account (you can create a CampaignFeed to further filter or disable location extensions served for a given campaign).

If an AdWords account is already linked to Google My Business at the account level using CustomerFeed, any existing legacy location extensions will be removed during the upgrade process.

How do I know if an account has been upgraded?

An account is considered upgraded if either condition is true:

It has a CustomerFeed for the Location placeholder type. You can query CustomerFeedService to check:
```
select FeedId, PlaceholderTypes where PlaceholderTypes = 7
```
It has neither a CustomerFeed nor legacy LocationExtension or LocationSyncExtension entities.

In an upgraded account, any attempts to create legacy location extensions using the CampaignAdExtensionsService will return the AdExtensionError.INVALID_ADEXTENSION_TYPE error.

How do I continue to manage locations?

There’s currently no API support for Google My Business. Locations are managed via the Google My Business Locations interface, which supports bulk management.

Can I start using upgraded location extensions before an account is upgraded?

Since the upgrade process is complicated for many accounts, the simplest approach is to allow accounts using legacy location extensions to be automatically upgraded (account owners will be notified 30 days before the upgrade).

What about reporting?

For upgraded accounts, you’ll need to use the Placeholder Feed Item Report rather than the Ad Extensions Performance Report to download statistics for each location.

We are here to help

If you have any questions about this upcoming change or anything else related to the AdWords API, please contact us on the AdWords API forum or via the Google Ads Developers Google+ page.

- Ray Tsang, AdWords API Team

Google Media Framework: Making online video simple

Wednesday, July 23, 2014

We’re excited to announce an open source video player framework to make online video and video monetization with the IMA SDK easier than ever. The Google Media Framework (GMF) is available for iOS and Android, and we have a Video.js plugin for web based video players.

Google Media Framework for iOS

Google Media Framework for Android

GMF Features

Ready to use Video player for your apps and websites
Demo apps include production ready integrations with the IMA ads SDK
GMF is free and open source, so can be customized to meet your specific needs (Send us a pull request!)
Easily customize the UI color and add or remove buttons
Support for iOS 7+ and Android 4.1+

We hope these frameworks enable you to simply make great mobile video apps and awesome web video experiences. You can send us thoughts or questions via the GMF Google group.

GitHub Links

Stay tuned as well for a deeper dive into Video.js with IMA soon!

-- The Google Media Framework Team

Preserving and renewing your AdWords scripts

Monday, July 21, 2014

To help streamline management of your AdWords scripts, we’ve made it easier to preserve scripts created in your AdWords account even after the original author becomes inactive.

In the past, a script in an AdWords account would become unavailable if the script’s original author was no longer associated with the AdWords account. Other users on the AdWords account would need to recreate the script on their own or else risk losing it entirely.

With the new changes we’re launching, scripts from an inactive user will continue to be available in the AdWords account where they were created. To keep these scripts running, the remaining users in the AdWords account will need to log into AdWords and reauthorize the script.

We’ll e-mail the administrators on the AdWords account if the author of a scheduled script goes inactive and here’s what you’ll need to do to get the script running again:

Log in to your AdWords account, and navigate to the Scripts section under Bulk Operations (or the Scripts section of your MCC account).
In the “Script” column, find the relevant script.
Click the "Edit" link.
Click the "Authorize now" button in the yellow bar at the top of the script editor.
Click the “Accept” button.

We are applying this change with an effective date of March 15, 2014. If an author went inactive before that date, his or her scripts will continue to be unavailable. Scripts created in your AdWords account after March 15 will remain available as long as the AdWords account remains open.

Anash P. Oommen, AdWords Scripts Team

Generating the Snippet Status Report with Ad Exchange Buyer REST API

Friday, July 18, 2014

If you are running DoubleClick Ad Exchange Real-Time Bidding campaigns, you can now use the Snippet Status Report Generator to obtain a Snippet Status Report for your creatives. The Snippet Status Report contains the approval status of your creatives, as well as the sensitive and product categorization that Ad Exchange automatically detects. The Snippet Status Report Generator produces reports using the Ad Exchange Buyer REST API.

There are three versions of this report available through the generator: a human readable text format, a binary protocol buffer format, and a spreadsheet-friendly CSV format. The text and protocol buffer version of the report can also be obtained via Google Cloud Storage. The CSV version can be used with spreadsheet programs such as Google Sheets, Microsoft Excel or LibreOffice Calc:

The Snippet Status Report Generator is available on GitHub as a python program. You are encouraged to download it and make modifications to generate reports in your desired format.

If you have any questions or feature requests for the Snippet Status Report Generator, please create an issue on the project’s issues page.

For any questions about the Ad Exchange Buyer API, visit us on the forum or our Google+ page.

- John Qin, Ad Exchange RTB API team

Deprecating PHP 5.2 support for the Ads PHP Client Library

Thursday, July 17, 2014

Starting January 1st, 2015, the PHP Ads client library will stop supporting PHP 5.2:

We will no longer test against PHP 5.2, or fix bugs that only affect PHP 5.2 users
Newer versions of the library may not work with PHP 5.2

This will impact PHP client library users of the AdWords API, the DoubleClick for Publishers API, and the DoubleClick Ad Exchange Buyer APIs.

PHP 5.2 hasn’t been supported since 2011 and should be upgraded to a current, stable version. Upgrading ensures you’ll receive the latest security updates.

In addition, there are numerous issues when using the PHP 5.2 SOAP client, such as:

No support for chunked encoding
Inability to set HTTP protocol version
Inability to set custom HTTP headers

In particular, custom HTTP headers are required for the DoubleClick for Publishers API starting from DoubleClick for Publishers API v201405 - the OAuth 2.0 access token must be passed via the HTTP headers rather than the URL parameter. In this case, PHP 5.2 users must upgrade in order to use DoubleClick for Publishers API v201405.

As always, if you have any questions, drop us a line on the forums (AdWords API, DoubleClick for Publishers API, DoubleClick Ad Exchange Buyer API) or Ads Developers Google+ page.

- Ray Tsang, AdWords API Team

AdWords - Meaningful Return Values

Tuesday, July 15, 2014

We are always striving to make sure the data you fetch from the AdWords API is as meaningful as possible, and in v201406 we've made a few changes to some return values that should be more intuitive.

First, in the TrafficEstimatorService, we used to return 0 for values which we couldn't calculate, for example if a field requires division by zero. However, this could’ve given the false impression that the actual value was 0, rather than that it couldn't be calculated. For this reason, we’ve changed the logic to return null in cases where the value couldn't be calculated at all. This affects the averageCpc and averagePosition fields in StatsEstimate, as these values will not be returned in SOAP responses when they can’t be calculated.

Second, when using the Keyword Performance Report, we formerly returned all negative keywords as having a "pending review" approval status. Since negative keywords don't need to go through the same process as normal keywords, we will now return a null value instead for the ApprovalStatus field for all negative keywords.

This change only affects version v201406 going forward, and doesn’t affect existing versions v201402 or v201309.

As always, we are constantly looking to improve the API. If you have any questions about this or other API features, please feel free to ask on the forum or on our Google+ page.

- Michael Cloonan, AdWords API Team

Changes to Ads API .NET client library

Tuesday, July 15, 2014

We have made a few changes to the Ads API .NET client library to allow better maintenance and support.

Unified repository

For ease of maintenance and to reduce duplication, we have combined the AdWords, AdXBuyer, DFP and DFA API .NET libraries into one repository: https://github.com/googleads/googleads-dotnet-lib

Going forward, please use the new repository for downloading Ads API .NET client library releases, reporting issues, requesting features, and providing source contributions.

We have updated wiki articles, consolidated open issues, and imported source code of past releases.

New runtime requirement

We have increased the runtime requirement for the client library to Microsoft .NET Framework 4. This upgrade allows us to enhance the library using features available in newer versions of the Microsoft .NET framework, while moving away from .NET 2.0, which is past its mainstream support period.

In case you are still using Microsoft .NET Framework 2.0, you may continue using the legacy library until July 1st, 2015, at which time we will stop providing bug fixes and enhancements to the library. Major feature enhancements and support of newer versions of the APIs will be limited to the newer library that uses Microsoft .NET Framework 4.

Updates to version numbers

We have updated the version number of the Ads API .NET client library to 18.0.0. The Common library version has been updated to 3.0.0. Going forward, all the API-specific client library assemblies will share a single version number, while the Common library will continue to maintain its own version number.

The legacy library assemblies will only have minor releases, and will use the following versioning scheme on both Github and Nuget:

Google.Ads.Common: 2.x
Google.AdWords: 17.x
Google.Dfp: 7.x
Google.Dfa: 5.x

If you have questions or feedback, let us know on our forum or our Google+ page.

Anash P. Oommen, Ads Developer Relations

A day in the life of a mobile line item (part 1)

Friday, July 11, 2014

Imagine for a moment that you're a mobile line item. You've just been initialized locally, and all of a sudden you’re having an existential crisis -- what makes you, you? How are you different from all the other line items? Sure your associated creative might be a bit different from other line items and you might have a few extra impressions allotted to your goal, but what truly makes you... unique? In this series of posts, we'll take you on an incredible journey through a day in the life of a mobile line item -- from how to target mobile to the actual delivery on a device.Adding mobile specific targetingIt all starts similarly enough: you need a name, an order ID, start and end dates, a goal, and all the usual suspects -- but wait, there's more! Instead of just having custom criteria, ad units, and geo-targeting, you find that you also have TechnologyTargeting fields specified, like:

DeviceCategoryTargeting

OperatingSystemTargeting

MobileCarrierTargeting

Now, say you're being created as a line item to advertise Android tablet cases. It doesn't make much sense for you to be delivered to an iPad or an iPhone, so we need to add technology specific targeting.To do so using Java, we would first set the DeviceCategory object with the targeting ID of the 'Tablet' category and the OperatingSystem object with the targeting ID of 'Android', both of which we'd pull from the PublisherQueryLanguage service:DeviceCategory deviceCategory = new DeviceCategory(); OperatingSystem operatingSystem = new OperatingSystem(); deviceCategory.setId(30002L); operatingSystem.setId(501013L);These would then be set on the DeviceCategoryTargeting and OperatingSystemTargeting objects:DeviceCategoryTargeting deviceCategoryTargeting = new DeviceCategoryTargeting(); OperatingSystemTargeting operatingSystemTargeting = new OperatingSystemTargeting(); deviceCategoryTargeting.setTargetedDeviceCategories(new DeviceCategory[] {deviceCategory}); operatingSystemTargeting.setOperatingSystems(new OperatingSystem[] {operatingSystem});Finally, the Targeting object will have a TechnologyTargeting object set for DeviceCategoryTargeting and also OperatingSystemTargeting:TechnologyTargeting techTargeting = new TechnologyTargeting(); technologyTargeting.setDeviceCategoryTargeting(deviceCategoryTargeting); technologyTargeting.setOperatingSystemTargeting(operatingSystemTargeting); Targeting targeting = new Targeting(); targeting.setTechnologyTargeting(techTargeting);Now what happens? You're a line item that has a bit of technology targeting specified, but where are you off to next? Stay tuned for what happens next in - 'A day in the life of a mobile line item, part 2.'

- Nicholas Chen, DFP API Team

New OAuth 2.0 Scope for the AdWords API

Thursday, July 10, 2014

A new OAuth 2.0 scope for the AdWords API was introduced along with the v201406 client library release. The OAuth 2.0 scope identifies the service that your application can access during the authorization process.

The new scope is: https://www.googleapis.com/auth/adwords. This new scope better aligns with the naming conventions of many of the other Google APIs.

Starting today, use the new scope when authorizing access for the AdWords API regardless of the AdWords API version. All our current AdWords API client libraries use this new scope.

But I have refresh tokens from the deprecated scope...

Don’t worry if your client code is using refresh tokens authorized with the deprecated scope - they will still work. However, new authorizations should specify the new scope.

As always, if you have any questions, drop us a line on the AdWords API forum or Ads Developers Google+ page.

- Ray Tsang, AdWords API Team

New labels features in AdWords API v201406

Thursday, July 10, 2014

Many developers in the AdWords API community have mentioned that being able to create, modify, assign, and report on labels through the API would be extremely helpful. Well, we're excited to report that the v201406 release of the AdWords API includes all of these requested features!

Summary of label services and features

End-to-end example
So how do these new features work together? Check out our labels guide to get you on the road to AdWords label expertise!

Next steps
If you've never used labels in your account or need a refresher course, check out the Help Center labels guide. Once you're ready to dive in, try out the label examples in your client library of choice.

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

- Josh Radcliff, AdWords API Team

Announcing v201406 of the AdWords API

Wednesday, July 9, 2014

Today we’re announcing the release of AdWords API v201406. Here are the highlights:

Labels support. The new LabelService now allows you to manage your labels through the API. We've also extended the relevant services to allow setting labels at all levels (campaign, ad group, ad, keyword) and updated reporting to allow labels-based retrieval and filtering.
Upgraded URLs. The next generation of destination URLs allow you to specify multiple destination URLs for your ads, criteria and sitelinks. URL templates allow you to change the tracking parameters of your destination URLs without repeatedly reviewing and verifying landing pages. This feature is currently available for test accounts only, but will become generally available soon.
Distance targeting. The new LocationExtensionOperand allows you to set a radius around campaign location targets to reach users within the specified area. This will replace legacy Proximity targets in the future.
Improved accounts management. ManagedCustomerService now allows you to move whole subtrees between MCCs.
Consistency updates. We updated a number of fields and report columns to be more consistent across the API. Make sure to check the release notes for the full list of changes.

Note: ClientLogin authorization protocol is deprecated and is no longer supported in versions v201402 and later. You need to migrate to OAuth2 to use AdWords API v201406 and access these new features.

If you're still using v201309 of the AdWords API, please note that it's being sunset on July 21st, 2014. We encourage you to skip v201402 and migrate straight to v201406. If you're using v201402, be aware it's now marked deprecated and will be sunset on November 6th, 2014.

As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201406 migration guide. The updated client libraries and code examples will be published shortly. With this release, we've also updated the Required Minimum Functionality document to include some of the newly added features that are now required in third-party tools. If you have any questions or need help with migration, please post on the forum or the Ads Developers Plus Page.

- Danial Klimkin on behalf of AdWords API Team.

Changes to Pretargeting for Ad Exchange Buyer RTB Campaigns

Tuesday, July 8, 2014

DoubleClick Ad Exchange is improving its pretargeting system by creating a new user interface and API resource to configure the inventory your bidder sees. These changes will only impact your RTB campaigns; non-RTB campaigns will continue to be managed as they were before.

Upgrades will begin in mid-July 2014 and all accounts will be upgraded by the end of September 2014. The new functionality has been added to the v1.3 REST API but will be read-only until your account has been upgraded. For additional information, please review the new resource reference and pretargeting guide.

Note that once your account has been upgraded you will still have access to the SOAP API for reporting, budgeting and non-RTB campaigns, but you will no longer be able to use it for pretargeting. If you need the ability to manage your pretargeting settings via the API, then you must use the latest AdX REST API.

If you have questions about these upcoming changes please contact your account manager. For questions about the Ad Exchange Buyer API, check out the Ad Exchange Buyer API forum. Follow our Google+ page for other announcements and updates.

Dean Lukies, DoubleClick Ad Exchange Buyer API Team

Line item duration issues in the DFP API v201405

Wednesday, July 2, 2014

At Google, we always want to be transparent with you about changes to our API. We recently announced v201405 of the DFP API, and, in v201405, we consolidated a line item's goal fields into its own Goal object and added the field LineItem.primaryGoal. During this refactor, the LineItem.duration (previous versions) field was removed from LineItem, but didn't make it into the Goal object due to an implementation error. This means that, in v201405, you cannot set the duration field when creating or updating line items. Instead, the server will set it to the default value.

Fortunately, this is only an issue for some LineItemType constants; many line item types only allow for one duration type, which is also its default, so setting it is not necessary. If you use the following line item types, v201405 will throw an error to prevent you from accidentally resetting the duration type if you update those line items:

If you need to create or update line items of these types, we recommend that you use v201403 or earlier to do so. In the next version of the API, we’ll add the duration field back as “goalType” to the Goal object. We are waiting until the next version so that we do not change the existing v201405 WSDLs, which would break early v201405 adopters' code.

As always, if you have any suggestions or questions, feel free to drop us a line on our API forums or Ads Developer Google+ page.

- Vincent Tsao, DFP API Team

New AdWords API guides

Wednesday, July 2, 2014

Did you know we have an extensive set of themed guides on the AdWords API Developers site? We do our best to have every topic covered and to keep all of them up-to-date. If you find that particular functionality needs better coverage, or we have a gap on a certain topic, let us know!

Meanwhile, my colleagues have published five new guides for the AdWords API:

We are looking forward to hearing your feedback via our G+ page or on the forum.

- Danial Klimkin, AdWords API Team.

AdWords and DoubleClick Ad Exchange API users - Only 3 weeks left to migrate from ClientLogin to OAuth 2.0!

Tuesday, July 1, 2014

ClientLogin authentication support for the AdWords API and the DoubleClick Ad Exchange API will sunset along with v201309 on July 21st, 2014. You only have 3 weeks left to migrate!

We have plenty of resources to help you migrate. It might take longer than you expect to migrate to OAuth 2.0, especially if you don't already use a single top-level MCC to manage your AdWords accounts or if you are a DoubleClick Ad Exchange customer.

Start your migration as soon as possible and reach out to us early on the AdWords API Forum or the DoubleClick Ad Exchange API Forum with any questions.

- Ray Tsang, AdWords API Team

Ads Developer Blog

Labels

Archive