API Blog

Some tips on handling duplicate errors when uploading keywords via the Bing Ads API

Dare Obasanjo - MSFT — Tue, 16 Apr 2013 17:59:58 GMT

Sometimes when adding keywords to Bing Ads, you might be surprised to encounter a duplicate keyword error when the keywords actually have different text. This is due to a process called normalization where Bing Ads eliminates certain superfluous characters such as punctuation marks when comparing newly added keywords for certain languages. Examples of how this process works are in our help topic on duplicate keywords.

Since the normalization rules vary across different languages in Bing Ads, it is sometimes may be difficult for developers to come up with effective strategies for consistently dealing with duplicate keyword issues. This blog post is intended to share our current best practices for adding keywords to the Bing Ads system via the API.

General guidelines for adding keywords

To avoid unnecessary redundancy in your keywords please use this information while working with Bing Ads. These recommendation are valid for all languages supported by Bing Ads.

Bing doesn’t differentiate keywords based on

- Case-sensitivity (i.e. Milk and milk)

- Number of white spaces or usage of tabs instead of whitespaces

- Decorated characters and accent mark (i.e. café and café)

- Numbers and date formats: there is no need to extensively add numbers and dates in different formats. Bing Ads will recognize any format you provide.

- Punctuation characters (i.e. “car” and “car.” will be considered the same)

These recommendations should be kept in mind especially when using keyword expansion tools which may unnecessarily bloat your keyword list with keywords that are considered the same by Bing Ads.

Effective error handling when calling AddKeywords with multiple keywords

Bing Ads APIs allow performing bulk upload of keywords to your campaigns via the AddKeywords service operation. The AddKeywords operation accepts up to 1000 keywords in one batch. However a challenge with this batch operation mode is that the entire operation fails if there are any duplicates detected in the batch. Duplicate detection includes failing the operation if two keywords have the same normalized form such as “Car” and “car”.

When writing code to add keywords to Bing Ads, it is recommended that you handle the exception that occurs when duplicate keywords are detected, retrieve the exact keywords that caused the failure from the exception details then retry the operation with the specified keywords omitted.

Below is the C# code that shows how to handle an exception that occurs as part of the AddKeywords call and then list out the duplicates that were detected

            catch (FaultException<EditorialApiFaultDetail> faultException)
            {
                const int CampaignServiceDuplicateKeyword = 1542;
                Console.WriteLine("Duplicate keywords detected: ");
                foreach (var error in faultException.Detail.BatchErrors.Where(error => error.Code == CampaignServiceDuplicateKeyword))
                {
                    Console.WriteLine("[{0}] {1}", error.Index, keywords[error.Index].Text);
                }
            }

An application can use the Index property of the error to locate the problem keyword from the original upload attempt, remove it and then retry the operation.

Below is a more complete sample showing adding keywords, handling the duplicate error and then filtering out of problem keywords before retrying.

using System;

using System.ServiceModel;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using BingAdsPractice.BingAdsSandbox;

namespace BingAdsPractice

{

class Program

{

static void Main(string[] args)

{

var client = new CampaignManagementServiceClient();

Keyword[] keywords = GenerateKeywordsArray("car", "SUV", "Car", "cars!", "car", "sedan", "SUV");

try

{

// 1. Try to add keywords and detect if call will fail

client.AddKeywords(

new AddKeywordsRequest(null, Settings.CustomerAccountId, Settings.CustomerId,

Settings.DeveloperToken, Settings.Password, Settings.UserName, Settings.AdGroupId,

keywords));

}

catch (FaultException<EditorialApiFaultDetail> faultException)

{

const int CampaignServiceDuplicateKeyword = 1517;

var duplicateKeywordIndexes = new List<int>();

// 2. Retrieve information about duplicate keywords

foreach (var error in faultException.Detail.BatchErrors.Where(error => error.Code == CampaignServiceDuplicateKeyword))

{

if (duplicateKeywordIndexes.Count == 0)

{

Console.WriteLine("Following keywords are considered to be duplicates:");

}

duplicateKeywordIndexes.Add(error.Index);

Console.WriteLine("[{0}] {1}", error.Index, keywords[error.Index].Text);

}

// 3. Retry to add keywords with filtered array

if (duplicateKeywordIndexes.Count > 0 && duplicateKeywordIndexes.Count < keywords.Length)

{

// Filter keywords array

Keyword[] filteredKeywords = FilterKeywords(keywords, duplicateKeywordIndexes);

client.AddKeywords(

new AddKeywordsRequest(null, Settings.CustomerAccountId, Settings.CustomerId,

Settings.DeveloperToken, Settings.Password, Settings.UserName, Settings.AdGroupId,

filteredKeywords));

}

Console.Read();

}

private static Keyword[] GenerateKeywordsArray(params string[] keywords)

{

var keywordsList = new List<Keyword>();

foreach (string k in keywords)

{

Keyword newKeyword = new Keyword()

{

BroadMatchBid = null,

ExactMatchBid = new Bid { Amount = .1 },

Param2 = "10% Off",

PhraseMatchBid = null,

Text = k

};

keywordsList.Add(newKeyword);

}

return keywordsList.ToArray();

}

private static Keyword[] FilterKeywords(IEnumerable<Keyword> keywords, IEnumerable<int> indexesToRemove)

{

Keyword tempKeyword = new Keyword();

List<Keyword> keywordToRemove = new List<Keyword>(keywords);

foreach (var index in indexesToRemove)

{

keywordToRemove[index] = tempKeyword;

}

keywordToRemove.RemoveAll(k => k == tempKeyword);

return keywordToRemove.ToArray();

}

A note on the usage of GetNormalizedStrings

Some developers use the GetNormalizedKeywords service operation to determine how to filter keywords before calling the AddKeywords service operation. Using this method is not recommended. This method does not utilize the same normalization steps as the AddKeywords operation and more importantly is redundant given the previously shown sample about handling duplicate errors thrown by AddKeywords.

This method will be deprecated in the next major release of the Bing Ads API which should be before the end of the year. Below is the current description of the behavior of the method

Language ID	Current normalization behavior
“English”, “French”, “Traditional Chinese”, “Portuguese”	Returns normalized version of keyword, stop words removed.
“German”	Returns normalized version of keyword, stop words are not removed.
All other languages	Returns the input keyword with no normalization applied

Note: Portuguese is currently not supported in Bing Ads but will be in the future.

Dare Obasanjo

Program Manager, Bing Ads Platform

Prepare for Product Ads Coming in Q3 2013

Dare Obasanjo - MSFT — Wed, 10 Apr 2013 17:39:43 GMT

We are preparing to offer a new search ad format in the U.S., Product Ads, which allows retail advertisers to include product details such as image, price, description, and merchant information within the ad. Product Ads pulls inventory from an advertiser’s real-time product catalog and creates the new rich ad format – delivering key details of the product offer that a user would need to make an informed decision before clicking to the advertiser’s site.

We are currently testing Product Ads with a limited number of advertisers and plan to roll out Product Ads in the U.S. to retail advertisers in early Summer 2013; stay tuned for more details on exact timing.

Action Recommended: Bing Ads API users can prepare for the release of Product Ads targeted in early summer by making code changes early. We suggest a code ready date of June 1st so that you are ready to support your customers and Product Ads when this feature is made available to U.S. advertisers. Product Ads is currently available in the API sandbox environment; the API documentation is available on MSDN. There is also sample code in C#, Java and PHP.

We will provide you with more specific release timing information as we get closer to launch, as well as planned future enhancements for this new search ad format. Please contact your account manager or stay tuned to the Bing Ads blog for more information.

Dare Obasanjo

Program Manager, Bing Ads Platform

Update to Business Locations and Location Extension v1 Sunset Timeline

Ricky Poole - MSFT — Thu, 07 Mar 2013 19:58:00 GMT

Earlier when we blogged about business locations and location extension v1 sunset, we got feedback from many partners and developers to allow additional time for this change. We have considered your feedback and as a result, we are moving the sunset deadline for business locations and location extension v1 by an additional quarter to early Q3 of this calendar year. As the sunset of location extension v1 and general availability of location extension v2 go hand in hand, below are the new timeline for location extension v2:

Phases (As mentioned in previous blog post)

Earlier

Now

Phase-2: Location Extension v2 Pilot Program Begins

Feb 2013

May 2013

Phase-3: General Availability of Location Extension v2 and Sunset of Business Locations and Location Extension v1 APIs

April 2013

Early Q3 2013

Resources:

Thank you!

- API Team

Prepare for Deprecation of Version 7 and Migration from Metro to DMA® Targeting

Eric Urban - MSFT — Mon, 28 Jan 2013 14:00:00 GMT

This is a reminder about two breaking changes coming in April 2013.

Bing Ads API Version 7 Sunset
Metro Target Deprecation

Bing Ads Version 7 Sunset

The Bing Ads API Version 7 is scheduled to sunset as early as the first week of April 2013. You must migrate your application to version 8 before the sunset date. Failing to go through migration will cause your application to stop working when the services are removed. For information about what’s changed from version 7 to version 8, see Migrating from Bing Ads API Version 7 to Version 8. To test your migrated application, use the Bing Ads API sandbox. For more information about using the sandbox, see Sandbox. Please reach out to support and forums if you have any questions or concerns.

For more information, see this blog post.

Metro Target Deprecation

Bing Ads is migrating to DMA^®targets and deprecating the metro target strings. Code to new DMA^® and city location strings before April 2013. Visit this MSDN link where you can download an XML document that contains the DMA® geographical location targeting codes. Note that both city and metro strings need to be updated. We plan to end support for the old metro and city API strings in April 2013.

For more information, see this blog post.

The 2013 January Bing Ads Release for API Users

Aurea Astro - MSFT — Thu, 24 Jan 2013 22:37:00 GMT

2013 is here and we're kicking off the new year with new features and UI updates to improve your Bing Ads experience. We haven't forgotten our dear API users, and have included a couple updates to your sandbox test environment in this month's release.

Data Purging (available across all markets). Data in your sandbox will be now purged 30 days after it has been created to limit capacity constraints. Developers who need to work on the sandbox for longer than a month will need to create tools that pre-populate their sandbox account with data before doing any development against the APIs in the sandbox.
Faster User Upgrade (available across all markets). Upgrading a reseller account in the sandbox used to take up to 2 weeks. Process improvements have reduced this timeframe to within a few days.

As always, we welcome your feedback in making Bing Ads the best experience for you. Feel free to drop into our Bing Ads Feature Suggestion Forum, or share your thoughts in the Developer Forum.

Heads Up: Changes to Business Locations and Location Extensions in Bing Ads API

Ravi Modalavalasa - MSFT — Fri, 07 Dec 2012 17:00:00 GMT

Business Locations and Location Extension –v1 APIs Will Sunset in April 2013

Business locations and location extension – v1 APIs will sunset in April 2013. Please plan to migrate your applications to location extension – v2 APIs which will be available in production through a pilot program starting February.

As location extension-v2 will provide all the functionality of location extension-v1, business location and more, the applications which are coded for features like business locations, business location targeting and location extension-v1 need to be updated to use location extension-v2 APIs.

Phase-1: Location Extension-v2 APIs in v8 Sandbox (Nov 2012)

Location extension-v2 APIs are now available on v8 Sandbox. Bing Ads API developers can get the code changes tested in sandbox.

To get started with v8 Sandbox, click on this link.

Note: All the current v8 sandbox customers should already have access to new APIs. Otherwise please contact support or your account manager.

Phase-2: Location Extension-v2 Pilot Program Begins (Feb 2013)

We will start onboarding customers on to location extension-v2 pilot. Evangelists/Account Managers will reach out to you for more details.

Business locations and location extension-v1 APIs will be deprecated for customers who are part of pilot program.

For more details on APIs that will be impacted and the location extension - v2 pilot program, please click on this link.

Phase-3: General Availability of Location Extension-v2 and Sunset of Business Locations and Location Extension-v1 APIs (April 2013)

Location ad extension feature will be available to all customers and we will also sunset business location and location extension-v1 APIs.

Happy Coding!

Bing Ads API Team

Video: Getting Started with the Bing Ads API

Scott White - MSFT — Fri, 30 Nov 2012 16:07:00 GMT

If you’re new to Bing Ads and are interested in getting started with using the API, check out this video. It shows you how to get access to the API, make you first call, and find API documentation.

Video: Get Started With the Bing Ads API

You can also check out the Getting Started documentation for more details.

Thanks and enjoy!

Prepare for Bing Ads API Version 7 Sunset and Migrate to Version 8

Eric Urban - MSFT — Sat, 17 Nov 2012 15:59:50 GMT

Mandatory Code Changes Required by Bing Ads API Users in Preparation for Landing Page by Match Type Updates

Ricky Poole - MSFT — Fri, 02 Nov 2012 21:02:00 GMT

As of early November, all customers in the U.S. have been enabled for Landing Page by Match Type (aka URL by Match Type), and we are now beginning to release this functionality to customers in Canada, India and Singapore, and soon to customers in the UK, Ireland and France. This post contains important information for API customers who may still need to make the required code changes prior to their migration.

With Bing Ads’ Landing Page by Match Type functionality, you will have more control and precision for managing each bidded keyword match type within the same ad group by assigning a unique destination URL. This will enable you to manage each URL and match type more independently to optimize and improve your campaign performance while making cross platform changes with more accuracy and ease. This feature also improves your ability to measure and track keyword performance by match type to more effectively optimize your campaigns.

Timing and Impact

Non-API advertisers with a customer-level market county setting of Canada, India, Singapore, UK, Ireland and France will be migrated to Landing Page by Match Type as early as January 2013. There is no action required for non-API customers prior to migration

Bing Ads API users (including Agencies/SEMs who manage advertisers) who have their customer level market setting set to Canada, India, Singapore, UK, Ireland or France will be migrated as early as Feb 1^st2013. All must prepare by making updates to their API code by February 1^st to ensure the continued ability to manage campaigns with Bing Ads APIs.

Timeframe of enablement of customers belonging to other markets (including the UK and France) is forthcoming and we will keep you informed as we update our release plan. (To determine your customer level Market setting, API users can pull this information from the v8 Customer data object.)

Details on code changes are provided below, but you can also refer to our MSDN documentation which contains this same information.

Mandatory Bing Ads API Code Changes Required

There are a few code updates API customers will need to make in order to leverage the functionality of Landing Page by Match Type and ensure continued management of their Bing Ads accounts with the APIs:

Current Rules	New Rules
The Keyword (KW) data object can have up to four different bids against (ExactMatchBid, PhraseMatchBid, BroadMatchBid, ContentMatchBid). Any match bid value on the KW object that is unused defaults (and is persisted in Bing Ads) as null. Note: Although content match is shown as an option, there is no contextual network within EMEA.	Keyword Object will only accept a bid for one of the four match types.
Bing Ads only allows a single instance of a keyword literal within the same ad group (e.g., you are unable to have two keyword objects that represent the bidded keyword “car”).	Business rule relaxed to allow multiple instances of the keyword in an ad group so long as there is no conflict/existing match type bid on the same keyword in the same ad group.
· Keyword Object and non-zero values: · Missing Bid: implies inheritance of bid from the ad group · Setting a bid explicitly to null: implies inheritance of bid from the ad group · Setting Bid to zero: Equivalent of deleting the match type for the Keyword	· Keyword Object and non-zero values: · As each Keyword Object instance can only have one match type bid, the remaining match type bids will need to be empty (different from null); Note that empty values will not default bids from the ad group. · Setting a bid explicitly to null: inherit the ad group bid for that match type (No change to this behavior) · Setting a bid to zero: not allowed (to delete a match type; advertisers need to call DeleteKeywords)
Content bids use the URL in the keyword object.	Keyword IDs can be created individually for content.

For Existing Keywords:

All existing Keywords will be converted so that the new “After Enablement” rules for the keyword object are not violated. The image below reflects the new keyword objects in yellow:

Bing Ads will determine what new Keyword Match Types to generate based on the number of clicks per match type over the last 30 days. The best performing match type will remain unchanged, and the remaining bidded match types will be moved to new KW instances that will have the same KW string, editorial status, URL and bid. There are some additional caveats API customers should be aware of:

If a KW has fewer than 1000 impressions, the KW ID retained will be based on the most restrictive MT. (Exact is the most restrictive with Broad being the least restrictive.)
If two MTs are tied for performance, the most restrictive MT remains unchanged and remaining MTs will be represented as new KWs moving forward.
Hybrid ad groups (ad groups that surface ads in Search & Content Networks): New KW ids will be created to represent content bids, regardless if the content MT bid is being inherited from the ad group.
Content-Only ad groups, exact, phrase, broad match types will get new IDs; existing IDs will always be retained with the content match type.
Ad groups will retain the 10,000 keyword object limit. If the limit is exceeded during migration, the migration itself will not fail, however no new KWs can be added until the KW count is under 10K.
New KWs will retain the editorial status of the original KW, but quality scores will be re-calculated.
To determine the migration status of an account, Bing Ads is exposing a new service operation called GetAccountMigrationStatuses.

Content Match Types When surfacing ads through the content network, Bing Ads will match against the Keyword ID that has a Content match type. In the event that a Content match type has not been created (the word “Car” is created for Exact , Phrase and Broad, but not Content), that KW continue to serve in the Content Network, however attribution will be associated with the least restrictive match type (in the order of broad, phrase, exact). It’s important to note that the contextual network is not available within EMEA, so the above information applies to the North American marketplace.

For reporting, all impression and performance data will be reported under “Content” for both delivered and bidded match types.

Reporting After Migration

If you are reporting on match type performance and reporting over a period that spans pre and post enablement, there could be two different keywords IDs with historic performance data that need to be referenced. For example, in the figure below, the March 1 rows represent performance data prior to the migration, and March 2 rows represent data reported after migration. In this example, reporting on the performance of exact match over the two day period would require referencing two different Keyword IDs. Note that if you do not report using the keyword ID column, the match type performance would be aggregated as-expected.

To assist you, Bing Ads is also releasing two different reporting capabilities:

KeywordMigration Report (in Reporting v8 only). This report will surface a new report that will show the keyword conversion “mapping” to reflect keywords and their “originating” KW, if any.
A New column called KeywordMatchTypeID (in the Keyword Performance Report). When selected as a column, the KW performance report will show post-migration keyword IDs (where new KWs were generated) and present a “unified” view of performance data. Using this column, the previous example would look as such:

Suggested Best Practices:

Pre-Enablement

Clean up ad groups at risk of exceeding the 10,000 keyword limit after feature enablement. Once this feature is introduced, each match type will count as a separate keyword. All keywords will be retained, but you will not be able to add new keywords to the ad group if the limit is exceeded.
For any match types you do not wish to have normalized into a new keyword, explicitly save a bid of 0.00 priorto migration; match type bids with null values will be normalized.Eliminate any five-cent bids designed to concede traffic.
In API version 8, code for the new service operation Get Account Migration Statuses to track account migration status. (Guideline: 15k calls every 4 hours)

Post-Enablement

Synchronize campaigns for newly generated KW instances Support new URL by MT business logic and accounts for any breaking changes (see table above)
Code for reporting changes (refer to reporting section)
Update destination URLs/tracking codes to each keyword match type if applicable(Guideline: 250k updates an hour, note that existing editorial validations and rules will continue to apply as today)

Reporting Changes

Additional Resources

MSDN Landing Page by Match Type Post
Keyword Object (Please navigate to the “Remarks” section of the document).

Heads Up: Bing Ads V7 API to Sunset April 2013

Scott White - MSFT — Thu, 18 Oct 2012 20:05:00 GMT

The Bing Ads V7 API will be removed April 2013. Please migrate your applications from v7 to v8 at your earliest convenience. For V8 API documentation, see Bing Ads API Version 8.

We are currently working on a migration guide to help you migrate to V8. The guide should be available in early November. We will update this post with a link to the guide when it’s available.

We’ve recently provided a V8 API sandbox that you can use to test your migrated application. For information about the V8 API sandbox, see Sandbox.

Thanks!

The V8 Sandbox for Bing Ads API Is Here!

Scott White - MSFT — Wed, 17 Oct 2012 18:00:00 GMT

We're happy to announce that we now have a V8 beta sandbox environment. It’s quick and easy to get access to the sandbox: just go to https://sandbox.bingads.microsoft.com and sign up for an account.

For details about getting started using the sandbox, see the sandbox documentation. If you’re a reseller, please contact your account manager to get access to the sandbox.

The sandbox will include the production release of the Campaign Management and Customer Management web services. We’ll let you know as we bring other web services online.

In case you’re new to Bing Ads – welcome! To learn how to use your new credentials, see Getting Started.

Thanks and enjoy!

Bing Ads API Maintenance Alert: Saturday, September 22 from 12pm to 2pm (Pacific)

Tina Kelleher - MSFT — Wed, 19 Sep 2012 18:30:00 GMT

If you didn't already see the update on the Bing Ads blog, this is just a quick note to all Bing Ads API users that the API will be unavailable from 12pm to 2pm on Saturday, September 22nd Pacific time. You will not be able to access the API or make calls during this time, but rest assured that your campaigns will continue to run and ads will continue to serve.

We apologize for any inconvenience.

Coming Soon: Bing Ads API is Migrating from Metro to DMA® Targeting

Peter Yang - MSFT — Wed, 05 Sep 2012 22:00:00 GMT

As you may have already seen on the Bing Ads Blog, in an effort to offer a more consistent experience for advertisers, Bing Ads is planning to migrate from metros to DMA^®s in late September through October. During this period, all advertisers currently targeting metros will be automatically migrated to DMA^®s.

Action Recommended for API Customers Currently Targeting Metros

We understand that API customers will need time to code to the new DMA^® strings. Therefore, we recommend the following action –

Code to new DMA^® and city location strings before April 2013 – First, visit this MSDN link where you can download an XML document that contains the DMA® geographical location targeting codes. Note that both city and metro strings need to be updated. We recommend that API customers code to these strings as soon as DMA migration finishes in the end of October.
Closely monitor your traffic during the transition period

Frequently Asked Questions

What is the metro to DMA^® migration timeline?

Date	Timeline
September 2012	New DMA^® API strings published
September to October 2012	All Bing Ads metros migrated to DMA^®s with new traffic
April 2013	Bing Ads no longer supports old metro and city API strings

Is there a breaking change to APIs in September if an advertiser doesn’t code to the new DMA^® and city strings?
No. However, even if you’re still reading / writing metros via API, traffic will be updated to DMA^®. Cities will see no change in traffic

When will Bing Ads no longer support the old metro and city strings?
We plan to end support for the old metro and city API strings in April 2013

Is there an impact for city targeting?
Yes. API users will need to update their city location strings before April 2013. There is no traffic change for cities

How will my geo targeting report change?
The report will switch to DMA^®s in September

If I’m using Bing Ads Desktop, Do I need to upgrade to a new version to use DMA^®s?
All metros will be switched to DMA^®s automatically for Desktop users in September and October

As always, if you have any questions or comment, feel free to leave them in the comments below or post a thread in the API forum.

Heads Up: Get Ready for New API Features in adCenter

Tina Kelleher - MSFT — Thu, 16 Aug 2012 19:30:00 GMT

Both the August and September releases of adCenter will include updates that all API users should be aware of and prepare for.

Bulk Service Operations

Having just been released out of pilot to all adCenter API users, Bulk Service Operations lets you download your adCenter campaign data in the background; if you keep a local cache of your campaign data, you should use this service instead of calling the Campaign management service’s entity operations.

Based on feedback from our pilot participants, we have released the new Bulk Download endpoint (for v8 only) as part of the August Release. If you’re using previous versions of the bulk service operations, or if you want to use the new bulk download capabilities for the first time, you need to reference and code to this new endpoint as documented on MSDN.

For specific instructions and best practices, please refer to the Bulk Service article on MSDN.

Coming in September:

1. API Throttling

For campaign API endpoints, API Throttling limits the number of calls to the API that any one user can make in a minute’s time. At the customer level, the number of calls a customer can make to the customer data is restricted using a sliding protocol with a 60 second window. The purpose of this practice is to protect the server load and promote fair usage of the system.

We believe in maintaining an open platform and building out the adCenter ecosystem for our customers. In order for adCenter to maintain openness and to continue facilitating growth, adCenter will begin to throttle extremely high-volume usage to maintain fair usage for all users.

Should you hit the API Throttle, you will see the following error:

Numeric code: 117

String error code: “CallRateExceeded”

Message: “You have exceeded the number of calls that you are allowed to make in a minute. Please reduce the number of calls that you make per minute.”

To resolve this error, you will need to reattempt by pausing for 60 seconds before resubmitting the request under the new limit.

2. Deprecation of Admin API version 7

As we no longer support quota management, Admin APIs will not be part of AdCenter APIs. If you’re using API version 7 (or any other older than v8), old code references will be deprecated at the end of August. You will need to remove existing Administration Service APIs, as well as the previously-piloted version of the Bulk Service Operations.

3. Metro Targeting Updates

In September, adCenter will be releasing new APIs that transition our targeting from metro areas to Nielsen DMA zones. Most advertisers will likely see an increase in traffic after this switch, however, in some instances, your traffic may decrease.

Once you’ve updated to the new APIs, be sure to review your campaign performance to make sure you’re still using optimal targeting options. Although the new DMA APIs will be released in September, the old APIs will continue to function through early 2013, so you have time to transition.

Stay tuned here to the API blog to keep updated on the latest news and info. If you have any questions, feel free to post them in the API forum.

The July 2012 adCenter Release for API Users

Tina Kelleher - MSFT — Mon, 23 Jul 2012 17:30:00 GMT

If you haven’t already checked out the July 2012 adCenter Release post over on the adCenter Blog, that’s where you’ll find all the details related to this month’s update. To ensure you, Dear API User, are aware of how these changes affect you, here’s some API-specific info for the updates and features that affect how you manage your campaigns.

Limit of As per Ad Group Increased to 50

The only aspect of this change that’s applicable to API users is that sending more than 20 ads per ad group will no longer generate an error in the API call, you’ll only run into that error if you send more than 50.

Domain Site Exclusions Limit Increased

The API will now allow for up to 2,000 site exclusions per ad group. Note, however, when retrieving site exclusions via the API, the service operation GetNegativeSitesByCampaignIds will be limited to returning a total of 30,000 negative sites. If you have many site URLs, we recommend retrieving site exclusions 15 campaigns/ad groups per call or GetNegativeSitesByAdGroupIds.

Thoughts? Comments? Questions? Leave a comment below, or stop by the API forum.