Tag Archives: google_ads_api

Announcing v8 of the Google Ads API

Today, we’re announcing the v8 release of the Google Ads API. To use v8 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: 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.

Live Webinar: Migrating to the Google Ads API


The Google Ads API Developer Relations team will be hosting a live webinar on Migrating to the Google Ads API, on June 16 at 10 AM EST (2 PM GMT).

Agenda

This webinar helps AdWords API developers jumpstart their migrations to the new and improved Google Ads API. The webinar builds upon our Migration Guide, so we recommend reading that guide before watching this webinar. We will also host a Q&A at the end with members of the Google Ads Developer Relations and Engineering teams. The webinar will cover the following topics:
  • High level differences between the AdWords and Google Ads APIs
  • Migrating Reporting
  • Migrating Mutates
  • New & Improved Features
  • Migration Best Practices

Reminders

Feel free to add the event to your calendar. In addition, you can set a reminder for the event on YouTube by clicking the “Set reminder” button on the YouTube event page.

We look forward to sharing our knowledge of the Google Ads API with you and answering your questions. If you have any questions or need additional help, contact us via the forum or at [email protected].


Live Webinar: Migrating to the Google Ads API


The Google Ads API Developer Relations team will be hosting a live webinar on Migrating to the Google Ads API, on June 16 at 10 AM EST (2 PM GMT).

Agenda

This webinar helps AdWords API developers jumpstart their migrations to the new and improved Google Ads API. The webinar builds upon our Migration Guide, so we recommend reading that guide before watching this webinar. We will also host a Q&A at the end with members of the Google Ads Developer Relations and Engineering teams. The webinar will cover the following topics:
  • High level differences between the AdWords and Google Ads APIs
  • Migrating Reporting
  • Migrating Mutates
  • New & Improved Features
  • Migration Best Practices

Reminders

Feel free to add the event to your calendar. In addition, you can set a reminder for the event on YouTube by clicking the “Set reminder” button on the YouTube event page.

We look forward to sharing our knowledge of the Google Ads API with you and answering your questions. If you have any questions or need additional help, contact us via the forum or at [email protected].


Sunsetting the KEYWORD_MATCH_TYPE recommendation type

On July 21, 2021, all existing recommendations of the type KEYWORD_MATCH_TYPE will be removed and no new recommendations of this type will be generated anymore.

What's changing?
The KEYWORD_MATCH_TYPE recommendations will no longer be returned by search for all versions of the Google Ads API and Google Ads scripts.

All requests sent to apply or dismiss KEYWORD_MATCH_TYPE recommendations will fail with RequestError.RESOURCE_NOT_FOUND errors for all versions of the Google Ads API.

What do you need to do?
Before July 21, 2021, ensure that the changes described above will not lead to any issues in your code or application.

Then, as soon as you can, remove any references of the field Recommendation.keyword_match_type_recommendation and the type KeywordMatchTypeRecommendation in your code. They will be deprecated and removed in future versions.

If you have any questions or need additional help, contact us through the forum or at [email protected].

Sunsetting the KEYWORD_MATCH_TYPE recommendation type

On July 21, 2021, all existing recommendations of the type KEYWORD_MATCH_TYPE will be removed and no new recommendations of this type will be generated anymore.

What's changing?
The KEYWORD_MATCH_TYPE recommendations will no longer be returned by search for all versions of the Google Ads API and Google Ads scripts.

All requests sent to apply or dismiss KEYWORD_MATCH_TYPE recommendations will fail with RequestError.RESOURCE_NOT_FOUND errors for all versions of the Google Ads API.

What do you need to do?
Before July 21, 2021, ensure that the changes described above will not lead to any issues in your code or application.

Then, as soon as you can, remove any references of the field Recommendation.keyword_match_type_recommendation and the type KeywordMatchTypeRecommendation in your code. They will be deprecated and removed in future versions.

If you have any questions or need additional help, contact us through the forum or at [email protected].

Announcing the Google Ads Query Language Query Validator

Today, we are releasing a Google Ads Query Language (GAQL) Query Validator, so you can validate GAQL queries directly in the browser via the developer documentation site. This new tool is integrated with the Interactive GAQL Query Builder to make for a streamlined workflow.
In order to use the new query validator, either visit the query validator page directly or click the Enter or edit a query button on any resource’s query builder page.



Upon successfully validating a query with the query validator, continue editing the query using the Interactive Query Builder by clicking the Continue Editing in Query Builder button.





The Query Validator will also provide feedback related to errors in invalid queries.




In addition, you can continue manually editing and validating queries built with the query builder in the query validator by clicking the Enter or Edit a Query button after constructing a query with the query builder.





As you get started with the new query validator, please feel free to share feedback by clicking the Send feedback button on the top right of the page.

If you have any questions or need additional help, contact us via the forum or at [email protected]

Live Webinar: Error Handling, Retry, and Timeouts in Google Ads API

The Google Ads API Developer Relations team will be hosting a live webinar covering Error Handling, Retry, and Timeouts, on June 3 at 10 AM EST (2 PM GMT).

Agenda

The webinar will cover the topics below and include code walkthroughs to demonstrate how to perform different actions with the Google Ads API client libraries. We will also host a Q&A at the end with members of the Google Ads Developer Relations and Engineering teams.
  • Types of errors returned by the Google Ads API
  • Catching and deciphering Google Ads API errors
  • Identifying failed operations using partial failure mode
  • Setting HTTP timeouts
  • Best practices for retrying failed requests

Prerequisites

In order to get the most out of this webinar, we suggest you develop a basic understanding of the Google Ads API. To learn more, please visit our API Overview documentation or check out this Google Ads API Overview workshop from 2019. In addition, we strongly recommend that you install and configure one of our client libraries to follow along with the live coding examples.

Reminders

Feel free to add the event to your calendar. In addition, you can set a reminder for the event on YouTube by clicking the “Set reminder” button on the YouTube event page.

We look forward to sharing our knowledge of the Google Ads API with you and answering your questions. If you have any questions or need additional help, contact us via the forum or at [email protected].


Live Webinar: Error Handling, Retry, and Timeouts in Google Ads API

The Google Ads API Developer Relations team will be hosting a live webinar covering Error Handling, Retry, and Timeouts, on June 3 at 10 AM EST (2 PM GMT).

Agenda

The webinar will cover the topics below and include code walkthroughs to demonstrate how to perform different actions with the Google Ads API client libraries. We will also host a Q&A at the end with members of the Google Ads Developer Relations and Engineering teams.
  • Types of errors returned by the Google Ads API
  • Catching and deciphering Google Ads API errors
  • Identifying failed operations using partial failure mode
  • Setting HTTP timeouts
  • Best practices for retrying failed requests

Prerequisites

In order to get the most out of this webinar, we suggest you develop a basic understanding of the Google Ads API. To learn more, please visit our API Overview documentation or check out this Google Ads API Overview workshop from 2019. In addition, we strongly recommend that you install and configure one of our client libraries to follow along with the live coding examples.

Reminders

Feel free to add the event to your calendar. In addition, you can set a reminder for the event on YouTube by clicking the “Set reminder” button on the YouTube event page.

We look forward to sharing our knowledge of the Google Ads API with you and answering your questions. If you have any questions or need additional help, contact us via the forum or at [email protected].


The Query Builder Blog Series: Part 8 – Conclusion

This blog series follows the journey of building the new and improved Interactive Google Ads Query Builder tool. If you’ve read this entire series up to this point, you should understand many details and nuances of the Google Ads Query Language (GAQL). Part 8 will wrap up our journey and discuss what we’ve learned along the way.

Creating the User Interface

With the ResourceService, SelectionService, and ValidationService in place, all that is left to do is create the components that will comprise the user interface. In some cases, we can pull data directly from our services. In other cases, such as tracking selectability, selection status, or query validity, we can subscribe to our services so that the components always reflect the current state of the application.

Conclusion

This blog series has walked through several integral parts of the Query Builder application with an emphasis on those which can be useful in understanding GAQL. Let’s recap our learnings from each post:


Part 1 - Setting the Stage

Part 2 - Designing a Resource Schema
  • What a schema might look like for our application.

Part 3 - Creating a Resource Schema
  • How to use the GoogleAdsFieldService to retrieve field metadata.
  • Field compatibility in GAQL.
  • The REST discovery API.

Part 4 - Creating the Resource Service
  • GAQL query structure.
  • The various types of fields that can appear in GAQL clauses.
  • Field properties and how they correspond to different GAQL clauses.

Part 5 - Determining Field Selectability
  • Field compatibility and how to determine if a field is selectable.

Part 6 - Selecting and Deselecting Fields
  • GAQL query structure.
  • Additional detail regarding selectability.
  • Using Observables in Angular.

Part 7 - Query Validation
  • The various facets of GAQL query validation.

Bonus

In addition to everything we’ve learned about the Google Ads Query Language, I hope you’ve also picked up some tips about writing Angular applications. This was my first time using Angular, and I’ve found it to be a powerful framework for quickly building complex applications. Using Angular services with dependency injection along with observables has been an efficient way to manage app-wide state.


Hopefully this series deepened your understanding of how to construct 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]

The Query Builder Blog Series: Part 7 – Query Validation

This blog series follows the journey of building the new and improved Interactive Google Ads Query Builder tool. Part 6 of this series described how we select and deselect fields from a query. In Part 7, we will discuss how to validate queries based on user selections.

Background


While we’ve learned about field compatibility in Part 5 and a bit more about selectability in Part 6, it is still possible to create an invalid Google Ads Query Language (GAQL) string using the Query Builder. In order to account for this, we’ll create a ValidationService that subscribes to the Observable we created in the SelectionService in Part 6. Each time the Observable is triggered, we’ll perform a set of validation tests and generate a list of error messages. We’ll create another Observable in the ValidationService that is emitted each time the validations are run. This way, we can let users know if their query contains any errors. If the user hasn’t made any selections, this represents the initial state of the application, so we won’t show any errors in this case.





We will perform the following validation tests:
  • Ensure the SELECT clause contains fields
  • Ensure core date selections are valid
  • Ensure click_view has a valid date filter
  • Ensure change_event and change_status have valid date filters
  • Ensure change_event and change_status have valid limits

Ensure the SELECT Clause Contains Fields

A valid GAQL query must contain at least one valid field in the SELECT clause. If selections have been made in clauses other than SELECT, and the SELECT clause is empty, we will generate an error.

Ensure Core Date Selections are Valid

If there exists a core date segment (segments.date, segments.week, segments.month, segments.quarter, segments.year) in any clause of a query, then the filtering conditions in the WHERE clause must combine to form a finite date range of core date segments that, in aggregate, form a date range of at least one day. If there are no core date segments present in the query, we will not generate an error.


Otherwise, we’ll ensure that the core date segment filters in the WHERE clause combine to form a finite range. In other words, a single filter such as WHERE segments.date > ‘2021-01-01’ would fail because the date range is open ended, in which case we’ll generate an error. However, the following filters would be valid: WHERE segments.date > ‘2021-01-01’ AND segments.date < ‘2021-02-01’, WHERE segments.date = ‘2021-01-01’, and WHERE segments.date DURING LAST_7_DAYS. All three examples have a beginning and end date, so we will generate no error.


Finally, if the core date segment filters do form a finite range, we’ll check to ensure that, in aggregate, they result in at least a single day. For example, a query containing the following filtering conditions will fail because no dates meet both filtering criteria: WHERE segments.date = ‘2021-01-01’ AND segments.date BETWEEN ‘2021-02-01’ AND ‘2021-03-01’, in which case we will generate an error. However, this filtering condition is valid: WHERE segments.date BETWEEN ‘2021-01-01’ AND ‘2021-01-31’ AND segments.date >= ‘2021-01-15’ AND segments.date < ‘2021-03-01’ because the date range of ‘2021-01-15’ - ‘2021-01-31’ meets all filtering criteria, and therefore, we will generate no error.

Ensure click_view has a Valid Date Filter

When click_view is the main resource in the FROM clause, a date filter specifying a single day in the last 90 days must be present in the WHERE clause regardless of what other selections have been made.

Ensure change_event and change_status have Valid Date Filters

If either change_event or change_status is the resource in the FROM clause, there must be a valid, finite date range composed of filtering criteria in the WHERE clause similar to the rule Ensure Core Date Selections are Valid. However, this criteria applies regardless of whether or not any date fields are present in the query. In addition, the filtering conditions are not composed of core date segments because none of the core date segments are available when change_event or change_status is the main resource in the FROM clause (see Part 4). When change_event is the resource in the FROM clause, date evaluation on the Google Ads API server is performed on filters on the change_event.change_date_time field. When change_status is the resource in the FROM clause, date evaluation on the Google Ads API server is performed on the change_status.last_change_date_time field.

Ensure change_event and change_status have Valid Limits

If either change_event or change_status is the resource in the FROM clause, the query must contain a valid limit, or a positive integer.

Conclusion

We have now created a ValidationService that checks for errors in a GAQL query. Each time a GAQL string changes, we’ll run these checks, generate a list of errors, and emit an event from the Observable in our ValidationService. In the component that subscribes to this Observable, we’ll show an error icon for a non-empty error list. In this post, we’ve covered the various facets of GAQL query validation.


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]