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

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^st 2013. 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 ofenablement 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:

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

• New KeywordMatchTypeId column in Keyword Performance Report (V8)
•  Migration Mapping Report (V8)

Additional Resources

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