Steal This:
Google Data Studio Style Guide

Hey There!

It's Jordan, the shy half of the Agency Automators team, today I am going to be sharing the exact Google Data Studio style guide that I use at my own agency, Kogneta, to stay organized with multiple team members working on multiple reports.

Anyone that knows me, knows that I am a HUGE systems and process nerd and if it ain't documented, it didn't happen. After onboarding a few new team members, they started asking questions about reporting I had forehead slap moment realizing that it was never documented.

Thus the birth of the style guide that you'll find below.

As you go through this guide, I've included some additional notes for this article to help provide more context and insights into my decisions.

Without further adieu, let's dive right now!

---

Reports vs Dashboards

There is an important difference between reports and dashboards. Understanding this difference is crucial as it dictates the development of a Google Data Studio document.

Report - A report is provides the reader with a snapshot understanding of performance that INCLUDES a narrative component. Reports are also always provided in PDF format to clients and are typically sent out on a monthly or weekly basis.

The narrative component consists of two sections:

1. Analysis - Provides a narrative and context as to why and how the metrics changed over the time period of the report.
2. Recommendations - Based on the metrics outlined in the report, a set of actionable recommendations are provided as next steps to improve performance.

Dashboard - A dashboard provides the viewer with an understanding of performance in a live manner.

Dashboards are accessed directly through Google Data Studio rather than a PDF and are accessed at anytime to see live data.

Rules to Live By

Use Branding

Always following our branding guidelines as outlined in the branding section on Kogneta's knowledge base.

Follow Naming Conventions

Everything that is created should follow the naming conventions outlined in the Google Data Studio Naming Conventions section below.

Answer Questions

Every single piece of information provided whether it be a table, chart, graph, score card or anything else should answer a question on how a client's campaign is performing.

Include and outline Date Ranges

Always include a report level date picker across each report and dashboard you develop. If an element in the report or dashboard outputs data from a date range outside of the report-level date picker then it should be explicitly mentioned.

Follow The Pyramid Principle

Start with the biggest answer that your trying to answer with your report or dashboard first and the rest of it should provide supporting arguments for it.

Build For Multiple Clients

Every report and dashboard should be built with reusability in mind so that it can be used on multiple clients or projects with little to no alteration or customization.

Focus on Actionable Metrics

The report or dashboard should focus on actionable metrics rather than vanity metrics. An actionable metric is something that the reader sees and can take action on. A vanity metric is something that doesn't show how performance is actually doing.

An example of this is CPA (Cost Per Acquisition) and Impressions. CPA is an actionable metric while impressions is a vanity metric.

Account Ownership

All Google Data Studio reports must be created under the our team analytics account.

Google Data Studio Naming Conventions

In order to stay organized we use a specific naming convention across all of our clients when it comes to Google Data Studio reports.

Report Naming

When it comes to reports, we've developed a consistent naming convention. This ensures that everyone understands and knows how to find a client's report and its content. The following is our naming convention:

{{Client Name}} - {{Time Frame}} {{Channel}} Performance Report

Here are several examples of how the naming convention is used:

If Kogneta is the client and we're doing SEO for them:

Kogneta - Monthly SEO Performance Report

If Kogneta is the client and we're doing PPC for them and sending the report on a weekly basis, the name of the report would be:

Kogneta - Weekly PPC Performance Report

If we were doing an SEO & PPC campaign for Kogneta it is something that the client can check live, we would use Dashboard instead. Thus, the name of the Google Data Studio Report would be:

Kogneta - Performance Dashboard

Data Source Naming

With Google Data Studio source names, we use the following:

{{Client Name}} // {{Channel}} // {{View, Table or Other Child View}}

The double slash (//) is used to delineate pieces of information about the data source. Below are several examples of how the naming convention works:

Google Analytics

If Kogneta was the client for the report and we're trying to look at our *KG - Filtered view in Google Analytics, the data source would be named:

Kogneta // GA // KG - Filtered*

Google Ads

If we're tying to create a Google Data Studio report for Kogneta's Google ads account, the data source would be named:

Kogneta // GAds

Since Google Ads only has one report view, we exclude it from the Google Data Studio source name.

Facebook Ads

For a Facebook campaign where Kogneta is the client, the data source would be named:

Kogneta // FB Ads

BigQuery

BigQuery is a bit of a different beast since we aggregate clients data into the same datasets and tables. In that case we'd use ALL instead of a specific client name.

Here is an example of naming GSC data in BigQuery

Kogneta // BQ // RAW_gsc

Blend Naming

Since blends in Google Data Studio combine multiple data sources together the naming convention should do just that:

{{Data Source 1}} <> {{Data Source 2}} <> {{Data Source 3}}}

The greater than, less than (<>) operators delineate one data source from another. The sequence of the data sources should follow the sequence of the blend.

For example, if we are blending the Google Ads and Google Analytics data sources for Kogneta from the examples in the Data Source Naming section then the blend's name would be:

Kogneta // GAds <> Kogneta // GA // KG - Filtered*

If we were also combining the Facebook Ads data source the blend would be named:

Kogneta // GAds <> Kogneta // GA // KG - Filtered <> Kogneta // FB Ads*

Filter Naming

To name filters you include the data source and a description of the filter. The template for this would be:

{{Data Source}} — {{Filter Description}}

Below are several examples of how you would go about naming a filter:

Only organic traffic from Google Analytics:

Kogneta // GA // KG - Filtered -- Organic Traffic Only*

Only showing Google Ads keywords with a CPA higher than $50:

Kogneta // GAds -- KW CPA > $50

Only display BigQuery GSC data from Kogneta:

Kogneta // BQ // RAW_gsc -- Only Kogneta

---

...and there you have it! Keep in mind that all SOPs that you create it should be an ever evolving document that is continuously being refined based on feedback from team members on what is an isn't working.

Have a better way of doing things?

Have questions about what I shared?

The join the conversation on Twitter here!