What is Google Analytics (How to use Google Analytics 2019)

What is the Google Analytics

What is Google Analytics and How to use Google Analytics

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. This Blog explains the What is Google Analytics and How to use Google Analytics 2019.


 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

How to use Google Analytics

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.,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

Google Analytics

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, 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 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.


[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]


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.


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. 


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.  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.


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.

Google Analytics Tracking events and Links and Google Analytics Ecommerce

Google Analytics Tracking events and Links and Google Analytics E-commerce

Google Analytics offers two options for E-commerce tracking. Basic E-commerce tracks completed purchases only. Enhanced E-commerce tracks many E-commerce interactions throughout the site.


Either must be enabled in Google Analytics. You can also set a preferred currency in your view’s settings in Google Analytics, which can automatically convert if you send data in a different currency.


Basic E-commerce tracking requires implementing server-side code to add E-commerce data to the data layer on the final transaction page of the site.


Then a Google Analytics transaction tag is added in Google Tag Manager to be triggered only on this final transaction page, reading the information in the data layer and sending it to Google Analytics.


This approach is advantageous because it is straightforward, but limited in the types of insights that can be derived from the data.

Enhanced E-commerce tracking requires implementing server-side code to add E-commerce data to the data layer on many pages of the site, to record details such as impressions, clicks, and detail views of products, additions to and removals from the shopping cart, purchases and refunds, and impressions and clicks of internal promotions.


Enhanced E-commerce data is sent along with an existing pageview or event tag for Google Analytics by reading the E-commerce data from the data layer.

Google Analytics Tracking events

For sites that sell products, you can gather additional data about the purchases users make on the site. Google Analytics offers two levels of detail in tracking E-commerce


Basic E-commerce tracking tracks purchases only. Since it is only concerned with the completed purchase, you only need to make changes in Google Tag Manager for the final purchase confirmation page.


Enhanced E-commerce offers expanded tracking of users’ interactions with products all through the site, from viewing a product in a list, adding it to the cart, and ultimately purchasing.


It offers richer ways to categorize and track all types of product interactions. Because of this, you will generally have to make tracking changes throughout much of the website to take full advantage of enhanced E-commerce.


Which should you choose? If you need only very simple E-commerce tracking, the basic option may suffice. For many sites, the enhanced E-commerce offers much deeper and more actionable data, however, so if you have the resources to implement it, it’s recommended.


With either E-commerce tracking option, implementation generally involves two sets of tasks:

  1. Changes to your website to provide the E-commerce data to Google Tag Manager via the data layer.
  2. Changes to tags in Google Tag Manager to accommodate sending E-commerce data to Google Analytics.


This blog lays out the process for both basic and enhanced E-commerceincluding walking through any Google Tag Manager changes (the second item). For the first item, the information that needs to be present in the data layer and in what format will be detailed.


This is normally accomplished by server-side changes to the website to provide this data in the data layer, and so the specific implementation will depend on your site and E-commerce platform.


E-commerce TRACKING FOR NON-E-commerce sites


Although it’s generally intended for measuring purchases, GA’s E-commerce tracking features are well-suited to any type of transactional interactions, whether there’s a monetary component or not. This might include scenarios such as the following:


Selecting from a catalog or library of items, such as e-blogs, videosor other content, and downloading, checking out, or viewing such items.

  • Registering for classes or online courses.
  • Applying for volunteer or job opportunities.
  • Selecting or configuring products that are ultimately purchased offline (such as a car).


  • In many cases, you might find goals sufficient for measuring these scenarios. If you want more detailed data about the particulars of each transaction, however, E-commerce tracking can be a good option. All of the E-commerce tracking functionality described in this blog will still work even with $0.00 amounts.


The remainder of this blog is divided into two sections, for basic E-commerce and enhanced E-commerce tracking. For implementation, you should choose one option or the other, and it’s only necessary to read the relevant section.


Basic E-commerce Tracking

Basic Ecommerce Tracking

Basic E-commerce tracks only completed purchases. Setting up basic E-commerce involves three steps:

  • Enable E-commerce tracking in Google Analytics.
  • Add E-commerce data to the data layer on the site.
  •  Add a Google Analytics transaction tag in Google Tag Manager. Let’s walk through the process.


ENABLE BASIC E-commerce TRACKING IN Google Analytics

First, you’ll enable E-commerce tracking in Google Analytics. This enables the E-commerce reports in the Conversions section as well as E-commerce data available in other reports throughout Google Analytics. E-commerce reports can be enabled or disabled in each view’s settings.


  • In the Admin tab of Google Analytics, choose the desired account, property, and view from the drop-down lists.
  •  In the view’s settings (the rightmost column), select E-commerce Settings
  • To enable E-commerce tracking, set the toggle to On. Select the Next Step button.
  • Leave the setting for enhanced E-commerce Off and select the Submit button.


You can also set the currency that you’d like to see in reports in this view. (GA will convert E-commerce data between currencies if you have a multicurrency store; see the following sidebar for more details.)

  • Still, in the Admin tab of Google Analytics, choose View Settings in the rightmost column.
  • About halfway down this page of settings is a drop-down list of currencies. 
  • Choose the currency you wish to see in reports for this view.
  • Select the Save button.


Enabling E-commerce simply makes the appropriate reports available in Google Analytics, but you still have to send the E-commerce data to fill them up. Next, you’ll add some information to your data layer about the purchase. Then, you’ll create a tag in Google Tag Manager to send this data to Google Analytics.


E-commerce Data in the Data Layer

Data about the purchase will be provided on the final confirmation page of the purchase process using Google Tag Manager’s dataLayer object. Google Tag Manager specifies a format and labeling for the pieces of information Google Analytics requires.


Here’s an example of purchase data in the data layer; let’s break down the pieces afterward.

dataLayer=[{transactionId:"AW699168",transactionAffiliation:"ThesisScientist",transactionTotal:42.98,transactionTax:3,transactionShipping:3.99,transactionProducts:[{sku:"MH342",name:"Thesis",category:"Hats",price:17.99,quantity:1},{sku:"MH007",name:"Purple blogs",category:"Hats",price:24.99,quantity:1}]}];</script>


Caution  You should only declare the data layer (with a statement like dataLayer = []) once within the page, and it should be before the Google Tag Manager code. Declaring the data layer again at a later time will overwrite its previous values and can cause Google Tag Manager to behave unexpectedly. 


To provide additional values to the data layer after it’s been created, use dataLayer.push(), which appends to the data layer, rather than overwriting it.


In this case, you need the values to be included when the page loads, so you’ll include the E-commerce data in the declaration.

This code should be included only when the transaction is completed—that is, on the final receipt page in the checkout process.

  • The first set of attributes summarizes the transaction:
  •  the transaction is required and serves as a unique identifier for this particular purchase.
  •  transactionAffiliation is optional and could denote a particular store (if you have multiple stores) or an affiliate code.


  • TransactionTotal is required and represents the total revenue for the transaction. (This total can be inclusive or exclusive of shipping and tax, depending on how you want to see revenue in your reports.)
  • transaction tax and transactionShipping are optional and represent tax and shipping charges for the transaction.


The next part of the E-commerce data is an array called transaction products. The array has entries for each of the distinct products purchased. Each product entry contains the following attributes:


  • SKU and name are required and represent an identifier and a label for the product.
  • the category is optional and represents a categorization or grouping of products.
  •  price is required and represents the unit price for the product.
  •  quantity is required and represents the number of units purchased. It should be an integer.


You need to repeat this information in the data layer for each of the products that are part of the transaction. In our example, there are two products.


As mentioned previously, the values of the information in the data layer are included from your site’s data, typically using server-side code to pull the values from your database or E-commerce platform.


The specifics of how to do this are particular to your site and the tools you are using to process these transactions, but as long as you format the data in this way, Google Tag Manager and Google Analytics can use it.


Caution  Since you’re inserting values from your database into this JavaScript code, you need to be careful about formatting and syntax. Specifically, beware of apostrophes or quotation marks in text fields (note the apostrophe escaped using the backslash in 'ThesisScientist' in the example code).


Also, note that currency values are numeric, and so should contain only digits and a decimal (no currency symbols or commas) — so 1342.57, not $1,342.57.



As you saw, you can choose a currency setting for your view in Google Analytics, which controls the currency shown in the reports. If you have a single-currency store, you simply set your reports to show US Dollars, send your prices and transaction amounts in US Dollars, and the numbers appear in the reports.


However, you may have a situation where you have a store that accepts multiple currencies, or several country-specific stores where you want to aggregate reporting across the locales. In such a situation, currency conversions need to occur for reporting.


In the transaction data in the data layer, you can specify a currency using the transaction currency attribute (for the transaction total) and the currency attribute (for each product). The currency values are three-letter codes such as USD or EUR that represent the currency.

The Google Analytics documentation includes a complete list of the currencies supported by Google Analytics.


dataLayer=[{transactionId:"AW699168",transactionAffiliation:"ThesisScientist",transactionTotal:42.98,transactionTax:3,transactionShipping:3.99,transactionCurrency:"EUR",transactionProducts:[{sku:"MH342",name:"Thesis",category:"Hats",price:17.99,quantity:1,currency:"EUR"},{sku:"MH007",name:"Purple blogs",category:"Hats",price:24.99,quantity:1,currency:"EUR"}]}];</script>


This is the same transaction as before, with the added transaction currency and currency attributes to indicate the currency in euros. (Although it would be unusual to have different currencies for different products, you still need to include the currency for the transaction total as well as each product.)


If the currency code included in the transaction data differs from the currency setting in Google Analytics, the currency will be converted using a daily exchange rate, and the resulting amounts shown in the reports.


(The exchange rate is taken from Google Billing and is an average for the previous day. As a result, the exact amounts may have small variances from the exchange rates you actually obtain through your financial institutions.)


For basic E-commerce tracking, the data layer object described is the only additional code you’ll need on the site. In the next section, you’ll create the Google Tag Manager tag to send this data to Google Analytics.


Basic E-commerce Tag in Google Tag Manager For basic E-commerce tracking in Google Analytics, there’s an additional hit type to send transaction data (just as you’ve previously seen hits to send data about page views or events). To send this data, you’ll have to create an additional tag in Google Tag Manager.


Create A Basic E-commerce Transaction Tag In Google Tag Manager

You can add a Google Analytics transaction tag in Google Tag Manager by following these steps:


  • Create a new tag. Select Google Analytics ➤ Universal Analytics as the tag type.
  • As you did in the basic pageview tag, you’ll fill in the Tracking ID with the {{GA Property ID}} variable you previously created.
  • Select Track Type ➤ Transaction. You’ll notice that a message is displayed indicating that you should set up the data layer appropriately (see the following screenshot), which you’ve already done. Select Continue.
  •  For the trigger, choose Some Pages. The list of any page triggers you’ve previously created is shown.
  •  Select New to create a new trigger.
  •  Name the trigger appropriately; for example, the Receipt page only.
  • Enter some criteria to trigger this tag only on the final checkout page (the page to which you added the E-commerce code in the data layer). Typically, you could do this with a criterion using the {{Page URL}} variable.
  • Save the trigger.
  • Save the tag, giving it a name: “GA – E-commerce”.


That’s it! This tag will now fire (after testing and publishing, of course) on the receipt page, where it reads the data you previously added to the data layer and sends it to Google Analytics.


Create a Goal in Google Analytics for the Checkout Process

Create a Goal in Google Analytics for the Checkout Process

The tasks in the previous sections are the only things you need to do to enable E-commerce reporting in Google Analytics and collect data on transactions.


However, you probably also want to set up a goal with a funnel for the checkout process so that you can see how users progress through the steps leading up to their completed purchase (or fail to complete that process). 


Enhanced E-commerce Tracking

The enhanced E-commerce features in Google Analytics go beyond just measuring completed purchases, to track E-commerce interaction activity throughout the entire website. 


The data you can collect include interactions of two types: with products (from viewing the product all the way through purchase) and with internal promotions (such as a banner or other offer).


Information about all of these interactions will be handled by adding information to the data layer. Google Tag Manager and Google Analytics expect a certain format and labeling for this data, which you’ll look at with detailed examples.


There are a variety of reports in the Conversions ➤ E-commerce section of reports in Google Analytics that reflect the data you send.


For products, the interactions are as follows:

  • Product impression (impressions): The user saw a listing of products, as in a category page, for example.
  •  Product click (click): The user clicked a product listing.
  •  Product detail view (detail): The user viewed a product detail page.
  • Add and remove products from the cart (add and remove): The user added or removed a product from the shopping cart.
  • Checkout (checkout): The user proceeded through the steps of the checkout process (you’ll be able to configure the number and sequence of steps).
  •  Purchase (purchase): The user successfully purchased a product or products.
  •  Refund (refund): A full or partial refund was issued.
  • For promotions, the interactions are as follows:
  • Promotion impression (promo view): The user saw a promotion, such as a sale banner.
  •  Promotion click (promo click): The user clicked a promotion.


Note that the types of interactions you’re talking about fall into two categories: those that occur when the page loadsand those that occur only when the user clicks on some element of the page.


In the first category are impressions, detail, and promo view, which all indicate something being viewed on a page. For these measurements, you can include E-commerce data in the data layer declaration when the page is loaded. 


In the latter category are click and promo click, which both indicate a click. For these interactions, you’ll need to push information to the data layer when the click occurs.


Other interactions, such as add, remove, checkout, and the purchase could fit either category, depending on the site. Some sites might take the user to the cart page when adding a product, while others might merely add the product without refreshing the page.

For checkouts, each step (billing, shipping, etc.) may be a separate page, or they may all be within a single page (using AJAX). You can deal with either scenario.


Finally, a refund is a type of interaction that may often take place outside a regular user interaction on the site (they may occur in conjunction with a customer service request, for example). You’ll examine how to handle refunds separately.



The types of interactions that can be tracked in enhanced E-commerce and the amount of data needed to support them can be overwhelming when you are considering implementation.


However, recognize that it’s not necessary to implement everything at once. There are no dependencies among the interaction types, so you can choose to implement some of them but not others (although of course, the Google Analytics reporting will show only those you have implemented).


Because of this, it’s common to start with only the most vital interactions, like the shopping cart, checkout, and completed purchases. More information about impressions and clicks can then be layered in, and finally, you can address promotions and refunds, if desired.


Enabling Enhanced E-commerce

Before sending data, you first need to enable enhanced E-commerce in Google Analytics and in Google Tag Manager. Here’s the process. First, let’s enable E-commerce tracking in Google Analytics.


This enables the E-commerce reports in the Conversions section, as well as E-commerce data available in other reports throughout Google Analytics. E-commerce reports can be enabled or disabled in each view’s settings.


  • In the Admin tab of Google Analytics, choose the desired account, property, and view from the drop-down lists.
  • In the view’s settings (the rightmost column), select E-commerce Settings 
  • To enable E-commerce tracking, set the toggle to On. Select the Next Step button.
  • Change the setting for enhanced E-commerce to On.


In the Checkout Labeling settings, choose Add Funnel Step and add a label for each step in the checkout process. For example, if the checkout contains the following steps, you’d add each one as a labeled step in the funnel:

  • Shipping
  •  Billing
  •  Payment
  • Review


This is similar to a goal funnel setup but is specific to the enhanced E-commerce reports. You’ll add code later that indicates where the user is in each of the steps in this process. Note that it's not necessary to add the purchase confirmation as a step; that’s always assumed to be the final step in the process.


  • Select the Submit button to save the settings.
  • You can also set the currency you’d like to see in reports in this view. 
  • Still, in the Admin tab of Google Analytics, choose View Settings in the rightmost column.
  • About halfway down this page of settings is a drop-down list of currencies. 
  • Choose the currency you wish to see in reports for this view.
  • Select the Save button.



Enhanced E-commerce sends additional E-commerce data along with existing Google Analytics tags (s), such as the basic pageview tag or an event tracking tag. You’ll enable enhanced E-commerce for the basic pageview tag. Later in the blog, you’ll look at uses that require an event or virtual pageview tags.


Note  Do not use the Google Analytics “Transaction” tag type for enhanced E-commerce. The transaction tag is used in basic E-commerce tracking. With enhanced E-commerce, product data is sent along with another hit, such as a pageview or an event; it does not require an additional tag type.


 In the list of tags in Google Tag Manager, select the basic Google Analytics pageview tag to edit.

  •  Click the Configure Tag section to edit the tag.
  • Under More Settings ➤ E-commerce Features, select the check box to Enable Enhanced E-commerce Features.
  • Check the box to use the data layer. (The other option allows you to read E-commerce data from a variable instead of the data layer. You’ll see an example of when you might use that later in the blog, but for all the basic tags, you’ll be using the data layer.)
  •  Save the changes to the tag.


The Google Analytics pageview tag is now ready for you to add E-commerce data to the data layer. When E-commerce data is present in the expected format, it will be sent along with the pageview automatically.


E-commerce Data in the Data Layer Declaration

Now that you’ve enabled enhanced E-commerce, you can begin to include E-commerce data in the data layer, which will be sent along with the Google Analytics pageview tag.


This is the approach you’ll use for any data that’s available at the time the page loads. Since the data is available on page load, you’ll include it in the data layer declaration (dataLayer = []). (For data from a click or an AJAX interaction after the page loads, you’ll use dataLayer.push() to send data; see the next section for details.)


You can declare a data layer before by including it in the page before the Google Tag Manager container code. Your E-commerce data will be included in an object called e-commerce. The basic format for the object looks similar to the following:



Each action has slightly different details and required and optional attributes. Detailed examples are provided in the following sections for all actions.


As mentioned previously, the values of the information in the data layer are included from your site’s data, typically using server-side code to pull the values from your content management system or an E-commerce platform. 


The specifics of how to do this are particular to your site and the tools you are using to process these transactions, but as long as you format the data in this way, Google Tag Manager and Google Analytics can use it.


Note  The naming and hierarchy of data layer attributes are different for enhanced E-commerce from basic e-commerce. If you are updating from basic e-commerce, you’ll need to make revisions to the fields in your data layer.




As you saw earlier, you can choose a currency setting for your view in Google Analytics, which controls the currency shown in reports. If you have a single-currency store, you simply set your reports to show US Dollars, you send your prices and transaction amounts in US Dollars, and the numbers appear in the reports.


However, you may have a situation where you have a store that accepts multiple currencies, or several country-specific stores where you want to aggregate reporting across the locales. In such a situation, currency conversions need to occur for reporting.


In your transaction data in the data layer, you can specify a currency using the currencyCode. The currency values are three-letter codes, such as USD or EUR, that represent the currency.


The Google Analytics documentation includes a complete list of the currencies supported by Google Analytics.

If the currency code included in the transaction data differs from the currency setting in Google Analytics, the currency will be converted using a daily exchange rate, and the resulting amounts shown in your reports.


(The exchange rate is taken from Google Billing and is an average for the previous day. As a result, the exact amounts may have small variances from the exchange rates you actually obtain through your financial institutions.)


Product Data

There are many E-commerce actions that include product data, from product impressions, through viewing a product, adding it to the cart, and checking out. Throughout this process, there are a number of core attributes about products that can be captured:


'name': 'blogs',
'id': 'MH007',
'price': '24.99',
'brand': 'ThesisScientist',
'category': 'blogs',
'variant': 'Purple'


These attributes describe various characteristics of the product: 

  • name and id are required and represent a label and an identifier (SKU) for the product.
  • the price represents the unit price for the product.
  • brand, category, and variant are optional and are used to further describe and categorize products:

the brand represents the brand name or designer of the product. the category represents a categorization or grouping of products. With enhanced E-commerce (unlike basic e-commerce), you can specify hierarchical categories up to five levels deep, separated by a slash (/).


In this example, the top-level category is Hats with a subcategory of Mens. Typically, you would use this to represent the taxonomy the site uses to organize and present products. variant represents some further differentiation of the product, such as color, size, and so forth.


In addition, there are other attributes, such as quantity, that only apply under certain circumstances; you’ll see these in the detailed examples to follow.


Additionally, you can use custom dimensions to capture even more information about products, if appropriate. As noted, many of these attributes are optional, but the more information you fill in, the richer your E-commerce reports in Google Analytics will be.

Product Impressions

Product Impressions

The impressions action is used to record impressions of products as users see them throughout the site. Typically, E-commerce sites show lists of products in many places: on the home page, on category pages, on search results pages, and in related product recommendations. 


By sending data about which products are viewed in these lists (and then later, which products are clicked and purchased), you can better understand click-through and purchase behavior on a per-product and per-list basis.


Here’s an example of impressions data in a data layer:

<script>dataLayer=[{E-commerce:{impressions:[{name:"blogs",id:"MH007",price:"24.99",brand:"ThesisScientist",category:"blogs",variant:"Purple",list:"Featured Products",position:1},
{name:"Thesis",id:"MH342",price:"17.99",brand:"ThesisScientist",category:"blogs",variant:"Grey",list:"Featured Products",position:2}]}}];</script>


Note that impressions is the name of an array containing the impressions data. The array is a list of products for which you wish to record an impression on this page (only two in this example, but as many as necessary on your site). These can include all the core attributes described previously, and also two additional attributes:


list is a name for the list of products. You can use whatever names you want; choose names that are easily understood by users of your reports to represent the product lists on your site, such as “Category Page”, “Recommended Products”, “People Who Purchased This Also Liked”, and so forth. 


The position is numeric and represents the position of the product within the list (starting with 1). You can include as many products in as many lists as are on the page.


Note  There is an 8-kilobyte limit to the amount of data sent in any Google Analytics request (approximately 8,000 characters). In typical usage, this is not a barrier, but if you have any impressions on a page, you may run afoul of this limit.


Keep track of how long your list of product data grows, and if necessary, you may need to split it into multiple requests (using dataLayer.push() to send additional events to Google Analytics with more product impressions).



In some cases, a site might not load all the products at once, but only when the user begins to scroll down the list, an effect that is sometimes called lazy load or infinite scroll.


In this case, product impression data for some sets of products might not be available until after the page loads, so you won’t be able to include them in the data layer definition.


In this case, you could use dataLayer.push() to send additional product impression data to the page after page load. You’ll also need an event to send this data to Google Analytics. The click and the AJAX interaction examples later in this blog provide examples of sending E-commerce information after the initial page load.


Product Detail View

The detail action represents viewing a product detail page. Here’s an example of a product detail view in a data layer:



For this data, detail is the name of the object, which contains a products array with the core product attributes. (Typically for a product detail view, there is only a single product.) The detail action has an optional property, list, that can be provided in the action field object, like so:

<script>dataLayer=[{"E-commerce":{detail:{actionField:{list:"Featured Products"},products:[{name:"blogs",id:"MH007",price:"24.99",brand:"ThesisScientist",category:"blogs",variant:"Purple"}]}}}];</script>


This allows you to capture which list a user came from to arrive at the product detail page. (If you’re already tracking product impressions and product clicks, this is unnecessary, but may be useful if you’re not capturing those details.)


Note that there may be more than one type of E-commerce data included in the data layer. For example, on a product detail page, there may also be a list of products with impressions (such as “Related Products” or “People Who Bought This Also Bought...”). You can combine these in the data layer:



Cart Additions and Removals

The add and remove actions can be used to track products added to or removed from the shopping cart.



The action object can be named add or remove as appropriate and contains one or more products. The product objects include the core attributes as well as the quantity attribute, which is numeric and indicates the number of items added or removed.


Checkout Process

Checkout Process

You can measure the checkout process using the checkout action. Recall that when you enabled enhanced E-commerce in Google Analytics, you labeled the steps of the checkout process. In the example, you included four steps:

  • Shipping
  • Billing
  • Payment
  • Review


The final step is always the completed purchase (which is a separate action addressed in the next section). For your site, you should include as many steps as you need. You’ll include code in the data layer corresponding to each of the steps, as illustrated next.


Note  This example assumes that each step of the checkout process is a separate page. For a site with an AJAX checkout process, see the “AJAX Cart and Checkout Interactions” section later in the blog.

<script>dataLayer=[{E-commerce:{checkout:{actionField:{step:1,option:"White Rabbit Delivery Service"},products:[{name:"blogs",id:"MH007",price:"24.99",brand:"ThesisScientist",category:"blogs",variant:"Purple",quantity:1},{name:"Thesis",id:"MH342",price:"17.99",brand:"ThesisScientist",category:"blogs",variant:"Grey",quantity:1}]}}}];</script>


The action is named checkout, and in the action field object you can specify two additional attributes: step indicates which step of the checkout process this is. (It’s not required if you have a one-step checkout, but otherwise it’s needed.) the option is an optional attribute to indicate some additional characteristic about the checkout step.


For example, it might be used to indicate a shipping method (as in this example) or payment method.


The product data includes all the core attributes, plus a quantity attribute (just like the add and remove actions as before).

You’ll repeat this data, changing the step number and options as necessary, on each page that is part of the checkout.


Often, you don’t know the value of an option until the subsequent step. For example, on the shipping page, the user has the option to select different shipping methods.


You can’t fill in that choice in the data layer for the shipping page, because you don’t yet know what the user will choose. To accommodate this, there’s an additional action called checkout_option that you can use to update the chosen option for a step:

'ecommerce': {

'checkout_option': {
'actionField': {'step': 1, 'option': 'White Rabbit Delivery Service'}
} }

The actionField indicates the step and the option value. Typically, you could include this in the data layer for the subsequent page (step 2 in this case). The full example might look like this:
dataLayer = [{
'ecommerce': {

'checkout_option: {

'actionField': { 'step': 1, 'option': 'White Rabbit Delivery Service' }


'checkout': {

'actionField': { 'step': 2 },

'products': [ // as above ]
} } }];



Finally, when a purchase is successfully completed, you can use the purchase action.

<script>dataLayer=[{E-commerce:{purchase:{actionField:{id:"AW699168",affiliation:"Online Store",revenue:"55.97",tax:"3.92",shipping:"",coupon:"FREE_SHIPPING"},products:[{name:"blogs",id:"MH007",price:"19.99",brand:"ThesisScientist",category:"blogs",variant:"Purple",quantity:1,coupon:"TOPHAT_SALE"},{name:"Thesis",id:"MH342",price:"17.99",brand:"ThesisScientist",category:"blogs",variant:"Grey",quantity:2}]}}}];</script>


For the purchase action, the action field object contains a number of attributes that summarize the transaction:

  • ID is required and serves as a unique identifier for this particular purchase.
  • affiliation is optional and could denote a particular store (if you have multiple stores) or affiliate code.


  •  revenue represents the total revenue for the transaction. (This total can be inclusive or exclusive of shipping and tax, depending on how you want to see revenue in your reports.) If you don’t specify revenue, Google Analytics uses the total price for the products in the transaction.


  •  tax and shipping are optional and represent tax and shipping charges for the transaction.
  •  coupon is optional and represents a coupon applied to the overall transaction.


Then the products are included in an array for each of the products that are part of the transaction, including the core product attributes as well as the following:

  • quantity, as previously seen in add, remove, and checkout actions for the number of items of that particular product purchased.
  • coupon is optional and represents a coupon applied to a particular product.


Note  The same fields used for Google Analytics can also be used for purchase tracking for Doubleclick transaction tags (with some additional optional fields that can be used for Doubleclick).



You can also record refunds using the refund action. An entire transaction can be refunded, as in the following example:

<script>dataLayer=[{E-commerce:{refund:{actionField:{id:"AW699168"}}}}];</script> The id attribute should match the id of the original transaction.

You can also record a partial refund of only certain products in the transaction:


Here, the id in the action field object should match the id of the original transaction, and the id and quantity of each item in the products array should represent which items are being refunded.


Providing refund data in the data layer, as in this example, is a workable approach if users can obtain a refund by completing a process on your website.


However, in many cases, refunds might be issued through a customer service process that takes place outside the user interactions on the website (through online or phone support, for example).


In a case like this, you can process such interactions using GA’s Measurement Protocol to record data from a non-web application or by importing the data to Google Analytics in a spreadsheet.


Promotion Data

In addition to product data, you can also provide information about internal promotions: a banner promoting certain products on sale, for example. Just as with products, you can measure both impressions and clicks of such promotions.


Data about these promotions and purchases that result after clicking them are available in the enhanced E-commerce reports in Google Analytics.

Promotions can include the following attributes:

'name': 'April Foolery Clearance',
'id': 'PROMO_0401',
'creative': 'Tweedle Dee v.1',
'position': 'Store Home Banner'


The attributes describe the promotion as follows: At least one of name or id is required. They give a label and identifier for the promotion, respectively.  creative is optional and describes the creative content or format of the promotion. the position is optional and describes the location or slot in which the promotion was displayed.


Since promotion impression data is available when the page loads, you can include them in the data layer declaration, like all of the product data you’ve looked at so far. (For promotion clicks, see the “Product and Promotion Clicks” section later in this blog.)


Promotion Impressions

Promotion impressions can be included in the data layer declaration as follows:

<script>dataLayer=[{E-commerce:{promoView:{promotions:[{name:"April Foolery Clearance",id:"PROMO_0401",creative:"Tweedle Dee v.1",position:"Store Home Banner"},{name:"Free Shipping",id:"FREE_SHIPPING",creative:"White Rabbit Delivery Service",position:"Right Sidebar"}]}}}];</script>


The action is promo view, and the promotions array contains one or more promotions that were included on the page with the attributes described earlier.


E-commerce Data on User Interactions

Ecommerce Data on User Interactions

In all of the previous examples in this blog, you included enhanced E-commerce data in the data layer declaration when the page loads. However, for some types of interactions, you may need to send it at a later time.


You can do this using dataLayer.push() to add information to the data layer upon user interaction and send that to Google Analytics using an event.


First, you’ll look at the two E-commerce actions that are always user interactions: product clicks and promotion clicks. Then you’ll take a look at cart and checkout interactions, which for AJAX sites might need to be handled using these techniques as well.


Product and Promotion Clicks

Earlier in the blog, you captured data about the impressions of products and promotions (using the impressions and promo view actions).

Now you can look at which of those impressions resulted in clicks using the click and promo click actions. You’ll need to trigger these when the appropriate user interaction occurs. You’ll recall that several approaches to tracking user interactions have been discussed:


  •  Embedding dataLayer.push() code directly in the site to listen for events on an element
  • Using Google Tag Manager’s auto-event tracking capabilities to attach events to an element

Either of these approaches is also viable for the product and promotion clicks, so you’ll look at each of them in the following sections.


Explicit Data Layer Events in Site Code

The E-commerce object for a product click looks like this:

 style="margin: 0px; width: 964px; height: 106px;">'ecommerce': {
'click': {
'products': [{ 'name': 'blogs', 'id': 'MH007', 'price': '24.99', 'brand': 'ThesisScientist', 'category': 'blogs', 'variant': 'Purple'


The action is slick, and it contains a products array with the core product attributes. (Unless there’s something very strange about your site, a user can only click one product at a time, so typically there’s just a single product in the array.)

For a promotion click, the E-commerce object looks like this:

 style="margin:0;width:954px;height:107px">'ecommerce': {
'promoClick': {
'promotions': [{
'name': 'April Foolery Clearance', 'id': 'PROMO_0401',
'creative': 'Tweedle Dee v.1', 'position': 'Store Home Banner' }]
} }


The action is promo click, and it contains a promotions array with the promotions attributes.

For each of the product or promotion links on the site, you’d like to capture the click interaction. To do that, you could call the dataLayer.push() function when the link is clicked:

<a onclick="dataLayer.push({'E-commerce': { // as above }, 'event': 'E-commerceProductClick' })">...</a>


Note  Although this example uses an inline onclick attribute to call the dataLayer.push() function, the code could be used in an event listener or any other existing JavaScript code on the site.


The data in the E-commerce object would be filled in by server-side code from your site, just as you fill in data in the data layer at the time the page loads, but it isn’t added to the data layer until the link is clicked.


Notice that you’ve also added an event attribute. This allows you to set up a trigger in Google Tag Manager to fire a Google Analytics event tracking tag, which will send the data (just as the Google Analytics pageview tag does for the data in the data layer at the time the page loads).



Assuming you’ve added the dataLayer.push() code described earlier, you can create the tag and trigger to use these variables to send an event to Google Analytics.

  • Create a new tag. Select Google Analytics ➤ Universal Analytics as the tag type.
  • Use the previously created {{GA Property ID}} variable for the Tracking ID.
  • In each of the Category and Action fields, enter some values to describe the event 
  • The example uses a category of “E-commerce” and an action of “Product Click”.
  • Under More Settings ➤ E-commerce Features
  • select the checkbox to Enable Enhanced E-commerce Features
  • Check the box to use the data layer.
  •  Choose to Continue to specify a trigger for the tag.
  • Choose More, then select the New button to create a new trigger.
  • Select the Custom Event as the event to cause the trigger. 
  • Custom Event allows you to trigger on a dataLayer.push with any event name.
  • For Event name to match, enter E-commerceProductClick (which corresponds to the name in the code).
  • Select the Create Trigger button, giving the trigger a name: “Custom Event – Product Clicks”. 
  • Google Tag Manager saves the trigger and returns to creating the tag.
  • Save the tag, giving it a name: “GA – Event – E-commerce Product Clicks”.


This example is specifically for product clicks. You could create another tag for promotion clicks (with a different name in the event attribute that you’ll use as the trigger for that tag).


Using Google Tag Manager’s Auto-Event Tracking

Using Google Tag Manager’s Auto-Event Tracking

The disadvantage of the approach in the previous section is that it forces you to include tracking JavaScript in the site’s code, while one of the reasons you adopted Google Tag Manager in the first place was to take tracking JavaScript out of the site’s code and centralize its control in Google Tag Manager.


As an alternative, you can use Google Tag Manager’s built-in auto-event tracking to find certain types of links or other elements on which to trigger tags. You’ll still need to provide the e-commerce data to be sent for each element, however, which you can do using a data- attribute.


In HTML, data- attributes are basically a reserved namespace of attributes for providing additional, site-specific data about elements. You can use a data- attribute on the product link:

<a data-E-commerce='{"E-commerce": { // as above }}' class="product" href="/products/fedora"> Fedora</a>


Here you’ve chosen the name data-E-commerce for the attribute. You can choose any name that starts with data-, making sure to avoid conflicts with any existing attributes in use on your site. The contents of the attribute are the object with all the E-commerce data about the product or promotion click.


Caution  Although in most cases single quotes (') and double quotes (") are interchangeable in HTML and JavaScript, the JSON (JavaScript Object Notation) specification specifically requires double quotes.


JavaScript’s JSON.parse() function (which you’ll use to access this value) respects this and treats the data-E-commerce attribute as an object only when the inner quotes are double (otherwise, it will be interpreted as a string). Long story short: don’t swap the quote styles in this example.


With the data in place on the product and promotion links you’d like to track, you can create a variable in Google Tag Manager to read this data, and then send it along with an event set up with auto-event tracking.




First, you’ll create a variable to read the E-commerce data from the data-E-commerce attribute, using auto-event tracking automatically adds a message to the data layer that includes a variable called {{Click Element}}, which allows you to access all the properties of the clicked element.

You’ll use this in a Custom JavaScript variable to return the value of the data-E-commerce attribute.


Create a new variable.

For the variable type, choose Custom JavaScript. Here’s the code you’ll be using:

function() {
var el = {{Click Element}}; if(el && el.getAttribute) {
var data = el.getAttribute('data-E-commerce');
try { return JSON.parse(data); } catch(e) { return data; }
} }


This uses the existing {{Click Element}} variable and uses a JavaScript function called JSON.parse() to retrieve the data-E-commerce attribute, and returns the contents of that attribute as the value of the variable. So long as you’ve formatted the object correctly in the attribute as discussed earlier, it will be returned as a JavaScript object.


  • Save the variable, giving it a name: “E-commerce Data Attribute”.
  • Next, you can set up a Google Analytics event tag using auto-event tracking to track clicks on the product or promotion.
  • Create a new tag. Choose Google Analytics ➤ Universal Analytics as the type.
  •  Use the previously created {{GA Property ID}} variable for the Tracking ID.
  • Select Track Type ➤ Event.
  • Fill in the Category, Action, and Label to be sent to Google Analytics. 
  • You’ll want to choose your own conventions for how you’d like to see these in your reports, but one sensible choice might be:
  • Category: E-commerce
  • Action: Product Click
  • Label: {{Click Text}} (the anchor text of the link)
  • Under More Settings ➤ E-commerce Features, select the check box to Enable Enhanced E-commerce Features. 
  • Instead of selecting the box to use the data layer, choose the {{E-commerce Data Attribute}} variable that you created earlier.
  •  Choose to Continue to specify a trigger for the tag.
  • Choose Click, and then select the New button to create a new click trigger.
  • Choose Some Clicks.
  •  Specify some criteria to trigger this tag on appropriate clicks. In this example, the product links have a class attribute with the value product, so you could use that.
  • {{Click  Classes}} – contains – product
  • Name the trigger. Then choose Link Click as the trigger type.
  • Filter pages on which the trigger should listen for product clicks (if needed).


If you want to restrict this trigger to only listening for product clicks on certain pages, you can use a condition or regular expression to match certain pages.

  • To listen on all pages, use a regular expression to match any URL:{{Page URL}} – matches RegEx – .*
  • Select the Create Trigger button, giving the trigger a name: “Product Clicks”. 
  • Google Tag Manager saves the trigger and returns to creating the tag.
  • Save the tag, giving it a name: “GA – Event – E-commerce Product Clicks”.


This example is specifically for product clicks. You could create another tag for promotion clicks (with a different trigger for that tag to target the appropriate links). The same {{E-commerce Data Attribute}} variable can be used for this tag as well.


AJAX Cart and Checkout Interactions

Earlier in the blog, you used the add, remove, checkout, and purchase actions to track interactions with the shopping cart and checkout process, and you assumed that each of the steps in that process was a distinct page, and you added information to the data layer declaration on each of those pages.


A site using an AJAX approach can use dataLayer.push() to add an E-commerce object to the data layer for the action to be measured (add, remove, checkout, purchase):

<script>dataLayer.push({event:"E-commerceCheckout",E-commerce:{checkout:{actionField:{step:1,option:"White Rabbit Delivery Service"},products:[{name:"blogs",id:"MH007",price:"24.99",brand:"ThesisScientist",category:"blogs",variant:"Purple",quantity:1},{name:"Thesis",id:"MH342",price:"17.99",brand:"ThesisScientist",category:"blogs",variant:"Grey",quantity:1}]}}});</script>


This code would typically be incorporated in the AJAX response when new content for the page is loaded. This code is identical to the checkout example earlier in the blog, except for two changes:

  • It uses dataLayer.push()
  • It includes an event attribute


Since the page doesn’t reload, you don’t want to declare a new data layer (using dataLayer = []); instead you want to append to the existing data layer (using dataLayer.push()). Declaring the data layer again after it already exists will overwrite its previous values and can cause Google Tag Manager to behave unexpectedly.


Also added is an event attribute. You can use this to trigger an event or virtual pageview tag to send data to Google Analytics.


Note  This solution, using dataLayer.push() and a custom event trigger, is one approach to tracking an AJAX cart or checkout process, and probably the most straightforward. for an in-depth discussion of tracking AJAX processes and other options in Google Tag Manager, such as form submission and history change triggers.



Assuming that you’ve added the dataLayer.push() code described earlier, you can create the tag and trigger to use these variables to send an event to Google Analytics.


  • Create a new tag. Select Google Analytics ➤ Universal Analytics as the tag type.
  •  Use the previously created {{GA Property ID}} variable for the Tracking ID.
  • Select Track Type ➤ Pageview or Track Type ➤ Event, depending on whether you’d rather use a virtual pageview or event to measure this interaction. Fill in the Page or Category and Action fields (as appropriate).
  • Under More Settings ➤ E-commerce Features, select the check box to Enable Enhanced E-commerce Features. Check the box to use the data layer.


  •  Choose to Continue to specify a trigger for the tag.
  • Choose More, then select the New button to create a new trigger.
  • Select the Custom Event as the event to cause the trigger. 
  • Custom Event allows you to trigger on a dataLayer.push with any event name.
  • For the Event name to match, enter e-commerce checkout (which corresponds to the name in the code).
  • Select the Create Trigger button, giving the trigger a name: “Custom Event – E-commerce Checkout”.
  • Save the tag, giving it a name: “GA – E-commerce – Checkout”.


This example is specifically for checkout actions. You could create other tags for add, remove, or purchase (with different names in the event attributes that you’ll use as the trigger for those tags).