What Google Analytics and How to use it (2019)

What is the Google Analytics and How to use Google Analytics 2018

What is Google Analytics and How to use Google Analytics 2018

Google Analytics uses JavaScript tracking code to track users’ activity on a website. The analytics.js tracking library is included on each page of the site along with a create command (to set up the Google Analytics tracker) and a send command (to send page view data to GA).


Google Analytics uses a first-party cookie named _ga to store a client ID to identify a browser and device. With multiple subdomains or domains, there are options to specify the domain for the cookie. With multiple domains, Google Analytics provides cross-domain tracking to share client IDs between sites with different cookies via a parameter in links between the domains. The linker plugin provides the functionality to decorate links with this parameter.


Google Analytics (GA) is an easy-to-use tool to measure activity on a website. A basic setup might take as little as a few minutes, and many of the standard reports are quite accessible and understandable without any special training or prior knowledge of web analytics.


Because of this, many users jump into Google Analytics without knowing much about its underpinnings—how the data is structured and gathered—and that’s fine for the basics. But eventually, users can outgrow this intuitive understanding of Google Analytics and its data, and need deeper insight into how it works and what it can do.


You may already be using Google Analytics, or just starting out. In either case, this blog will help you get a handle on what’s in Google Analytics:


  • How Google Analytics accounts are structured
  • How your data gets into Google Analytics
  • How reports are generated from that data
  • Google Analytics Account Structure and Administration


If you’re just creating your Google Analytics account from scratch, either because you are starting a new website or switching from another tool, congratulations! You have the opportunity to set everything up from the beginning.


On the other hand, if you’re like most users of Google Analytics, you’re inheriting some accounts that already exist, set up at some point in the dim past. There may or may not be any record, documentation, or organizational memory of what was set up and why.


To make sense of all this, let’s take a look at the structure of Google Analytics accounts, starting with the email address you use to log in.


Getting a Google Login

 Google Login

Whether starting from scratch or accessing an existing implementation of Google Analytics, you will need a way to log in. For Google Analytics (and all other Google-y tools, such as Tag Manager, AdWords, Search Console, Google+, and so on), this requires that you have a Google Account.


If you sign up for an email address through Gmail, that’s automatically a Google Account. But you can sign up any email address (alice@thesisscientist.com, for example) as a Google Account. Look no further than the “Sign in” option at the top right of pretty much anything Google, which will allow you to sign in with an existing account or create a new one.


It will ask you a few security questions and allow you to choose a username for a new Gmail address or to use an existing email address.


Tip  You’re better off using company email addresses than Gmail addresses for official business using Google tools since you have more control over your own email addresses (being able to reset the password with email verification if someone leaves your organization, for example).


 You’ll want anyone who needs a login to your organization’s data and settings in Google Analytics (and later, Google Tag Manager) to create an account this way. You can have many different logins, with different levels of access to your Google Analytics data.


Tip   You might wonder: “Should we share a single login?” Whether you want a shared login (e.g., analytics@thesisscientist.com) or separate logins for different personnel (e.g., alice@ thesisscientist.com, lewis@thesisscientist.com, etc.) depends on the structure of your organization’s departments, business units, or teams, as well as your internal security policies.


Think about whether multiple people sharing a password works. (For small organizations, maybe. For larger organizations, you’re going to want more granularity, control, and accountability for individuals.)


Google Analytics Structure

Google Analytics Structure

Google Analytics organizes data into a three-level hierarchy: accounts, properties, and views. Each login (email address) can have access at any of these levels.


The account is the highest level and generally corresponds to a single business or organization. In many cases, you may have access to just one Google Analytics account. But you might have multiple accounts for various reasons: you have a work account (for your employer’s websites) and a personal account (for your blog on trends in the millinery industry);


you might be an agency that works with multiple clients, each of whom has an account; or you might work for a large and complex organization that has multiple accounts (the North American division vs. the European division).


The property is the next level of organization. Each account may have multiple properties. The property corresponds to a website (or group of websites), mobile app, or other sources of data. Your organization might have multiple websites (thesisscientist.com, madhatterheadwareinc.com, etc.), and so your account might contain multiple web properties.


The view is the third and lowest level of the organization. Each view is a specific set of data from the property from which the reports in Google Analytics are generated. By default, Google Analytics creates a view for each property that simply contains all the data for that property.


You get to specify what data are included in each view, so you can create additional views for subsets of your site’s content (just a particular section of the site, or just a particular marketing channel, for example).


On the Home tab for Google Analytics, you’ll see a hierarchical listing of all the accounts, properties, and views to which your login has access, through which you can browse by collapsing and expanding the sections. Each view shows a short summary of metrics, and clicking on a view takes you to its reports.


Administration and Access Controls

Administration and Access Controls

The Admin tab of Google Analytics gives you access to all of GA’s settings, and you’ll find that it’s organized in the same way, by account, property, and view (from left to right). Each of the three columns is a menu of settings for that level, and the drop-down menus at the top of each column control which account, property, or view you’re seeing.


What you’ll see in the Admin tab depends on which level of permissions your login has to Google Analytics. There are several levels of permissions that can be assigned to a login:


  • Read & Analyze is the most basic level of permissions. This allows a user to view reporting data and create personal customizations, such as custom reports, alerts, dashboards, or segments.


  • Collaborate is the next level. It includes everything that Read & Analyze can do, as well as the ability to share customizations with other users.


  • Edit includes everything that Collaborate can do, with the addition of the ability to change settings in the Admin area.


  • Manage Users is a separate permissions level from reading & Analyze, Collaborate, or Edit, and does not include those abilities (though it can be given in addition to them for a user). Manage Users gives the ability to add or remove permissions for other logins.


These permissions can be assigned to the account, property, or view level, which gives great flexibility. For example, Alice might be in charge of analytics across all company websites, so she could have Edit and Manage Users access at the account level. The Mad Hatter, who manages the e-commerce store portion of the website, may have Edit permissions to only that view.


If you have the Manage Users permission, you’ll be able to see a Manage Users menu listed in the Admin tab. Clicking through shows a list of users and their permissions, as well as the ability to add a new user. Note that the login email needs to be a Google Account (see earlier) before you can add it to Google Analytics.


Tip  Most commonly, you will probably use Collaborate permissions for the majority of users, at whatever account, property, or view is appropriate for them to use. Typically Edit and Manage Users are reserved for a limited number of administrators (again, at the account, property, or view level that’s appropriate).


Further blogs explore the other settings in the Admin area. The property-level settings largely pertain to what data is collected by Google Analytics: the tracking code itself, customs data, and data import. The view-level settings control what data shows up in reports, and you’ll learn ways to use those to track conversions and clean up and organize your data.


Google Analytics Premium Properties

Google Analytics

Google Analytics is a free tool. People often ask, “Why does Google give it away for free?” Organizations with better data about their websites and marketing are more likely to spend money on advertising, which is where Google brings in the money.


As a free tool, however, it does have some limitations on how much data you can collect and process. Google also offers Google Analytics Premium, which is a paid subscription service that includes higher limits on data collection and processing, service-level and uptime guarantees, and customer support and training.


 Google Analytics Premium also offers some more processing-intensive reports and ways of retrieving data beyond what’s available in the free tool, as well as early access to beta features.


Google Analytics Premium is activated at the property level in Google Analytics, and you’ll see a flag next to any properties in your account list that are enabled for Google Analytics Premium.


Most of the features discussed in this blog are available for everyone—Premium or standard. Differences will be called out so you’ll know.


How Google Analytics Collects Data

How Google Analytics Collects Data

Google Analytics captures a wide variety of data. Data is sent to Google Analytics by means of a tracking hit. Each hit is a bundle of data about some specific type of interaction (viewing a page, for example).


Google Analytics specifies the format for this hit data with a data collection specification called the Measurement Protocol. The Measurement Protocol is agnostic about the source of the data—as long as the hit is in the right format, the data will be collected into Google Analytics. This means that you can send data to Google Analytics from anywhere: a website, a mobile app on iOS or Android, or from your own custom applications. 


In most cases, you’ll be sending data to Google Analytics from your website, and that’s the focus of the bulk of this blog. For websites, Google Analytics provides a JavaScript library that generates the tracking hits for you and automates much of the nitty-gritty of the data collection so that you don’t have to worry about the details of the Measurement Protocol.


This JavaScript code is loaded in each page of your website. By default, this code captures the view of each page (and a slew of associated data) each time a page loads. By adding more code, you can track other interactions or occurrences, such as clicking a button, scrolling the page, and more.


For standard (non-Premium) Google Analytics, you are limited to collecting ten million tracking hits per month by the terms of service. If you exceed that limit, Google may contact you about purchasing a Google Analytics Premium subscription or reducing the amount of data you collect. (Premium accounts have higher hit limits, starting at one billion hits per month.)



Hits, Sessions, and Users

Hits, Sessions, and Users

Each hit sent to Google Analytics represents one interaction. A collection of hits that occur together is called a session. For example, a user might come to your website and view several pages in succession—each page generates a hit, and all of the hits together comprise the session. The typical rule for grouping hits into sessions is that not more than 30 minutes pass until the next hit (although you have the ability to change this time window in the Google Analytics settings).


Example  Alice visits a website and goes to pages A, B, and C. Then she follows a rabbit down a hole and returns an hour later, viewing pages D and E. Alice has two sessions: the first containing A, B, and C, and the second containing D and E. If only 29 minutes had passed between C and D, there would be a single session with all five pages.


Google Analytics also tracks the user, who may have multiple sessions. When the same user comes back to the site repeatedly, Google Analytics keeps track of how many times they’ve been there and how recently.


Privacy Considerations

Of course, you are interested in tracking user activity to make your website better. But you have to remember that the users visiting your website are real human beings, not just a collection of data, and you need to be clear about what you’re collecting and careful about what you do with it.

Google Analytics’ Terms of Service for the United States1 require the following:


  • That you disclose that you are using Google Analytics to track the behavior of your website users (typically by linking to Google’s description of how it collects data in your site’s privacy policy).


  • That you must not circumvent any methods that Google Analytics allows users to opt out of tracking.


  • That you must not collect any personally identifiable information within Google Analytics (names, email addresses, or billing information).
  • The terms for other regions may be different, and you should also become familiar with the privacy regulations in the countries in which you operate to understand your obligations.



Reports and Data Structures in Google Analytics

Reports and Data Structures in Google Analytics

Once the data is sent to Google Analytics, it will appear in all of the standard reports you can access in the Reports tab (or in Custom Reports in the Customization tab, if you’ve created any of those). Let’s take a look at how this data is organized into those reports and how the numbers are calculated.


Dimensions and Metrics

Dimensions and metrics are the building blocks of every report in Google Analytics, and understanding the dimensions and metrics available and how they fit together will give you a deep understanding of how Google Analytics really works, and what you can do with the data.


Dimensions are labels that describe data. They typically appear as the rows of reports. Examples include:

  • URLs: Hostname, Page, Landing Page, Exit Page, Previous Page, Next Page
  • Traffic sources: Source, Medium, Campaign, Keyword, Referral Path, Social Network
  • Geography: Country, Region, City, Metro


Metrics are measurements. They are always numerical and typically appear as the columns of reports.

  • Examples include:
  • User metrics: Users, % New Sessions
  • Session behavior metrics: Bounce Rate, Pages/Session, Avg. Session Duration, Conversion Rate
  • Campaign metrics: Impressions, Clicks, CTR, CPC


Each report in GA—whether a standard report, a custom report or even data extracted through the Google Analytics APIs—is a combination of dimensions and metrics that are extracted and calculated from the tracking hits received. Most standard reports have some sensible defaults, but allow you choices to show the data in different ways by changing the dimensions or metrics displayed.


Custom reports allow you to select completely customized combinations of dimensions and metrics. Reports also allow filtering and segmentation of data based on dimensions and metrics. For example, you can say “Show me all the Pages with Bounce Rate greater than 50%” or “Show me the Campaigns only for users located in Florida”.


You’ll get a sense for the dimensions and metrics available simply by browsing through the standard reports in Google Analytics. A comprehensive reference to dimensions and metrics is available in the Google Analytics developer documentation,2 which includes the labels used in the reporting interface as well as the programmatic identifiers used in the APIs.


The dimensions and metrics reference also indicates which combinations are allowed—certain dimensions or metrics cannot be viewed in the same report, either because they are logically incompatible or because the underlying data on such a combination isn’t available in Google Analytics.


Pre-Aggregation and Sampling

Google Analytics

For the combinations of dimensions and metrics in most of the standard reports, all of the report data is pre-aggregated by Google Analytics. This means that the metrics in these reports are calculated and ready to go when you request the report for any date range.


Row Limits

For this pre-aggregated data, there is a limit of 50,000 unique rows daily that are shown in the aggregated reports. Once you exceed this limit, the report will group additional values into a single row labeled (other). This is uncommon for most dimensions, but for dimensions like Page (URL) or Keyword, there may be large numbers of unique values. (Additional limits apply in multiday or multidimensional reports, but exceeding the daily limit is the most common scenario.


The limits are higher for Google Analytics Premium users.) You may be able to overcome these limits by cleaning up unnecessarily specific query parameters or other information in your URLs.



If you request a report that is not drawn from GA’s pre-aggregated data—for example, by applying an additional dimension to a standard report, applying a segment, or creating a custom report—GA must calculate the metrics for the report on the fly by going back to the original tracking hit data.


For non-aggregated data, if the date range contains more than 500,000 visits, Google Analytics will employ sampling in calculating the metrics for the report. (Again, additional limits sometimes apply, but the session limit is the most common to trigger sampling. The limits are increased substantially for Google Analytics Premium users, who also have the ability to download completely unsampled reports.)


Sampling means that the totals are projected from a subset of the data. For example, if there were 1,000,000 sessions in your time period, Google Analytics might take 500,000 sessions to calculate the metrics, then multiply by 2 (1,000,000 / 500,000) for the totals.


Google Analytics will indicate when sampling occurred and what proportion of total traffic was used in calculating the report by a notification at the top right of the report. It also gives you the ability to select between “Slower response, greater precision” (which uses close to the limit of 500,000 sessions but takes longer to calculate the report) or “Faster response, less precision” (which is quicker but uses fewer sessions).


You can eliminate sampling if you can reduce the date range of your report to encompass fewer than 500,000 sessions. (In this scenario, you would have to add results back together for multiple dates ranges to get totals for the entire time period of interest. You can also use the Google Analytics APIs to apply this technique programmatically.) However, this approach makes analysis in GA’s reports cumbersome, and it does not make it possible to address user-level metrics (which cannot be simply totaled across time periods).


Tool Overlap and Reconciliation

If you’re like most folks, you’re using multiple tools for measuring web activity, and more than likely, some of those overlap with what Google Analytics is also measuring. Your content management system, social media plugins, e-commerce system, email marketing tools, and more may all have metrics about web activity.


To the extent possible, it’s worth trying to consolidate as much as possible in a single system that is flexible enough to handle most of the data that’s most important to you, for the simple ability to see and analyze all these data side-by-side without having to stitch them together in some other way.


 Google Analytics is a good candidate for bringing together as much of your online (and even offline) customer interaction as possible because of its flexibility. Much of this blog will focus on bringing these different categories of data together. However, collecting data in Google Analytics may not be practical for you in all cases, so there are many facilities for exporting data as well.


Where you are using Google Analytics data alongside data from other sources, you should be aware that metrics will not always match exactly. This can happen for a whole variety of reasons. Metrics that seem like they should be the same are often defined in subtly different ways between tools or are measured in different ways.


Compare carefully, and don’t assume that numbers between different tools are comparable unless you understand their definitions clearly and do some cross-checking of your own. Overall, though, you should expect metrics to agree directionally and proportionally between tools, and you shouldn’t get bogged down in the minutiae of reconciling tools when you could better spend your time making decisions based on data that is good enough.


Google Analytics Documentation

Google Analytics Documentation

Even with this excellent blog in hand, you’ll probably need to reference the documentation for Google Analytics at some point. There are actually two major documentation collections for Google Analytics:


The Help Center, accessible from the top menu, provides information about the reporting and administration functions in Google Analytics. If there’s a report or setting you don’t quite understand, it should give you some context on what it’s for and how it works.


The Developer Center has all the documentation of the Google Analytics JavaScript tracking codes, APIs, and other technical information about Google Analytics. It makes a great supplement to this blog, and some of its reference documentation and handy tools will be referred to for further background.


Basic Google Analytics Measurement

Google Analytics

Google Analytics’ measurement of your website is based on the JavaScript tracking code installed on the site. Although for most of this blog we’ll be using Google Tag Manager (GTM) to manage and install this code, it’s instructive to understand the basics of the Google Analytics tracking code and how it is intended to work.


Practically speaking, you probably won’t use this tracking code directly. However, having a basic understanding of it will help you to interpret the options in Google Analytics tags within Google Tag Manager, as well as to decipher Google Analytics documentation and examples to set up Google Tag Manager for your site.


Basic Google Analytics Tracking Code

When you first create a Google Analytics account, you supply some basic information, such as your site’s domain and time zone. Then, Google Analytics presents a snippet of JavaScript code with the instruction to “copy and paste this code into every web page you want to track”.


If you need to find this suggested code after the initial setup process, you can find it in the Admin settings in the Property column in the section Tracking Info ➤ Tracking Code.


How the Tracking Code Works

How the Tracking Code Works

Let’s break this code down and take a look at what it does. The first part looks like this:


(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){ (i[r].q=i[r].q||[]).push(arguments)},

i[r].l=1*new Date();a=s.createElement(o), m=s.getElementsByTagName(o)[0];a.async=1;a.class='lazy' data-src=g;m.parentNode.insertBefore(a,m) })

(window,document,'script','//www.google-analytics.com/analytics.js','Google Analytics');


Don’t even bother reformatting this piece of code to make it more readable, because it’s the same for every site and you would almost never make changes to it. It fetches the Google Analytics tracking library (analytics.js) from a Google server and inserts it into the page. (The only part of this script you would possibly want to change is the very last bit: 'Google Analytics' is the name that will be given to the Google Analytics tracking function. 


You can rename this function should you need to avoid a conflict with the name of an already existing object in your page.)

The second part is where you tell Google Analytics what to do. The default code includes two commands:

  • ga(create', 'UA-XXXXX-YY', 'auto');
  • ga('send', 'pageview');


The Google Analytics function accepts a sequence of parameters, the first of which is the name of a Google Analytics command.

Here you see two different commands: create and send.


Create the Google Analytics Tracker

The create command sets up the Google Analytics tracker. Each tracker sends data to a specific Google Analytics property, which is identified in the second parameter in this command, called the property ID.


The property ID is of the form UA-XXXXX-YY, where XXXXX is a number that identifies your Google Analytics account, and YY is a number that identifies a property within the account. You can find the property ID listed next to each property in the Home screen of Google Analytics, or in the Admin settings in the Property column.


The last parameter, auto, is a configuration parameter for the tracker that relates to how it sets cookies for the site. 


Send the Pageview

Send the Pageview

The second command, send, sends a tracking hit to Google Analytics.

The second parameter of this command is the hit type, which in this case is pageview. There are a number of different hit types, which collect different kinds of data and are reported in different ways in Google Analytics, such as the event hit type for user interactions or the screen view hit type for mobile applications.


Whenever a send command occurs, data is sent to Google Analytics. An HTTP request is generated to www.google-analytics.com/collect that includes a payload of data about the hit (the data from which the dimensions and metrics in Google Analytics will be populated).


Because the Google Analytics tracking code is included on every page of your site, each time a page loads, the command to send a pageview executes, recording that the page was viewed. It’s that simple. The two commands represented here (create to create the tracker, send to send the pageview) are the bare-bones minimum for Google Analytics tracking to function on your site.


Now, this default code doesn’t capture everything you might want—it’s just recording pageviews each time a page loads. So what about an AJAX form, where the user completes several steps but the page doesn’t reload? What about other interactions within pages, like playing an embedded video? These are going to require additional code (to execute only when some action is completed, like loading new AJAX content or playing the video).


Google Analytics Tracking code

This blog focuses on the latest generation Google Analytics tracking library, analytics.js, which is part of GA’s suite of upgrades and expanded features called Universal Analytics. There are other, older Google Analytics tracking libraries, such as urchin.js and Google Analytics.js. These worked in similar ways, but the specifics of syntax are different, and not all features described in this blog are available with older libraries.


The analytics.js library has been the default code for new properties in Google Analytics since 2014, and an upgrade process is available for properties that predate the change. You will see a notification about the upgrade process in the Admin section if you haven’t updated (and you’ll be able to see the older code on your site).


Although the older code will continue to work and gather data for some period of time, if you want to take advantage of any of the newer features of Google Analytics, you will want to upgrade as soon as possible (and eventually it will become mandatory).


The Google Analytics Developer Center contains documentation for the legacy code and an upgrade center to guide you through the process.1


Multiple Google Analytics Trackers

One last important detail about creating a Google Analytics tracker: every tracker has a name that identifies it. (The default tracker’s name is actually t0, although that’s not indicated anywhere.) The name of the tracker is nothing to worry about if you’re only using one, but in some cases, you might have multiple trackers running in parallel on a web page.


If there are multiple trackers, each command must specify which tracker it is being called on. (It’s not necessary to specify the name for the default tracker t0, however.)


Why might you want multiple trackers? In some cases, you might want to send data to more than one property in Google Analytics, which can happen for many reasons:


A joint interest in a website by two distinct parties (your organization and its parent company, for example) with different Google Analytics accounts.


Adding your tracking code to content provided by a third-party vendor or app that may have its own Google Analytics tracking already in place.


In some situations, for testing upgrades to ensure your implementation is correct. Here’s an example of naming a tracker and then calling a command on it. The name can be any string; here you use t1.

ga('create', 'UA-XXXXX-YY', 'auto'); // default tracker

ga('create', 'UA-WWWWW-ZZ', 'auto', 't1'); // additional tracker named t1

    ga('send', 'pageview'); // sends pageview for default tracker

ga('t1.send', 'pageview'); // send pageview for t1


The commands for named trackers are prefixed with the tracker name before the command name, separated by a dot: t1.send, for example.


Arguments and Field Names

Depending on the command, Google Analytics accepts values for additional fields that affect how it works or the data gathered. As you saw earlier, for example, the create command indicates the property ID, for example.


In many cases, there are two ways you can specify these values. For some, you can specify them as arguments directly in the Google Analytics function call: ga(create', 'UA-XXXXX-YY', 'auto');


This is the format you’ve already seen, and it is a convenient way to provide some of the most common field values. Since it uses function arguments, notice that the order is important, and the function expects the arguments to occur in a particular position.


There’s an alternative syntax available as well, and it’s the only way to specify some of the lesser-used fields, which do not have a parameter equivalent. This alternative syntax uses an object for the fields and values:

  • ga('create',
  • { 'trackingId': 'UA-XXXX-Y', 'cookieDomain': 'auto' });

Since the object includes the name for each field, the order doesn’t matter. Both of these syntaxes are equivalent and work in the same way.


Getting the Code on the Page

Getting the Code on the Page

So the instructions say “copy and paste this code into every web page you want to track,” but fortunately that’s probably easier than it sounds. In this era, chances are that you have a content management system with some manageable number of page templates (rather than individual, distinct HTML files for each page of the site).


If that’s the case, you just need to get the code into one or more templates so that it’s automatically included in each page of the site. You do want to make sure that you get all the templates because any missing pages will not be measured in Google Analytics. As far as Google Analytics is concerned, if there’s no tracking code on the page, it’s as if it doesn’t exist.


Code Placement

The Google Analytics tracking code is asynchronous, meaning that the browser doesn’t need to wait for the code to finish loading to continue rendering elements that come after it on the page. This means that you can safely put the code at or near the top of your pages. The recommendation is to put the code in the <head> section of the page, although the beginning of the <body> is fine as well if that is easier in your templates.


Tip  You do want to try to include the code as high on the page as possible. If the code is toward the end of the page and the page takes a significant amount of time to load, it's possible that the user could navigate away (click a link or close the browser window) before the tracking code has loaded, meaning you would miss capturing data about that pageview.


The Google Analytics code executes asynchronously from the rest of the page, but the commands provided to Google Analytics execute in the order they are called. Because of this, it’s important for the create command to come before the send command, for example.


Cookies and Domains

Google Analytics employs a cookie to store a client ID, a randomly generated identifier for a particular browser and device. It uses the client ID in its calculation of the number of users and in user behavior across sessions (such as recency, loyalty, and the multichannel funnel reports).


Your browser stores cookies assigned to a particular domain (for security reasons, so that unauthorized sites can’t read cookies from other domains). Google Analytics uses first-party cookies, meaning that its cookie, named _ga, is assigned to your domain. That is, if I have Google Analytics tracking code on thesisscientist.com, I have a _ga cookie for that site (not for google.com or google-analytics.com, for example, which would be a third-party cookie).


In many cases, GA’s use of cookies is pretty invisible to you, and if you have only a single domain or several domains that are all separate sites, it isn’t something you need to worry about. However, if you have multiple domains or subdomains that operate as a single website, you may need to specify where the cookie is set and how domains share the client ID value.


Choosing a Cookie Domain

Google Analytics uses some default rules to decide the cookie domain, or you can explicitly specify which domain you’d like to use. There are three possible cases for the cookie domain:


Default: ga(create', 'UA-XXXXX-YY')


Google Analytics uses the full domain shown in the hostname of the URL, except that it ignores a www. prefix, if any. If subdomains of your main domain should be treated separately, this is the desired option.


Automatic Configuration: ga('create', 'UA-XXXXX-YY', 'auto')


Google Analytics uses the highest-level domain possible from the hostname of the URL. This is the suggested code when first installing Google Analytics. If subdomains of your main domain should be treated together, this is the desired option.

Manual Configuration: ga('create', 'UA-XXXXX-YY', 'store.thesisscientist.com')


Google Analytics uses the domain you specify. The domain must be an ancestor of the domain in the hostname of the URL.


Note  The create command can accept the cookie domain as the third argument, or you can use the field object. The following are equivalent:


  • ga('create', 'UA-XXXXX-YY', 'store.thesisscientist.com');
  • ga('create', 'UA-XXXXX-YY', { 'cookieDomain': 'store.thesisscientist.com' });


In most cases, you want to treat multiple subdomains (such as www and store) as a single site, with a single set of cookies, which the auto option does. If you wanted to treat subdomains as separate sites, you would want to specify the domains manually with separate cookies for each.



The default Google Analytics cookie is named _ga. Should you need to rename this cookie to prevent conflicts, you can do so with an additional field in your create command:


ga(create', 'UA-XXXXX-YY', { 'cookieName': 'my_ga_cookie' });


It's also possible to use Google Analytics without any cookies at all. To do so, you must supply the Client ID from your own source to identify the device. This option can be useful for syndicated content where you want to avoid first-party cookies or use a third-party cookie, or supply data from an application on a shared kiosk—for example:


ga('create', 'UA-XXXXX-YY', { 'storage': 'none', 'clientId': '5aced0c9-1d2f-4da0-bbdf-5775d8ff7ad7' });


The client should be a universally unique identifier following the format of UUID Version 4.2


Multiple Domains As One Site

Google Analytics

Sometimes, you need to treat multiple domains as a single site. This is most common with sites with third-party components, such as a shopping cart, donation site, or other application where some functionality is on a different domain. For example, your site might be thesisscientist.com, but to blog a hotel stay, users end up on thesisscientist.com.example.biz instead, a third-party site.


If the regular Google Analytics tracking code were used on such a site, there would be a separate _ga cookie for thesisscientist.com and thesisscientist.com.example.biz. Since each site would have a different set of client IDs, Google Analytics won’t connect behavior on one site with the other—for example, did someone who viewed a particular page on your site end up booking a hotel room on the third-party site? That’s a question you would probably want to be able to answer, but to do so, you will have to coordinate the client IDs between the two sites.


This is known as cross-domain tracking in Google Analytics. Google Analytics provides some functions to append a special parameter to the links or forms that take a user from one site to another that contains the client ID so that the receiving site uses the same client ID. The links look like this: http://thesisscientist.com.example.biz/hotelbooking.php?_ga=1.1821195.1441315.1362115890410


The linker parameter _ga contains the client ID for the receiving site. Let’s take a look at how to set this up.


Enabling Cross-Domain Tracking

First, in each site’s create command, you have to turn on the cross-domain linker function:

ga('create', 'UA-XXXXX-YY', 'auto', {'allowLinker': true});


When allowLinker is set to true, Google Analytics will look in the URL of the page for the linker parameter containing the client ID. If it’s present, it will use that value, rather than generating a new client ID for the cookie.


Note  The cross-domain linker parameter also includes a timestamp, and the client ID will only be used by Google Analytics if the timestamp is within the last two minutes. This helps prevent a user from accidentally sharing a link with a linker parameter and causing multiple users to share the same client ID.


Decorating Links

Next, you have to append the linker parameter to links on either site that go to the other. This is known as “decorating” the links—like hanging a little ornament on the end. Google Analytics provides several utility functions to do this in a plugin called linker.


The simplest option is to use the autoLink command, which allows you to specify a list or pattern of domains to be included and automatically decorates links that appear on your web pages.


ga('require', 'linker');

ga('linker:autoLink', ['thesisscientist.com', 'example.biz']);


The first line loads the linker plugin. The second calls the autolink command and supplies an array of domains for which you want links to be decorated. The domain list uses a substring match against the destination of the link—notice you can list example.biz or thesisscientist.com.example.biz, depending on how specific you want to be.


Tip   Instead of a list of strings, you can also use a regular expression to match domains:

ga('linker:autoLink', [/^thesisscientist.com(resorts\.com|\.example\.biz)$/]);


The autoLink command works well for automatically decorating links on most websites. Some pages may include scripts that prevent auto-linking from functioning, so as with any JavaScript, you should test thoroughly before deploying on your site. If auto-linking doesn’t work for your site, the linker plugin also provides a function linker: decorate for manually decorating your links. This function is useful in a number of situations aside from standard links:


  • Decorating an HTML form that posts from one site to another.
  • Decorating the destination of an iFrame of one site’s content within the other.
  • Decorating links if the autoLink function doesn’t play nicely with existing scripts on your site.
  • Specific examples of these cases are available in the Google Analytics Developer Center.


Introducing Google Tag Manager

Google Analytics

The basic Google Analytics code isn’t very complicated. Put it in your template and you’re all set. Except… Well, there are still a bunch of blogs left in this blog with additional types of data you might want to track with Google Analytics, many of which involve adding more code. A little piece here for PDF tracking, another little bit over there to track user logins, and so on.


The more code you add, the harder it becomes to keep track of all the little pieces, and which of those pieces should be included and under what circumstances, and what happens when you make a change.


And that’s just Google Analytics. Chances are, you also have other little bits of JavaScript on your site for other tracking tools that capture other kinds of data that are useful—maybe other Google tools like conversion and remarketing tags for AdWords or DoubleClick, or maybe for third-party ad platforms and analytics tools.


Sometimes you might have to measure the same page view or click for two, or three, or four different tools to serve different purposes, and each one takes a JavaScript tag.


If all of that sounds like it could get a little messy, it’s because it can. That’s where a tag management tool steps in to organize and standardize all those tags.


Why Use a Tag Manager?

Just like your content management system manages the content of your website—by allowing you to insert text, headings, and images in a web-based interface—a tag management system manages the tags—allowing you to insert those bits of JavaScript, such as the Google Analytics tracking code. It offers a web-based interface to choose, edit, and manage those tags when they are included in your web pages.


This approach offers a number of advantages:

  • There’s no need to make changes to the actual source code of the site or its templates when updating or adding tags.
  • You can keep track of and organize tags to avoid duplication and mistakes.
  • There are built-in debugging, testing, and preview tools.
  • You can use version control to keep track of changes.


There are multiple levels of permissions to view, edit, and publish tags.

Tag management tools separate the process of adding and updating tracking tags from the process of altering your site’s templates and code. There are a number of good tag management tools available, but this blog focuses on Google Tag Manager (GTM), since it’s a free tool that works very well with Google Analytics. (And if you’re a Google Analytics Premium subscriber, Google Tag Manager is also covered by the service-level agreement for Google Analytics Premium.)


How Does Google Tag Manager Work?

Google Analytics work

Google Tag Manager has two components that work together to include tags on your website:

  • A web-based interface to set up tracking tags to be included on your site.
  • A container script that is placed in your site’s template that loads the tags. Let’s take a look at each of these pieces to get your Google Tag Manager account set up.


Creating a Google Tag Manager Account

Since Google Tag Manager is another Google tool, you can use the same Google Account login you use for Google Analytics. You can be granted access to a previously existing Google Tag Manager account or you can create a brand-new one. Just like Google Analytics, your login can have access to multiple Google Tag Manager accounts.


Google Tag Manager Account Structure

Google Tag Manager accounts are organized into containers. Each container corresponds to a container script (see the upcoming “GTM Container Script” section) that is included on a website using Google Tag Manager.


When you sign up for a Google Tag Manager account, it creates your first container, and you are able to create additional containers as needed. Google Tag Manager shows an overview of your accounts and containers when you log in.


In some ways, it seems that there is an obvious parallel between accounts and properties in Google Analytics and accounts and containers in Google Tag Manager. At the account level, this analogy holds up well: an account usually represents a single organization or business, in either tool.


The Google Tag Manager container can be a somewhat broader concept than the Google Analytics property, however. For example, while you might have separate Google Analytics properties for your development, test, and production websites, you might have a single Google Tag Manager container to manage the tags across those sites, since you want very similar tags deployed across all of them.


A general rule of thumb for Google Tag Manager containers is that if the tags are mostly the same across websites, use a single container. If they differ greatly between websites, separate containers might be more appropriate. (You’ll see more of how these tags are set up over the next several blogs, so you may want to get a feel for how tags work in Google Tag Manager before you make a final decision about how to structure your account.)


Google Tag Manager Permissions

Just as in Google Analytics, logins in Google Tag Manager can have different levels of permission at the account and container levels that give them different abilities. You can assign permissions in the User Management section of GTM’s Admin area.


  • At the account level, there are two different levels of permissions:
  • View allows the user to see the list of users and the account settings, but not to make any changes.
  • Manage allows the user to add and remove other users and to edit the account settings.
  • At the container level, there are more detailed permissions:


  • View Only allows the user to view the tags in the container, but not to make any changes.
  • View and Edit allow the user to make changes to the tags in the container.
  • View, Edit, Delete, and Publish allows the user to make changes to tags, delete them, and publish them to the live website.


Changes to your website don’t take effect until they are published in Google Tag Manager. By managing the container permissions, you can ensure that only the users who should be able to change tags or publish them to your website are able to. (The next blog will take a look in greater detail at the publishing process in Google Tag Manager.)


Note  The Google Tag Manager account settings additionally enable you to require two-step authentication for certain activities, such as modifying permissions or editing custom tags. Two-step authentication is an additional security measure for Google Account logins that sends a verification code to a phone or other device to verify the user’s identity.


Google Tag Manager Container Script

Google Analytics script

In order to include tags on your website, you have to add the Google Tag Manager container script. On the surface, the Google Tag Manager container script is just another snippet of code you’re adding to your website templates (just like Google Analytics or any other tracking code).


But the Google Tag Manager container script is meant to replace all those other bits of code as a single script that you won’t need to update on your site; all updates will be made through Google Tag Manager.


When you first create a container, Google Tag Manager will provide you with the container script and instructions. Or, you can find the container script by selecting the Admin tab at the top and choosing Install Google Tag Manager in the right-hand column.


The Google Tag Manager container script looks something like this:


<!-- Google Tag Manager -->

<noscript><iframe class='lazy' data-src="//www.googletagmanager.com/ns.html?id=GTM-XXXXXX" height="0" width="0" style="display:none;visibility:hidden"></iframe></noscript> <script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'Google Tag Manager.start':

new Date().getTime(),event:'Google Tag Manager.js'});var f=d.getElementsByTagName(s)[0],

j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.class='lazy' data-src=



<!-- End Google Tag Manager -->



This code contains your Google Tag Manager container ID, which is an identifier of the form GTM-XXXXXX that uniquely identifies your container. This code loads a script called Google Tag Manager.js, which includes all the tags you have set up in Google Tag Manager.


Like the Google Analytics tracking script, the Google Tag Manager script is asynchronous, so it should be placed as high in the page as possible. However, note that the Google Tag Manager code contains two parts: a <noscript> tag and a <script> tag. The <noscript> portion allows Google Tag Manager to include some types of tags even if JavaScript is not enabled in the client browser.


These tags are included in an <iframe> element, which means that the Google Tag Manager code must go in the body of the web page (iframe elements are not officially supported in the head section). Because of this, the recommendation for the location of the Google Tag Manager code is at the beginning of the body, immediately after the opening <body> tag.


Once the Google Tag Manager container code is included on your website, tags can be added and published through the Google Tag Manager web interface.


The Building Blocks of Google Tag Manager

The Building Blocks of Google Tag Manager


Once you’ve created a container, you’ll see it listed in GTM’s list of accounts and containers. Selecting a container takes you to the container overview. The container overview shows information about recent changes to the container and prompts you to add your first tag (which we’ll do in an upcoming section).


In the top navigation, you’ll notice tabs for Accounts (which takes us back to the list of accounts and containers), Container (this overview screen), Versions, and Admin (the account and container settings).


Google Tag Manager has three building blocks that work together:


  • Tags, the tracking components for Google Analytics or other tools, which are typically composed of JavaScript or an image (tracking pixel).


  • Triggers, which are rules that specify when a tag should be executed by the Google Tag Manager container.
  • Variables, which extract pieces of information from the page for use in tags and triggers.


Note  If you’ve been using Google Tag Manager since its beginning, you may remember that triggers were once called “rules” and variables were called “macros”. Some older documentation may still contain these terms.


Note that these three building blocks correspond to the items in GTM’s left-hand navigation. Clicking on any of these navigation items displays a list of existing tags, trigger, or variables, and allows you to create new ones.


In addition, there’s the ability to organize these tags, triggers, and variables into folders. This can be a handy organizational tool as the number of items in your container grows.



Tags, the first building block of Google Tag Manager, are the tracking scripts or pixels that tools use to record data. Google Tag Manager supports any kind of asynchronous tag. It has built-in templates for a number of Google products and third-party tools, as well as the ability to add completely custom HTML or image tags.


For tag templates, Google Tag Manager handles all of the necessary JavaScript, providing a form with various options and entry fields for filling in settings or data within the tag’s code. For example, the Google Analytics tag requires you to fill in the property ID.


Instead of editing JavaScript, there’s a simple form field to fill in this value. (You’ll see the entire setup of a Google Analytics tag using Google Tag Manager later in this blog.) Each different tag template has its own settings based on the options available and the data it gathers.


The tag templates support Google Analytics, AdWords conversion and remarketing tags, DoubleClick Floodlight counter and conversion tags, as well as a variety of third-party (non-Google) tools. However, Google Tag Manager also supports completely custom tags—either custom HTML (into which you can insert any custom HTML, including scripts), or custom image tags (which can be used for tools that use a simple tracking pixel, without scripting).


Custom HTML tags, in particular, give great flexibility in using tags from tools for which templates aren’t provided, or in using completely custom code to track page elements or user interaction.



Triggers, the second of GTM’s building blocks, describe under which circumstances a tag should be fired. Triggers can evaluate a variety of conditions on variables to determine whether a tag should be executed (see the following section for examples of variables).


When you create a Google Tag Manager container, it includes one default trigger, All Pages, which executes on any pageview (which would be appropriate for your basic Google Analytics tag, for example).


However, in many circumstances, you want tags only to execute under more specific circumstances (for example, when a conversion occurs or when a certain user interaction takes place). You can create additional triggers, each of which includes one or more conditions. If more than one condition is included in a trigger, all of the conditions must be fulfilled for the trigger to apply (logical AND).


The conditions specified in triggers can specify an exact value, values containing a string, numerical value comparisons such as greater than and less than, or they can use regular expressions to match patterns.


Triggers, once created, can be used on any number of tags. For each tag that you create in Google Tag Manager, you can assign both firing triggers and optional blocking triggers. Firing triggers say when the tag should execute.


If any of the firing triggers apply, the tag would be executed (logical OR). Blocking triggers specify when a tag should NOT execute, and take precedence over firing triggers. A tag needs at least one firing trigger to be executed. If you don’t assign any triggers to a tag, it will never fire.



Variables are the third building block of Google Tag Manager, and they allow you to pull information from a web page for use in tags and triggers. Variables let you customize the information you collect based on the actual content of the page.


Google Tag Manager variables can be used to fill in the data and settings used in tags and the criteria specified in rules. In entry fields in Google Tag Manager, you’ll see a small building block icon, which allows you to access a drop-down of existing variables within your container.


You can also type a variable directly into any text entry field or custom code within Google Tag Manager using its name enclosed in double curly braces: {{Variable Name}}. Google Tag Manager will automatically insert the value of the variable. (When referring to variables in this blog, we’ll use this format as well.)


Your container already includes a number of useful built-in variables, such as {{Page URL}} and {{Referrer}}. You’ll see these listed in categories at the top of the Variables section.


Notice that the built-in variables can be enabled or disabled. In a brand new container, a few of the built-in variables will be enabled by default. Those will be sufficient for now, but as other needs arise in later blogs, you’ll enable more of these. We’ll look at the types of variables and what values they contain below.


You can also create user-defined variables. When creating a new variable, you can select from among a number of different types. The variable types available include the following, which are grouped together into some categories based on their usage:


Basic page attributes: URL, HTTP Referrer

  • Gleaning data from page content: DOM Element, JavaScript Variable, First-Party Cookie, Data Layer Variable, Custom JavaScript
  • User interactions: Custom Event, Auto-Event Variable


  • Google Tag Manager attributes: Container Version Number, Debug Mode
  • Others: Constant String, Lookup Table, Random Number


Basic Page Attribute Variables

These variables are based on the basic attributes of the page, URL and Referrer.



Your container already has three built-in variables available for the URL of the current page, {{Page URL}} (the full URL from beginning to end), {{Page Hostname}} (just the domain name), and {{Page Path}} (just the pathname portion of the URL, after the domain).


The URL variable type additionally allows you to create variables to access individual pieces of the URL for the current page or any other URL. It’s a convenient way to avoid having to create regular expressions to match particular parts of a URL string.


protocol hostname port path query fragment  http:// thesisscientist.com :8080 /folder/ ?category= #returnspage.html hats&sort=mad 


HTTP Referrer:

The previous page through which the current page was accessed (via a link or form submission). Google Tag Manager again includes a built-in variable {{Referrer}} with the entire referring URL, but the variable type allows you to access individual parts of the URL string.


Page Content Variables

 Page Content Variables

The next group of variable types makes use of information that’s part of your web page. They use the HTML elements of the page through the browser’s Document Object Model (DOM) or via JavaScript to extract page content. You’ll make extensive use of the following types of variables in Blog and further explore their capabilities.


DOM Element:

You can specify an element of the page by its id attribute. The contents of the variable can be the text content of the element or the text of an attribute.


JavaScript Variable:

You can specify the name of a global JavaScript variable for the page. This includes any global variables available in custom code for your page, but note that you may also access standard DOM variables such as document.title.


First-Party Cookie: You can specify the name of a cookie and access its values.


Data Layer Variable:

You can provide information to Google Tag Manager in a standardized object known as a data layer. See “Providing Data to Google Tag Manager with a Data Layer” later in this blog for further information.


Custom JavaScript:

The most flexible type of variable, this allows you to include any JavaScript function. The value of the variable is the value returned by the function.


User Interaction Variables

The Custom Event and Auto-Event Variable types are used for capturing interactions with the page. The built-in variables in the Clicks, Forms, and History categories cover these types.


  • Google Tag Manager Attribute Variables
  • These variables, both available as built-in variables, access information used internally by Google Tag Manager.


  • Container Version Number: This variable’s value is the version number of the currently published Google Tag Manager container.
  • Debug Mode: This true/false variable indicates that the page is being viewed using GTM’s debug mode.


Other Variable Types

Constant String: This variable type can be used for a simple string. Even though it’s not dynamic, this variable can be useful for a string that’s used in multiple tags or triggers, because it allows a single place to update the value.


Lookup Table: The lookup table variable type allows a series of comparisons to pick a value from a list.


Random Number: This variable contains a random number between 0 and 2,147,483,647. This is available as a built-in variable. Providing Data to Google Tag Manager with a Data Layer.


In some cases, you’ll be able to capture information of interest directly from the page using variables for URLs, DOM Elements, and so on. But at times, there is information you might like to capture that is not part of the page—metadata about the page itself or the user viewing it that is not explicitly displayed in the page’s content.


Examples could include information such as a page’s category (where that isn’t made explicit in the URL) or a user’s identity (for a site where users log in).


Google Tag Manager uses an object for communication of this type of information, called a data layer. The data layer provides a centralized list of information made easily accessible to Google Tag Manager, but which remains invisible to the user viewing the page.


Structure of the Data Layer

The data layer is a JavaScript array named dataLayer that contains objects with properties. You can include a data layer in your page by declaring the data layer before the Google Tag Manager container script, like this:


dataLayer = [{

'pageCategory': 'hats',

'userId': '12345'




Each property provided in the data layer object has a name (which you can retrieve using a variable) and the value that applies to the particular page or user. The property names here, pageCategory and userId, are merely examples. The data layer properties can have any names you wish, although Google Tag Manager uses several property names (such as an event) with special meaning.


Filling In the Data Layer

Filling in the values of the data layer typically involves server-side code in your website’s templates. Your content management system or application server know the category of the page or the user’s login id, for example, and you’ll need to pull that data from the appropriate places in those systems to fill in values in the data layer.



Google Analytics has a three-level structure: accounts, properties, and views. Access to Google Analytics is through Google Accounts, which are logins based on a Gmail address or any other email address. Each login may have different levels of permission at any level in the Google Analytics account structure.


Google Analytics collects data through tracking hits, packages of data about an interaction that are sent from your website using JavaScript, or from another source of data such as a mobile app. Hits are grouped together in sessions, and users are tracked over multiple sessions. There are privacy provisions for notifying your users about your data collection practices and restricting the data you can collect.


Google Analytics data is based on dimensions (labels that describe data) and metrics (numeric measurements). All reports, including standard reports, custom reports, and APIs are based on GA’s dimensions and metrics.


Standard reports are pre-aggregated, meaning the numbers are precalculated. Non-pre-aggregated reports, such as a custom report or a standard report with an added segment, can be sampled, meaning that the numbers are calculated on the fly from a subset of the data if the dataset is large.