At Bing Ads we have been working hard for the last few months to bring you a wave of new features this summer. We are very excited to announce that, over the course of next several weeks, we’ll be rolling out many new features across our suite of APIs. We’ve refreshed our V9 service with many exciting new features and improvements that were the direct result of all your feedback.
Starting with this blog post we will highlight the specific features and updates to the Campaign Management Service, which is available to all developers starting today in Sandbox. Stayed tuned to our blog as we’ll continue to outline new features that have been rolled out to all the other services in Sandbox.
To summarize at a high level, these are the features that are now available in Campaign Management in Sandbox:
Developers have told us that managing negative keywords has been particularly challenging because API clients would have to manipulate an array of strings in our API. Previously your client would have to download the entire array of negative keywords, make your modification and then replace the entire array. This method becomes inefficient for simple use cases such as adding or removing one negative keyword. With thisrelease we are making Negative Keywords a first class entity complete with its own set of create, read, update, and delete operations to make managing your negative keywords as simple as any other object in theCampaign Management Service. You can now manage one or more of the negative keywords with these operations AddNegativeKeywordsToEntities, DeleteNegativeKeywordsFromEntities, GetNegativeKeywordsByEntityIds and These operations make it easier to add or remove specific negative keywords without having to operate on an array of strings. This change, still allows you to manage negative keywords at both the campaign and ad group level.
We also ensured that the new methods are backward compatible to our previous model of managing negative Keyword management through these APIs GetNegativeKeywordsByAdGroupIds, GetNegativeKeywordsByCampaignIds, SetNegativeKeywordsToAdGroups and SetNegativeKeywordToCampaigns. Your existing tools will continue to work with above old methods.
We’ve already heard that many developers would welcome this improvement and as a result we plan on deprecate the old methods in the next version of our API. It’s now recommended that APIclients should use these new methods to implement negative keywords as they’ll be more efficient for your implementation.
We are also introducing the ability to create up to 20 negative keyword lists per account, which can then be associated to one or more campaigns. This helps you manage negative keywords across multiple campaigns and it saves you from duplicating the negative keywords in every campaign.
Negative keyword lists effectively adds any new negative keywords that are not already directly applied to the campaign. In other words, the entire set of the negative keywords on a particular campaign is the unionof a shared negative keyword lists, combined with any negative keywords directly applied on the campaign.
You can manage negative keyword lists by using the NegativeKeywordList entity. Start by creating a list by calling the method AddSharedEntity. Once created you can associate it to a campaign via SetSharedEntityAssociations. For more details on how to manage negative keyword lists, please see the reference section on negative keywords.
We have also made an abundance of improvements to targeting to give you more control on when and where your ads show. Back in March we announced the upcoming radius targeting improvements. In addition to that we have added postal code targeting and made updates to Day and Hour targeting and physical intent targeting. We are adding new capabilities through the new object called Target2.
As we previously announced,you will now be able to apply both geo and radius targeting at the same time.In addition to that, you will be able to specify radius increments down to the mile instead of the fixed increments (5, 10, 20 etc.) that we had previously enforced. The new radius target object also allows you to specify units in terms of kilometers and miles as well. Please see RadiusTarget2.
We are replacing the existing Day and Hour target with a new DayTimeTarget in Target2. This adds the capability to have fully flexible time ranges, minute level granularity (0, 15, 30, and 45) and the ability to add individual time ranges per day. Your existing day and hour targets will continue to work (via the Target object) however once you make a change to those settings via DayTimeTarget you will no longer be able to modify the DayTarget or HourTarget via the old object. This is due to the fact that there’s much more flexibility in the new model which cannot be expressed by the existing DayTarget and HourTarget objects. From that point forward, you need to change these settings via Target2 and the DayTimeTarget. Note that even in this state you can still manage other types of targets (e.g. AgeTarget, GenderTarget) via the original Target object. This has no impact on the other targeting types.
We are adding a new PostalCodeTarget object to LocationTarget2 so you can more granularly target a specific location and assign different bid adjustments for different postal code locations within a city. This capability will be available only for U.S market in this release. We will be looking at adding support for other markets in the near future.
Today we have two choices for on location targeting; either physically located in the target location or not. We are adding three intent options available in the enum IntentOption on the LocationTarget2 object. We introduced an added option to select users who are only searching for viewing pages about your target but who are not physically located in your target location. This is available when you select “PeopleSearchingForOrViewingPages”.
Note that if you or another application sets the value to “PeopleSearchingForOrViewingPages” for the IntentOption element of this LocationTarget2 object, the HasPhysicalIntent element of the legacy LocationTargetobject will be null when retrieved. A subsequent set from the legacy LocationTarget object will ignore this null value.
As promised from our previous announcement, we’re also improving Site Link Ad Extensions. Now you will have the option of specifying two additional lines of descriptive text for each site link ad extension, andsetting the mobile device preference. We are also working on new ad extensions that will be announced shortly so stay tuned for more.
This is just the first of many API announcements and we are really excited to share all the new features that will be coming to our developer platform. As always, we would love for developers to provide their feedback on our APIs. We encourage developers to use the Sandbox and code against these new features so that they can test their implementation before we start piloting in June.
If you have any questions or comments, feel free to post them in the comments below.