Tag Archives: targeting

Changes to CampaignSharedSet Entities

Starting June 23, 2022, attempting to create a CampaignSharedSet with a shared_set that has a status of REMOVED will cause a MutateError.RESOURCE_NOT_FOUND error in the Google Ads API.

There will also be a one-time change to automatically update CampaignSharedSet entities to a status of REMOVED if they contain a shared_set with a status of REMOVED. Because the shared_set already has a REMOVED status, this won’t impact any active campaigns since we’re only changing CampaignSharedSet entities that don’t currently serve.

Where can I get support?

If you have questions, please reach out to us on the forum or at [email protected].

UserData Enforcement in Google Ads API

On January 10, 2022, the maximum number of user_identifers set in a UserData object will be reduced from 100,000 to 20. This is to clarify that each set should represent a single user.

The table below illustrates uploading UserData for two users (John Doe and Max Mustermann), each of whom has two email addresses.




Correct usage

operations: {
create: {
user_identifiers {
hashed_email: hash(“[email protected]”)
},
user_identifiers {
hashed_email: hash(“[email protected]”)
}
}
}
operations: {
create: {
user_identifiers {
hashed_email: hash(“[email protected]”)
},
user_identifiers {
hashed_email: hash(“[email protected]”)
}
}
}
Incorrect usage

operations: {
create: {
user_identifiers {
hashed_email: hash(“[email protected]”)
},
user_identifiers {
hashed_email: hash(“[email protected]”)
},
user_identifiers {
hashed_email: hash(“[email protected]”)
},
user_identifiers {
hashed_email: hash(“[email protected]”)
}
}
}

UserData is used for Customer Match and store sales uploads. In a given create/remove UserData operation, each set of user_identifiers should be for a single user.

Note that the same total amount of data can be sent in a single request, but each set of user_identifiers must represent a single person.

If the number of user_identifiers for a single set exceeds the new limit of 20, a TOO_MANY_USER_IDENTIFIERS error will be generated.

This will be applied to the two Google Ads API methods that provide UserData uploads:

If you have any questions or need additional help, contact us via the forum.

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.

Upcoming changes to mobile placement targets and exclusions

What's changing
Starting September 18, 2018, AdWords API requests that attempt to target or exclude a Placement criterion where the url is exactly adsenseformobileapps.com will fail and result in a CriterionError with reason INVALID_PLACEMENT_URL. You can read more about this change in the Google Ads help center.

What you should do
Modify your application so that it does not add the above Placement criterion via the AdWords API, and review and modify your mobile targeting to achieve your campaign goals. You will no longer be able to exclude all mobile apps from targeting using this Placement criterion, but you can refine your mobile app targeting and exclusions using any of the following criteria: For more details, check out the criteria usage grid that indicates which criterion types can be targeted and excluded at the campaign or ad group level. If you have any questions or need help, please contact us via the forum.

Changes to YouTube placements in AdWords scripts

We are rolling out a change to the way placements work when specifying YouTube URLs. Starting on August 14, 2018, using generic placements to specify YouTube channels or videos is going to be disallowed and will result in an error.

For more accurate video targeting, even when videos are played across platforms, use the new specific YouTubeChannel and YouTubeVideo placement criteria when you want to target specific channels or videos in AdWords scripts.

If you have any questions about these changes or AdWords scripts in general, you can post them on our developer forum.

Support for additional audiences in AdWords Search and Shopping campaigns

What's changing
Historically, some types of audiences have only been available for targeting and bidding in Display campaigns, as indicated by UserList.isEligibleForSearch = false in the AdWords API.

Starting at the end of September, 2016, both AdWords and the AdWords API will allow you to target additional audiences in Search and Shopping campaigns.

What you should do
  • Make sure that your application does not make assumptions about which user lists are available for Search and Shopping campaigns. Instead, your application should check the value of the isEligibleForSearch attribute of each UserList.
  • You can discover the audiences in your AdWords account and their eligibility for Search, Shopping, or Display campaigns by issuing an AdwordsUserListService get or query request that includes the IsEligibleForSearch and IsEligibleForDisplay selector fields. On an ongoing basis, you should periodically check for user lists where eligibility has changed due to improvements in AdWords.
  • If you'd like to add additional audience targeting to your Search or Shopping ad groups, add a BiddableAdGroupCriterion with a criterion set to an instance of the appropriate type of UserList. Make sure that your application can handle an OperationAccessDenied.OPERATION_NOT_PERMITTED_FOR_CAMPAIGN_TYPE error, which will occur if the particular UserList in your request is not currently available for Search and Shopping campaigns.
Further reading
For an overview of remarketing and audience targeting in the AdWords API, check out the Remarketing and audience targeting guide.

If you have any questions, please post on the forum or the Ads Developers Plus Page.

Demographic targeting in Search campaigns coming to AdWords API

Adwords currently supports demographic targeting only for Display network campaigns, but starting September 19, 2016 and launching over the subsequent days, demographic targeting will also be supported for Search campaigns. All existing AdWords API versions will retroactively allow these criteria in Search campaigns.

The benefit here for AdWords API users is that AgeRange and Gender criteria will be allowed in Search campaigns. Formerly, you would receive a CriterionError.CANNOT_ADD_CRITERION_TO_SEARCH_PLUS_CAMPAIGNS error when trying to add these types.

If your application does any type of automatic bidding, make sure that you update your app to accommodate these new potential bid modifiers on Search campaigns before September 19. These new criteria may be added by users of the AdWords user interface, so your code may have to handle them even if your application doesn't add them explicitly. This may be particularly relevant if you use the "Target and bid" (targetAll=false) option in TargetingSettingDetail, because the new criteria will begin restricting targeting.

If you have any questions about this change, or other questions about the AdWords API, contact us via the forum.

Upgrade former AdWords interest category campaigns

In December 2014, we announced that “Other interests” has been superseded by affinity and in-market audiences. As a part of this transition, the associated criteria are no longer supported in AdWords API v201502.

To finalize this sunset, we’ll be auto-upgrading existing deprecated criteria of this type to supported ones. The auto-upgrade will happen gradually over several weeks starting May 15, 2015.

Campaigns that target "Other interests" will be automatically upgraded to one or more of the following options:
  • Affinity audiences for driving brand awareness and engagement from a defined list of categories;
  • In-market audiences for reaching customers actively researching and intending to make a purchase;
  • Topic targeting to target websites about specific topics.
Campaigns with "Other interests" exclusions will be converted to Topic exclusions during this upgrade. Campaigns that don’t target "Other interests" will not be affected by this upgrade. If you'd like to keep full control of your campaign targeting, make sure to upgrade your campaigns before May 15.

If you have any questions or need help with the upgrade, please post on the forum or the Ads Developers Plus Page.

Targeting views with DoubleClick

With over half of ads measured not viewed, it’s more important than ever for advertisers to be able to act on viewability measurement. That’s why we’re happy to roll out new product updates we announced at CES, that make viewability more actionable for advertisers using the DoubleClick platform.

As we heard from Neal Mohan earlier this month, “when it comes to impact, having your ad seen is not just important, it’s fundamental.” It’s why we’re investing heavily to help make viewability a common currency across the industry. Over the last year, we’ve enabled advertisers to buy only viewable impressions across the Google Display Network, built Active View viewability reporting into our DoubleClick platforms for display and video, and today we’re building on this even further with two launches that will help advertisers act on these viewability metrics. 

  • Viewability targeting in Doubleclick Bid Manager. Clients of DoubleClick Bid Manager can now measure and target impressions globally based on the historical viewability of an impression. By programmatically targeting viewable impressions, marketers are able to improve the performance of their campaigns, in real-time, eliminating the need to manually reallocate spend to find viewable impressions. 
  • Viewability data in DoubleClick Ad Exchange bid requests. Ad Exchange clients can now see the historical viewability percentage for every impression when available. With this signal, programmatic buyers can make smarter decisions about the value of impressions before they place their bids on Ad Exchange.

Viewability reporting has given marketers the data to understand how many of their ads were seen. Now they can use that same data to programmatically increase the viewability of their campaigns. For brands like TalkTalk Telecom Group, using viewability targeting on DoubleClick Bid Manager has driven strong results.

TalkTalk generates 94% more viewable impressions
TalkTalk Telecom Group, a leading TV, broadband, mobile, and phone provider in the U.K., was eager to boost the viewability of its ads while maintaining costs. Having already implemented programmatic buying to reach potential customers at the exact moment they're ready to commit, TalkTalk wanted to then ensure its ads were actually being seen by targeting viewable impressions. To do so, the company deployed DoubleClick Bid Manager with Active View. TalkTalk generated 94% more viewable impressions, increased CTR 133%, and lowered CPC by 40%.


"Being able to target by viewability with Active View is groundbreaking. Active View enables us to measure the viewability of our ads, and Bid Manager's viewability targeting feature provides us with a solution to increase the number of viewable impressions we buy." - Rich Bailey, online marketing manager, TalkTalk Telecom Group.

To learn more about the team’s approach and results, check out the full case study here.

Stay on top of new updates by subscribing to our newsletter and following us on Google+ and Twitter.

Posted by the DoubleClick Product Marketing team

Filtering report data by custom targeting key ID in the DFP API

A lot of our DFP API developers have been asking recently about how to filter report data by custom targeting key ID. Currently the DFP API allows you to filter report data by custom targeting value ID only. Until we have official support for filtering by custom targeting key ID in reports, you can use the CustomTargetingService and the ReportService together to achieve this goal.

Step 1: Use CustomTargetingService to get your keys and values

You will first need to use getCustomTargetingValuesByStatement and filter by the custom targeting keys you’re interested in to obtain all the corresponding values. For example:

    WHERE customTargetingKeyId IN (17, 18, 19)

If you have a lot of keys and values in your network, a better approach is to store these in a local database and do nightly syncs. Use getCustomTargetingKeysByStatement to obtain all the keys in your network, and then iterate through them, calling getCustomTargetingValuesByStatement for each key to obtain their values. Our client libraries all have examples of this. For instance, the Java example can be found in our ads Java client library GitHub repository. This way, you can look up the values associated with a custom targeting key more quickly and not do an additional API call.

Step 2: Use the values in a report query

Once you have the values for the custom targeting key you’re interested in, you can then use the ReportQuery.statement with the PQL IN clause to filter on the CUSTOM_TARGETING_VALUE_ID dimension. For example, say you were interested in filtering on custom targeting key ID of 7777. You look up the values of 7777 in Step 1, which gives you three value IDs: 3211, 88990, 123456. You can then use the IDs to effectively filter your report data by custom targeting key ID 7777.

    WHERE CUSTOM_TARGETING_VALUE_ID IN (3211, 88990, 123456)

However, please be aware that if you have a lot of custom targeting value IDs to filter on, you should batch them by querying for no more than 500 IDs at a time in the PQL IN clause. For example, you will run your report filtering on the first 500 IDs you’ve collected and save that report. Then you will run the same report on the next page of 500 IDs you’ve collected and so on until you have no more IDs. You can then combine the reports locally so that you have all the data for those custom targeting IDs.

If you have any questions about this, feel free to drop us a line on the DFP API forums or Ads Developer Google+ page.