Skip to contents

The problem is that the RAdwords package is used to work with Google AdWords API v201809. This API has not been updated for a long time and will stop working on 27 April 2022.

In this vignette, I want to share some information on a new package, rgoogleads, which I started working on in June 2021. The package currently has all the functions needed to request the function data. Next, we will go through the details of how to switch from RAdwords to rgoogleads, so that from April 2022, your scripts will still correctly collect the necessary data from your Google Ads accounts.

rgoogleads package features

The rgoogleads package currently includes all the functions needed to fetch data from the Google Ads API:

  • authorize in Google Ads API;
  • import the list of top-level accounts;
  • import the entire account hierarchy from management accounts;
  • import the ad account objects: campaigns, ad groups, ads, and more;
  • import statistical data from advertising accounts;
  • import resource metadata, resource fields, segments, and metrics;
  • import forecast and historical data from the keyword planner.

rgoogleads package benefits

Now let’s look at the benefits of switching to the new rgoogleads package:

  • rgoogleads is used to work with Google Ads API v8 (released on 09.06.2021); RAdwords is used to work with Google AdWords API v201809. Google AdWords API will sunset on 27.04.2022;
  • rgoogleads uses the gargle package for authorization, which gives much more flexibility than the RAdwords authorization process;
  • rgoogleads has an embedded Google Ads developer token and an OAuth client for authorization. This will save most users from having to request basic access to the Google Ads API from Google support and wasting time creating a project and OAuth client in the Google Cloud Console;
  • most rgoogleads functions have a cl argument, which allows for multi-threaded data import;
  • unlike RAdwords, rgoogleads has a list and account hierarchy import function;
  • rgoogleads has separate functions to import the main objects of the advertising accounts, such as advertising campaigns, ad groups, keywords, and ads;
  • since data request is not divided into separate functions, the syntax of rgoogleads is more straightforward and concise. In RAdwords, you had to initially create statement() function and then use it to request the data in the getData() function;
  • rgoogleads has no problem importing names containing Cyrillic characters;
  • if the API request encounters a server failure (response status 429 or higher), the rgoogleads package will automatically pause for 100 seconds and try to request data again. This makes this package more stable and resilient to Google Ads API server failures;
  • rgoogleads displays a detailed error message. In comparison, RAdwords will not display a message if the user has made a request error;
  • rgoogleads allows you to request data from the Keyword Planner.

Key differences between the Google AdWords API and Google Ads API

Fortunately, there are few key differences between the old and new APIs, and the migration process isn’t that difficult. Let me enumerate the key points of the migration below.

  • no need to change auto-ionization data; the developer token, ID, and client secret OAuth can also be used for a new Google Ads API;
  • The AdWords API reporting is a separate service, while Google Ads API reporting is part of the same service. All you need to do is include the necessary metrics fields in your reports;
  • In AdWords API, there were report types such as CAMPAINGN_PERFORMANCE_REPORT. The Google Ads API doesn’t have them; instead of report types, it consists of a vast number of resources;
  • AdWords API and Google Ads API have different API response formats;
  • there is no includeZeroImpressions parameter in Google Ads API; instead, you can use the metrics.impressions > 0 filter.

Migrating from RAdwords to rgoogleads

The former report types in Google AdWords have become resources in Google Ads. See the comparison table from the official help guide:

#> 
#> Attaching package: 'dplyr'
#> The following objects are masked from 'package:stats':
#> 
#>     filter, lag
#> The following objects are masked from 'package:base':
#> 
#>     intersect, setdiff, setequal, union

See the official help guide for the correspondence between the “Report” and the resource fields. The table is large, so there’s no need to duplicate it here.

See the example of requesting a campaign performance report with the same set of fields, using the RAdwords package and rgoogleads below.

The request of ad campaign performance report using RAdwords

library(RAdwords)

# auth
adwords_auth <- doAuth()

# create request
query <- statement(
  select = c('CampaignName',
            'Date',
            'Clicks'),
  report = 'CAMPAIGN_PERFORMANCE_REPORT',
  start  = '2021-06-01',
  end    = '2021-06-30'
)

# data import
data1 <- getData(
  clientCustomerId = 'xxx-xxx-xxxx',
  statement        = query, 
  google_auth      = adwords_auth
)

The request of ad campaign performance report using rgoogleads

library(rgoogleads)

# auth
gads_auth_configure(path = 'D:/ga_auth/app.json')
gads_auth(email = 'me@gmail.com')

# data import
data2 <- gads_get_report(
  resource = 'campaign',
  fields   = c('campaign.name',
              'segments.date',
              'metrics.clicks'),
  date_from         = '2021-06-01',
  date_to           = '2021-06-30',
  customer_id       = 'xxx-xxx-xxxx',
  login_customer_id = 'xxx-xxx-xxxx'
)