Announcing v201409 of the AdWords API

[Danial Klimkin]

Today we're announcing the release of AdWords API v201409. Here are the highlights:

• Mobile campaigns for search and display. Search Mobile App and Display Mobile App campaign subtypes are now available via CampaignService. These new subtypes are a simplified way of creating campaigns focused on mobile app promotion.
• Ad Customizers. Ad Customizers previously available for Test Accounts only are now enabled in production. With this feature you can include dynamic values in your ads based on feed data.
• Currency support for conversions. Conversion trackers (including offline conversions) now supportcurrency specification. You can also set default currency per tracker.
• Website call conversion tracker. This tracker allows the collection of conversion stats for calls made on a script-generated phone number placed on your website.
• Rule-based remarketing lists. The new API version allows you to create and manage rule-based remarketing lists. This feature allows you to use simple rules to better target the people who visited your website.
• Better Labels handling. LabelIds column is now available in all relevant reports. We've also added both Labels and LabelIds columns to the Criteria Performance report.
• Updates to reporting. A new Extension Placeholder report is now available for retrieving consistent extension stats. Reporting interface was extended to allow you to control the presence of report headers and footers in the response.

There's also an important API-level change in v201409. Starting this version, the clientCustomerId header is now a required header for calls to all services except CustomerService. If your application relies on a default account identified by authorization credentials, you need to update it to send a valid customer ID for every request. You can obtain the customer ID via a get call to the CustomerService.

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

As with every new version of the AdWords API, we encourage you to carefully review all changes in the release notes and the v201409 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 don't hesitate to ask here or on the Ads Developers Plus Page.

-Danial, AdWords API Team.

[David Midgley]

Hi Danial

I was really hoping this release would remove the whitelist only restriction on the SharedSet Service as it's been in the API for a couple of releases in a row now. I just tried and got an access denied response from the API.

Any news on when this service will be enabled for all API users? I have clients with hundreds of thousands of duplicate negative keywords because they can't programmatically maintain their negative keyword lists using the SharedSet Service and therefore have to create separate negative keyword lists for every campaign containing exactly the same keywords.

Cheers

David

[Danial Klimkin]

Hello David,

As previously announced, we do not plan to expose Shared sets in the public API. Those services are available temporarily to the existing users only.

I will definitely follow up on this feature request internally.

-Danial, AdWords API Team.

[David Midgley]

Hi Danial

Just in case you are looking of use cases for shared sets, here are some below:

1. Adding search queries. If you have an automated system that adds search queries, you can't compare them with negative keyword lists to see if they match. This currently means holding lists in two places which could become unsynchronised. The strategy we currently use is to apply identical negative keywords to every campaign as the overhead of manually managing negative keyword lists and their application to campaign is too labour intensive. The drawback of this strategy is that the client has hundreds of thousands of negative keywords and it takes an age to sync the account with AdWords Editor.

2. Apply list based on label (name match). Because it's hard to see at a glance from the AdWords campaign interface which lists are applied where, you could write an app (or script) which scans labels to see if any match the name of a negative keyword list. If they do and the list is not already applied to the campaign, apply the negative list to the campaign. Since labels can be viewed easily by customising columns in the AdWords interface, it's much easier to see which campaigns have which list applied.

3. Apply list based on label (brand). This is similar to above, but this time a specific brand negative list is applied if a "Brand" label is NOT attached to the campaign. This ensures all your brand traffic goes to your brand campaigns.

4. List "layering". This allows for additional negative keyword lists to be applied if the budget is being exhausted too quickly. An app (or script) could apply a more strict negative keyword list to help slow spend. You could have multiple "layers" of lists that can be applied based on how much budget it left. This is preferable to lowering bids or pausing campaigns.

5. Audit application. An audit application that checks if you are applying best practice to an account can't see if/how you are using negatives as it has no visibiliy of shared lists.

I hope that helps build the case for API access to negative keyword lists!

Cheers

David