Category Archives: Ads Developer Blog

The official blog for information about the AdWords, AdSense, DoubleClick and AdMob APIs and SDKs

Reminder to migrate to the AdMob API

Starting on October 12, 2021, developers will no longer be able to retrieve AdMob data from the AdSense Management API v1.4. Please start to migrate to the AdMob API which is generally available.

Where can I get my AdMob data?

After October 12th, 2021, using the AdMob API will be the only way you can access your AdMob data programmatically. The AdMob API helps app developers retrieve:

  • metrics that are consistent with the AdMob UI definitions and calculations
  • mediation reports that are not available through the AdSense API

What do I need to do?

Start migrating from the AdSense API to the AdMob API as soon as possible. If you do not complete the migration by October 12th, 2021, you will lose access to AdMob data through the AdSense API, which may impact your ability to make data-driven business decisions.

Follow the instructions in the migration guide to migrate your API workflow. Review these additional resources to support your migration:

Feel free to reach out to us via the AdMob API forum if you have questions or feedback regarding the AdMob API.

Reminder to migrate to the AdMob API

Starting on October 12, 2021, developers will no longer be able to retrieve AdMob data from the AdSense Management API v1.4. Please start to migrate to the AdMob API which is generally available.

Where can I get my AdMob data?

After October 12th, 2021, using the AdMob API will be the only way you can access your AdMob data programmatically. The AdMob API helps app developers retrieve:

  • metrics that are consistent with the AdMob UI definitions and calculations
  • mediation reports that are not available through the AdSense API

What do I need to do?

Start migrating from the AdSense API to the AdMob API as soon as possible. If you do not complete the migration by October 12th, 2021, you will lose access to AdMob data through the AdSense API, which may impact your ability to make data-driven business decisions.

Follow the instructions in the migration guide to migrate your API workflow. Review these additional resources to support your migration:

Feel free to reach out to us via the AdMob API forum if you have questions or feedback regarding the AdMob API.

Google Ads API v4 and v5 sunset reminder

The Google Ads API v4 and v5 will sunset on June 23, 2021. After this date, all v4 and v5 API requests will begin to fail. Please migrate to a newer version prior to June 23, 2021 to ensure your API access is unaffected.

We've prepared various resources to help you with the migration: If you have questions while you’re upgrading, please reach out to us on the forum or at [email protected].

April 2021 update to Display & Video 360 API v1

Today we’re releasing an update to the Display & Video 360 API which includes the following features:

More detailed information about this update can be found in the Display & Video 360 API release notes.

Before using these new features, make sure to update your client library to the latest version.

If you run into issues or need help with these new features, please contact us using our support contact form.

Upgrade to the Google Ads API from the AdWords API by April 27, 2022

If you are a developer currently using the AdWords API, you need to upgrade to the Google Ads API by April 27, 2022. On that date, the AdWords API will sunset and requests to the AdWords API will fail. With Google Ads API v7, we reached feature parity with the AdWords API making it possible for all developers to upgrade with a few exceptions listed at the top of the Migrating Features guide.

With the Google Ads API, you’ll see faster rollouts of new features and updates for tools like recommendations, asset management, and new ad types. We’ve also made improvements to existing features like Keyword Planner, change history, and billing. This provides more features to manage your campaigns and increases overall productivity.

Where do I start?
Any developers applying for a new developer token after today will only be given access to the Google Ads API. The following are useful resources for new API users: Existing AdWords API developers should start upgrading. Here are some resources to get started: Where can I get support?
If you have questions while you’re upgrading, please reach out to us on the forum or at [email protected].

Announcing v7 of the Google Ads API

Today, we’re announcing the v7 release of the Google Ads API. To use the v7 features, you will need to upgrade your client libraries and client code. The updated client libraries and code examples will be published next week. For more information on breaking changes, see the migration guide.

Here are the highlights:
  • We now have new assets that are available in test accounts:
    • Callout assets
    • Structured snippet assets
    • Sitelinks assets
  • The promotion assets we’ve added are available in production and test accounts.
  • The Google Ads API now supports reporting for Apple’s SKAdNetwork. This feature allows advertisers to query how many SKAdNetwork conversions they receive from their iOS apps as well as the SKAdNetwork conversion value of those conversions.
  • Keyword Planning now supports:
    • Refining keywords using annotation data
    • Selecting a custom date range for search volume
    • Requesting aggregate metrics for generated keyword ideas and for keywords in a keyword plan
  • We’ve added ad_group_ad_label and ad_group_criterion_label labels for easier filtering and selection.
  • You can now manage bidding strategy and campaign simulations.
  • We updated our resource exceeded errors to include more detail such as what type of limit was exceeded and how many resources are allowed by that limit.
  • You can now use marginal ROI campaign budget recommendations. This recommendation suggests adjusting a campaign's budget if we predict that its ROI will go up.
See the release notes for details and for more features.

Where can I learn more?
The following resources can help you get started: If you have any questions or need additional help, contact us via the forum.

The Query Builder Blog Series: Part 4 – Creating the Resource Service

This blog series follows the journey of building the new and improved Interactive Google Ads Query Builder tool. Part 3 of this series described how we used the GoogleAdsFieldService to create a detailed JSON resource schema to serve as the canonical data set for the angular application. In Part 4, we will discuss how to create a resource service that determines which fields are displayed to users in various parts of the application.

Background

One of the benefits of the new Interactive Google Ads Query Builder is that fields are dynamically updated based on user selections to display whether a field is selectable or not, and if not, users are provided with feedback to understand why a given field is not selectable. However, we must first present lists of fields that are available to select in each clause of a Google Ads Query Language (GAQL) string based on the main resource in the FROM clause of that GAQL string. We will create a service called the ResourceService that will contain this logic. Then, we can use Angular’s services and dependency injection model to pull the appropriate fields and their related information into any component.

Objective

The app is designed such that the FROM resource is determined by the user’s current URL. Therefore, the resource in the FROM clause and list of all available fields is constant based on that URL. For the sake of this post, we are only concerned with three GAQL clauses, SELECT, WHERE, and ORDER BY, because these are the only clauses that can be dynamically populated with fields. LIMIT accepts an integer, and PARAMETERS only has a single option.


Within each clause, we will organize each of the available fields into four categories: attribute fields, metrics, segments, and attributed resource fields for a better user experience. Our objective is to create a ResourceService that provides the relevant fields for a given clause and category.

Implementation

We can leverage the resource schema we generated earlier to select the entry for the main resource in the FROM clause as determined by the URL and filter its fields sub-entry to provide only fields that match specific criteria.


Let’s begin by categorizing our fields by clause.
  • Fields in the SELECT clause have the selectable property equal to true.
  • Fields in the WHERE clause have the filterable property equal to true.
  • Fields in the ORDER BY clause have the sortable property equal to true.
We can further break these field lists into attribute fields, metrics, segments, and attributed resource fields. Retrieving the metrics and segments in a given clause is trivial because our resource schema provides a list of metrics and segments (including segmenting resources). For each clause, we’ll include all of the segments and metrics that meet the clause-related criteria listed above.

Similarly, we can retrieve each clause’s main attribute fields by looking at the attributes of the resource in our FROM clause, filtering for those which begin with the resource name followed by a dot, and applying the clause-related filtering criteria above.

All of the other fields in our attributes entry are attributed resource fields. We can generate a list of attributed resources by creating a set of the unique prefixes (i.e., the text that precedes the dot) of the resource’s attributes excluding our main resource. Finally, we can create a list of fields by clause for each attributed resource by selecting the fields that are prefixed with each respective attributed resource’s name.

With all of this logic in place, we can create an interface that exposes methods for returning a list of fields in a given category and clause. Then, any component that is injected with the ResourceService can simply call the corresponding method to retrieve the appropriate list of fields.

Conclusion

We now have created a ResourceService that we can use to display relevant fields to a user constructing a GAQL query based on the clause and category they are viewing in the app. In this post, we’ve covered:
  • GAQL query structure.
  • The various types of fields that can appear in GAQL clauses.
  • Field properties and how they correspond to different GAQL clauses.

Hopefully this has deepened your understanding of constructing GAQL queries with the Google Ads API. If you have any questions or need additional help, contact us via the forum or at [email protected].

Adding New Resource Types to ChangeStatus in Google Ads API

We're hard at work in bringing some new resource types to the change_status report. Some planned future improvements include changes to shared sets and assets. While these types will be fully supported in future versions of the Google Ads API, the infrastructure changes we're making to support them will have some effects on existing versions as well.

When we add support for new resource types, you will be able to fetch the new rows in all versions of the API, with the resource_type returning as UNKNOWN in already released versions. In some specific instances, rows that previously had a known resource_type, such as CAMPAIGN, may start returning a resource type of UNKNOWN. This will occur if, for example, a change that was previously reported as a CAMPAIGN change was actually a CAMPAIGN_ASSET change all along. The future version of the API will know about the CAMPAIGN_ASSET resource type, but existing versions do not, so we must use UNKNOWN. This row will also have a new resource_name associated with it, which now includes the asset's ID as well.

The new resource name for the row will include an identifier that tells what kind of change it is. We will keep an updated list of these identifiers on the change status guide. This lookup will only be necessary for rows with an UNKNOWN resource type, and corresponds to the resource type that would be returned from the future API version when that resource type is fully supported.

We are planning multiple new resource types for this report, so please expect UNKNOWN types to appear for various new resource types. Rest assured that when you see this, it's because an upcoming release will have a newly supported resource type for the change_status report. We won't make any changes until at least May 24, 2021, so you have time to ensure that your code can handle UNKNOWN resource type rows.

If you have any questions, please leave a post on our forum so that we can help.

Reminder: Using v2.0 of the Content API for Shopping with new accounts ends on April 30, 2021

In March, we announced that beginning April 30, 2021 we will no longer allow new merchant accounts onto v2.0 of the Content API for Shopping as part of the sunset process. With less than two weeks to go until the April deadline, here is a quick reminder of the details.

What do I need to know?
  • This account restriction will not impact users accessing new sub-accounts via an existing multi-client account (MCA), provided that MCA has been actively making v2.0 requests.
  • New accounts using v2.1 of the Content API for Shopping will not be affected.
  • The sunset date for existing merchant accounts actively using v2.0 is September 30, 2021.
What do I need to do?
  • Migrate to v2.1 of the Content API for Shopping in order to continue interacting with new merchant accounts after April 30, 2021.
  • If you are concerned you won’t be able to meet the April deadline, please fill out this form to request an exemption.
If you have any questions or issues during migration, contact your Google representative for Merchant Center programs, or ask questions in the Content API for Shopping forum.

Announcing v2 of the AdSense Management API

We're happy to announce that v2 of the AdSense Management API is available starting today. This version adds the ability to fetch the status of sites on your account and aligns the AdSense Management API with current Google API standards.

At this time, v1.4 of the AdSense Management API is now deprecated, and it will sunset on October 12, 2021.

Notable changes from v1.4 to v2 include the following:
  • All deprecated methods in v1.4 have been removed in v2. This includes resource methods that did not specify an AdSense account.
  • Resources are now identified by a name field. For example, an AdClient’s name would be “accounts/{accountId}/adclients/{adClientId}”.
  • With v2, AdSense Management API reporting data now aligns with the AdSense UI. This means that AdMob and YouTube properties are no longer supported. If you need to continue to fetch AdMob data programmatically, please migrate to the AdMob API. Additionally, the AdSense Management API will only support report data going back 3 years.

For a full list of changes, see the release notes. As always, feel free to reach out to us on the AdSense API forum with any API-related questions.