Giving your editors statistical insights about their content

TL:DR The GA Summary module lets you display per page or user statistics. It defines an overall timespan and lets you pick which data to collect as aggregated data into Drupal. At the time of writing the module is still a sandbox - which means it is still subject to change before the version number settles.

The Workbench module is used for managing editor workflows. Each editor can get an overview of their own content; their drafts, what needs review etc. For one of our customers we needed to expand the Workbench with some statistical insight, so that all editors can get some idea of how well their content is doing - ie bounce rate, hits and other metrics from Google Analytics. The solution described here solves our use case, but can be used for anything where you would like to aggregate Google Analytics data and be able to match it to both users and nodes.

There are a number of Drupal modules that integrates with Google Analytics, but the one that we found to be most used and maintained is the Google Analytics Reports module and the accompanying Google Analytics Reports API module.

The API module integrates the Views module with Google Analytics. We needed to match the page results from Google with the current user in Drupal, and in order to do that efficiently, we had to save the data from Google Analytics in the database and expose it in Views. We ended up using the Google Analytics Reports API module for fetching data, but recreating the Views integration in a slightly different way, so that we could do the matching between the pagePath metric from Google Analytics and the current user.

How to use it:

Start by setting up the Google Analytics Reports configuration. See


An administrator with the permission “Administer GA Summary” should start by defining which data to aggregate from Google Analytics. This is done here: /admin/config/system/ga_summary.


You should start by setting up which dimensions and metrics to aggregate from Google Ananlytics here: /admin/config/system/ga_summary.

We have found that the easiest way to work with GA is to make a test report in the GA query explorer and then copy the values in the configuration form.

End date: How many days before NOW should the data collection stop. I guess usually you would have 1 or 0 here, so that the data collection will end on the current day or the day before.

Start date: The default is to fetch a months worth of data, but you could set this to whatever, as long as it it a bigger number than the end date.

Dimension: Pick the dimension you want to collect.

Metrics: You need at least one metric in order to fetch data from GA.

Setting up reports

Currently the module does not provide a default report, so in order to display anything to your editors, you need to setup a view. If you are planning on using this with the workbench module, and display the statistics for a users own content as a tab under the workbench; here is how to do it.

In Views UI (/admin/structure/views) add a new view, using the GA Summary data.

Create a new page for the view.

Billede 1

If you want to filter on the current user - which you probably do, if you are setting up a workbench integration. Set the current user as the filter criteria.

Billede 2


Expose the GA Summary Data Type and Value fields.

Billede 3

Add the GA Summary: Node as a relationship and add the Node Title as a field.

Billede 4

Set the format to Table and under settings set the grouping field Nr 1 to Nodes title.

Billede 5

Billede 6

Finally exclude the Content Title from display.

Billede 7

To set the View as a tab under workbench, click the No menu option, set it to Menu tab and give it a title. Click Apply.

Billede 8

Set the path to something under the workbench, fx admin/workbench/ga-summary-view

Billede 9

Optionally set the views access permission to View GA Summary.

If you have data from GA, you should now be able to see the data under the workbench.

Billede 9


The module is still a sandbox, and will be subject to some changes in the future. Particularly I would like the view to display a bit nicer; one line per page, where the data type acts as column headers.