Tag Archives: geotargeting

Changes to location targeting in Google Ads Search, Shopping, Display, and Performance Max campaigns

Starting on April 14, 2023, there will be changes made to the location targeting settings for Search, Shopping, Display, and Performance Max campaigns in the Google Ads API. We are making this change to simplify the location targeting portfolio and improve advertiser performance. All versions will throw errors if you try to set the location target settings to one of the values shown below.

Campaign.geo_target_type_setting fields
positive_geo_target_type can no longer be set to SEARCH_INTEREST for Search, Shopping, and Display campaigns. The default value is PRESENCE_OR_INTEREST.
negative_geo_target_type can no longer be set to PRESENCE_OR_INTEREST for Performance Max, Search, Shopping, and Display campaigns. The default value is PRESENCE.
The error returned if these values are used is SettingError.SETTING_VALUE_NOT_COMPATIBLE_WITH_CAMPAIGN.

On April 24, 2023, we will start performing any necessary auto-migration of fields to the new default values until no more invalid combinations exist. The auto-migration will occur on a per-campaign basis. You can confirm that the migration is complete for a Google Ads account by checking that these two queries return zero rows.


SELECT campaign.id, campaign.geo_target_type_setting.positive_geo_target_type, campaign.advertising_channel_type FROM campaign WHERE campaign.advertising_channel_type IN ('DISPLAY', 'SEARCH', 'SHOPPING') AND campaign.geo_target_type_setting.positive_geo_target_type = 'SEARCH_INTEREST' LIMIT 1
SELECT campaign.id, campaign.advertising_channel_type, campaign.geo_target_type_setting.negative_geo_target_type FROM campaign WHERE campaign.geo_target_type_setting.negative_geo_target_type = 'PRESENCE_OR_INTEREST' AND campaign.advertising_channel_type IN ('DISPLAY', 'PERFORMANCE_MAX', 'SEARCH', 'SHOPPING') LIMIT 1
Where can I get support?
If you have questions, please reach out to us on the forum or at [email protected].
Nadine Wang, Google Ads API Team

Sunset of deprecated Geo Region targeting options in Display & Video 360 API

Starting January 2021, over 1500 deprecated Geo Region targeting options will no longer be supported in Display & Video 360. This announcement, along with the full list of deprecated options, can be found on the Geography Targeting Help Center article. These deprecated targeting options reflect outdated geographical regions and, therefore, do not change the serving of line items.

How will this happen in the API?

This sunset will be reflected in the Display & Video 360 API through the following sequence of events:
  1. Starting today, we will begin removing deprecated targeting from older resources. These resources consist of Line Items or Insertion Orders that are currently archived or have been paused for more than six months.
  2. In February 2021, the deprecated targeting options will no longer be retrievable through the Targeting Options service and attempts at assigning or removing deprecated targeting through the Line Item Assigned Targeting Options service will return an error.
  3. After the deprecated targeting options are no longer able to be assigned, we will begin removing deprecated targeting from all remaining resources. Any line items only using deprecated targeting will be paused upon the removal of said targeting. This concludes the formal sunset of the deprecated targeting options.

What should I do to prepare for this?

In anticipation of this sunset, it is recommended that you do the following:

  1. Check to see if any existing Line Items utilize deprecated targeting options. Use advertisers.lineItems.targetingTypes.assignedTargetingOptions.list to list the assigned Geo Region targeting for each active line item and check the targeting against the deprecated targeting options. Remove or replace any deprecated targeting as soon as possible using advertisers.lineItems.bulkEditLineItemAssignedTargetingOptions.
  2. If you are storing oft-used targeting option IDs locally, cross-reference them against the list of deprecated targeting options. This will avoid errors caused by attempting to assign sunset targeting options.

Should I expect more deprecations in the future?

Users should expect the occasional deprecation and sunset of targeting options in Display & Video 360 in much smaller quantities than this deprecation. As such, future deprecations likely won’t be announced through a blog post or documentation change.

In order to account for these deprecations, it is recommended that you use targetingTypes.targetingOptions.get to confirm that a targeting option is still available before assigning it. This should be done before assigning any option not obtained through the Targeting Options service, including those stored locally or copied from existing targeting. This will avoid errors caused by attempting to assign deprecated targeting.

You can read more about the Targeting Options and Assigned Targeting Options services in our reference documentation and on the Set Targeting page of our Managing Line Items guide.
If you have questions or run into issues navigating this process, please contact us using our support contact form.
- Trevor Mulchay, Display & Video 360 API Team

Sunsetting manual location extensions from feeds

At the moment, location extensions in AdWords can be sourced from two different places: a Google My Business account that is linked to your AdWords account or - for legacy users - manual location extensions created as feed items in AdWords.

What’s changing?
We’ll sunset manual location extensions on May 20, 2017 for all legacy users. You’ll no longer be able to manually create and manage Feed and FeedItem with a corresponding FeedMapping of placeholderType 7 (location extensions) and placeholderType 77 (location targeting) after this date. Instead, create your locations in Google My Business and link them to your AdWords account as outlined in our Location Extensions guide. You can use the Google My Business API to manage your business locations at scale.

What you should do
Please migrate your code before May 20, 2017 to avoid being impacted by this transition. See our guide for managing location extensions for further details, including an end-to-end code example. We recommend migrating your existing legacy locations alongside your code in order to have full control over your Google My Business account structure, test your setup, and avoid any downtime in location extension management. If you're not concerned about downtime, let us migrate your existing manual location extensions for you (you still have to migrate your code).

Auto-migration
All unmigrated manual location extensions stored in AdWords will be gradually auto-migrated starting from May 22, 2017.
  • For each Customer Account with unmigrated manual location extensions, we'll pick all Manager Accounts at the lowest level of the manager hierarchy.
  • For each such Manager Account, we'll create a single Business Account in Google My Business managed by the administrative users of the original Manager Account and its managers. The name of this Business Account will be ‘AdWords (<cid>)’, where <cid> is the AdWords Customer ID of the original Manager Account.
  • We’ll also create Business Accounts in Google My Business for Customer Accounts not linked to any Manager Account. Those will be managed by the administrative users of the Customer Account.
  • For each unmigrated location in the Customer Account, we'll create a new unverified business location in that Business Account and label it with its AdWords Customer ID. The original manually created feed items representing that location in AdWords will be removed.
  • We'll replace all unmigrated location extension and location targeting feeds with new feeds linked to the shared Business Account created in Google My Business. In each feed, we'll set up a labelFilter based on the Customer ID to map each location to its original account.
  • Any existing CampaignFeed and AdGroupFeed will be recreated to match the original setup, including their matching functions.
If you have questions while you’re upgrading, please reach out to us on the AdWords API forum.
- Timo Bozsolik, AdWords API Team

Changes to the setting of positiveGeoTargetType in AdWords campaigns

In September 2016, we will disallow the setting of positiveGeoTargetType as AREA_OF_INTEREST for non-search campaigns. Existing non-search campaigns whose positiveGeoTargetType are set to AREA_OF_INTEREST will be automatically changed to DONT_CARE. Any requests that attempt to set this to AREA_OF_INTEREST for non-search campaigns will fail.

In addition, for search campaigns, the behavior of AREA_OF_INTEREST will be changed. If you use this setting, the campaign will primarily target a user's area of interest and secondarily his/her location of presence. In other words, if the area of the user’s interest is explicitly present in a search query, such as “flower delivery in NYC”, then it’ll be used. If the search query doesn’t include any areas of interest, say “flower delivery”, the physical location of the user performing the search will be used instead.

If you have any questions or need help, as always, please post on the forum or the Ads Developers Plus Page.
, AdWords API Team

Adjusting the manual location extension sunset

In October 2015, we announced the Google My Business API and the sunset of manual location extensions in AdWords. To give developers more time to migrate their locations from AdWords to Google My Business, we have decided to extend the manual location extensions sunset and voluntary migration deadline beyond March 31. Existing locations in AdWords will not be auto-migrated until further notice. We will announce the revised sunset timeline and more details about auto-migration on this blog at a future date. Apologies for any inconvenience, please contact us if you have any questions.

Timo Bozsolik, AdWords API Team

Google’s handling of new top level domains

With the coming of many new generic top level domains (gTLDs), we'd like to give some insight into how these are handled in Google's search. We’ve heard and seen questions and misconceptions about the way we treat new top level domains (TLDs), like .guru, .how, or any of the .BRAND gTLDs, for example:

Q: How will new gTLDs affect search? Is Google changing the search algorithm to favor these TLDs? How important are they really in search? 
A: Overall, our systems treat new gTLDs like other gTLDs (like .com & .org). Keywords in a TLD do not give any advantage or disadvantage in search.

Q: What about IDN TLDs such as  .みんな? Can Googlebot crawl and index them, so that they can be used in search?
A: Yes. These TLDs can be used the same as other TLDs (it's easy to check with a query like [site:みんな]). Google treats the Punycode version of a hostname as being equivalent to the unencoded version, so you don't need to redirect or canonicalize them separately. For the rest of the URL, remember to use UTF-8 for the path & query-string in the URL, when using non-ASCII characters.

Q: Will a .BRAND TLD be given any more or less weight than a .com?
A: No. Those TLDs will be treated the same as a other gTLDs. They will require the same geotargeting settings and configuration, and they won’t have more weight or influence in the way we crawl, index, or rank URLs.

Q: How are the new region or city TLDs (like .london or .bayern) handled?
A: Even if they look region-specific, we will treat them as gTLDs. This is consistent with our handling of regional TLDs like .eu and .asia. There may be exceptions at some point down the line, as we see how they're used in practice. See our help center for more information on multi-regional and multilingual sites, and set geotargeting in Search Console where relevant.

Q: What about real ccTLDs (country code top-level domains) : will Google favor ccTLDs (like .uk, .ae, etc.) as a local domain for people searching in those countries?
A: By default, most ccTLDs (with exceptions) result in Google using these to geotarget the website; it tells us that the website is probably more relevant in the appropriate country. Again, see our help center for more information on multi-regional and multilingual sites.

Q: Will Google support my SEO efforts to move my domain from .com to a new TLD? How do I move my website without losing any search ranking or history?
A: We have extensive site move documentation in our Help Center. We treat these moves the same as any other site move. That said, domain changes can take time to be processed for search (and outside of search, users expect email addresses to remain valid over a longer period of time), so it's generally best to choose a domain that will fit your long-term needs.

We hope this gives you more information on how the new top level domains are handled. If you have any more questions, feel free to drop them here, or ask in our help forums.


Posted by John Mueller, Webmaster Trends Analyst

New geo targeting options in AdWords API

Building on our AdWords announcement in November 2013, v201402 of the AdWords API supports geo targeting for areas with particular places of interest or income levels. These are useful for reaching customers based on the types of places they visit or demographic information based on their location. Please check the support site for more information, and to determine if these new targeting options are available for the country you would like to target. Within the API, these new criteria types are called LocationGroups and can be applied on a campaign to affect all of its ads.

The targeting can be set up using a matching function, which you may already be familiar with from other parts of the API. There are three new operand types for LocationGroups matching functions. Each matching function will pair one of either IncomeOperand or PlacesOfInterestOperand with a GeoTargetOperand, which is always required, to target income brackets or places of interest within a specific geographical region.

For example, to target airports in New York City using the Java client library, you would set up a matching function using a PlacesOfInterestOperand and a GeoTargetOperand, like this: 

LocationGroups locationGroup = new LocationGroups();
Function matchingFunction = new Function();
matchingFunction.setLhsOperand(new FunctionArgumentOperand[] {
    new PlacesOfInterestOperand(null, PlacesOfInterestOperandCategory.AIRPORT)
});
matchingFunction.setOperator(FunctionOperator.AND);
matchingFunction.setRhsOperand(new FunctionArgumentOperand[] {
    new GeoTargetOperand(null, new long[]{ 1023191L }) // ID for NYC
});
locationGroup.setMatchingFunction(matchingFunction);
You can look up geo target IDs via the LocationCriterionService or in the documentation. You can also see fully functional, runnable code demonstrating this criterion type in each client library (Java, PHP, .NET, Python, Ruby, Perl).

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

- Michael Cloonan, AdWords API Team