SharePoint and Google Analytics

SharePoint on-premises is a popular portal solution, used by thousands of organizations globally.

SharePoint 2010 had a built-in web analytics feature that did a decent job of showing how users interact with the portal, but Microsoft decided to remove certain web analytics features with SharePoint 2013 and onward.

Many SharePoint customers use Google Analytics, since it’s free (up to 10 mil events) and contains lots of useful reports.

Unfortunately, Google Analytics isn’t able to provide a complete picture of activity on SharePoint sites:

No PII

Google’s Terms of Service doesn’t allow customers to store Personally Identifiable Information (PII) in Google Analytics.

When users login to SharePoint to access documents / pages / information, Google Analytics doesn’t show usernames and the documents viewed by that username.

If you need to audit file access for compliance or security purposes, GA can’t show you this information.

Missing File Downloads

To track file downloads, Google Analytics requires JavaScript. If a file is directly linked from a website or in an email, Google Analytics doesn’t “see” the download.

Data Sampling

GA frequently uses report sampling for high traffic sites, which is frustrating when you need details.

No Data Protection

This primarily applies to Intranets and secure environments.

SharePoint URLs frequently contain sensitive information about customers or employees. Google stores your data in its global cloud network.

When data is stored outside your network, data protection is difficult to maintain.

SharePoint Web Analytics Solution

SharePoint On-Premises sits on top of an IIS server, and IIS creates a daily access log.

These logs can be processed by self-hosted web analytics software, which alleviates all the above issues and provides:

  • Data Protection
  • Unblockable Tracking
  • Full Visitor Details
  • Monitoring for Sensitive Files
  • Usage Cost Reporting

Angelfish is self-hosted web analytics software which provides detailed reports about how users interact with your SharePoint websites, and has a comprehensive API for populating corporate dashboards.

SharePoint Web Analytics Software.

Creating Goals in Google Analytics

Goals in Google Analytics allow you to define important events and track conversions. You can tie those events back to websites or marketing initiatives that brought visitors to your site. You can also use them to measure the relative influence of each page on your site.

In short, goals are an important piece of the puzzle if you want to know how visitors use your site and how effective your marketing efforts are.

What is a Goal?

In Google Analytics a goal is a page. It is a page that visitors will only visit after completing a desired action. For example, the thank you page after submitting a form, or the receipt page after placing an order.

A goal conversion is a unique pageview for that page. Or, to put it another way, it is the number of visits that included the conversion page at some point.

Goal Funnels

You may also define a series of required steps before a conversion, like the checkout pages in a cart before the receipt page is reached. By defining these steps, Google Analytics can construct a funnel visualization report that you can use to see abandonment rates as well as entrance sources.

You can specify that the first step in a funnel is required, which will force the funnel visualization report to ignore visits that enter the funnel at a later step.

Conversions

Google Analytics calculates three conversion rates around goals.

  1. Goal conversion rate
  2. Funnel conversion rate
  3. Overall goal conversion rate

The goal conversion rate is the number of unique pageviews for the conversion page divided by the number of visits to the site. This calculation is independent of any other goals or how the visitor got there.

This is an important distinction. If a visitor hits the conversion page without going through the funnel, a conversion will be reported. If two goals share the same conversion page, they will always have identical conversion rates, regardless of their funnels. If a visitor hits the conversion page more than once in a visit, only one conversion will be reported.

The funnel conversion rate is the number of visits that complete the funnel divided by the total number of visits that entered the funnel at any point. (Making the first step required would ignore visitors that start on step 2 or beyond in this calculation.)

The overall goal conversion rate is the sum of the goal conversion rate for goals 1 through 4. It’s a sum total, so it’s possible for this number to be greater than 100%. This is also misleading, so hopefully Google changes this in the future.

When to Use Goals

There are a number of ways to track important activities on a site. Goals are only one way to do it. They should be used when an event is important enough that you want to tie it back to specific traffic sources. If there are several similar goals (eg. several contact forms with different thank you pages), they can be consolidated into a single goal.

Goal funnels should only be used to track required steps in a process, not desired clickpaths through the site. Tracking each step in a checkout process is an ideal case, for example, because leaving the checkout process midstream represents some kind of failure. Reporting where visitors go from a landing page or how many visitors who visit the home page end up buying is not a good use of the goal funnels, because the starting points are so generic.

How to Create a Goal

Go to the profile edit screen to define a goal. Click edit next to any of the goal slots. You will be presented with the goal settings page.

Active Goal

Be sure to turn the goal on. It is off by default.

Match Type

We recommend using the Regular Expression Match type every time. The Exact Match and Head Match are converted to regular expressions on the back-end, so using regular expressions in the UI give you complete visibility and control.

Goal URL

Enter the URL for the conversion page. If you are using regular expressions, verify that what you entered matches only what you intended by copying the regular expression into a content report search box.

Remember that if your regular expression matches conversion pages for other goals, a visit to that page will register as a conversion for both goals.

Goal Name

Enter a descriptive name for the goal. If you define a funnel, this name will also appear as the name of the conversion page in the funnel visualization report.

Case Sensitive

This is off by default. You only need to turn it on if two URLs by the same name but different cases exist on your site.

Goal Value

Assigning a dollar value to each conversion allows you to see more clearly what different traffic sources are worth. It will also populate the dollar index in your Content reports, giving you a feel for the relative influence of each page toward conversion.

A goal value is intended as an approximation. Say, for example, that for every ten contact form submissions, you know that on average one of them will make a $500 purchase. That would give each conversion a rough value of $50.

Goal Steps

These are only necessary to define if you want to see a funnel visualization report showing abandonment rates. Each step should be defined as a regular expression as well. The conversion page is already defined. It should not be added as a goal step.

Required Step

As mentioned above, the first step in a funnel can be specified as a required step. This only affects how the visualization report renders and the funnel conversion rate is calculated. It’s not usually necessary to select this option. No other steps in a funnel can be marked as required steps.

Next Steps

Check out our Recommended Tools to learn about products that complement Google Analytics.

Google Analytics for Intranets

Does your company use Google Analytics to track Intranet websites? If so, there’s a slight problem:

Google Analytics isn’t designed for Intranets

Multiple Domains in Google Analytics

When your site uses multiple domains, here’s an overview of the default behavior for Google Analytics (GA) cookies:

  • A user visits your website (e.g. www.analyticsmarket.com), and the GA tracking code creates a set cookies.
  • The user clicks a link that takes them to a different domain (e.g. www.actualmetrics.com).
  • The GA tracking code on the second domain can’t read the cookies created by the first domain. A new set of cookies will be created (i.e. a new visitor) and the visit will be attributed to the referral from the first domain (called a self-referral).
  • As the visitor continues to move between domains, two visits and two visitors will be counted.

Parenthetically, a similar thing can happen with multiple subdomains, but the solutions are different.

The Principles of Cross-Domain Tracking

In order to track a visit seamlessly across multiple domains, you need to make two coding changes.

  1. Modify the basic tracking code on every page of each domain
  2. Add code to every link where the destination URL is on a different domain

If you want them tracked in the same profile, each of the domains should use the same UA number in their code.

These changes will pass the visitor’s cookie information to the other domain where they will be duplicated. From Google Analytics’ perspective, it will be one set of cookies because they will carry identical information. In reality, you will be creating a duplicate set of cookies on every domain.

This is worth clarifying. If a link on your site sends a visitor to another domain and you want that domain to be counted as part of the same visit, you must tag the link. It doesn’t matter how many domains you have; this principle applies to every link on every site where the domain changes. The only time it’s not necessary is if the link sends the visitor to a site you’re not tracking.

The emphasis might seem unnecessary, but this fundamental principle is commonly overlooked. Incompletely coding for cross-domain tracking is one of the most common reasons for self-referrals in reports.

Change the Tracking Code

Every domain that needs to be tracked as part of the same visit will need three changes made to the tracking code. These changes are made to the code on every page right before the _trackPageview() method.

_setAllowLinker()

This method must be set to true: _setAllowLinker(true)

This method essentially tells the code to look for cookie information coming from the other domain. When it sees it, it will duplicate the cookies for the current domain.

This method also enables the code that must be placed on each link. This is why it must be placed on both sending and receiving domains.

_setAllowHash()

This method must be set to false: _setAllowHash(false)

By default, the tracking code ties a set of cookies to a domain by making a hash of the domain name and placing that value in the cookies. If your site utilizes multiple domains, though, this will prevent the code from accepting the other domain’s cookies because the hash won’t match up. Setting this method to false just inserts the number 1 into the cookies in place of the hash.

_setDomainName()

This method will set the cookie path to the domain root or to a specific subdomain, depending on what you specify. It’s best practice to set this for each domain when doing cross-domain tracking.

Adding Code to Each Link

To do it manually, add an onClick event (or equivalent) that executes the _link() method. You must pass this method the full URL that the link redirects to, and it must be followed by return false if it’s in an anchor tag. This gathers the visitor’s cookie information and appends it in a query string to the link URL; it then overrides the href value and redirects the visitor to the newly constructed URL.

Adding Code to Forms

If it’s not a link or button, but a form that sends the visitor to a new domain, Google Analytics has a solution for that, too. It’s the _linkByPost() method. This method works the same way as _link(), but it gets added to the form tag as an onSubmit event.

Adding Code to Frames

If you have an iframe that shows a page on another domain that you have code on, you will need to change the src attribute to include the visitor’s cookie information using the _getLinkerUrl() method. This accepts a URL, just like _link() and it returns the URL with the addition of the query parameters.

Sometimes it might be necessary to replace the src attribute dynamically with the onLoad event instead.

Adding Code Dynamically

It’s possible to create a script on your site that would dynamically tag each link or form. This could be done server-side with some type of search and replace function, or it could be done client-side with JavaScript, for example, to dynamically add onclick events to each outbound link.

Another possibility for the _link() method in an anchor tag is to pass it a dynamic parameter (eg. this.href) instead of manually adding each URL.

Troubleshooting Cross-Domain Tagging

After you’ve added all this code, expect to see a drop in the number of visits and visitors reported. Incorrect implementation inflates visit counts. The other biggest indicators that you were successful are the traffic source reports.

Referrals

The obvious place to look first is the referral reports. Change the date range to include only the time after the code was implemented. Then go to the Referring Sites report. Look for any of your own domains. If you see any, click on the top one. Then change the graph to “Compare to Site” and look at what percentage of overall traffic this constitutes.

It’s not unusual to see a few self-referrals, even when the code is on the site properly. However, if it’s more than a few percentage points, you may have missed some pages or links.

Direct Traffic

Direct traffic is really traffic that the tracking code couldn’t identify a source for. Sometimes different browsers under different circumstances will track referrals as direct traffic. If the percentage of direct traffic seems fishy, check the landing pages for it. If those landing pages are unusual URLs, or if they are URLs you know are unlikely to be referenced by third-parties (eg. the beginning of a checkout process), you may have a problem.

Conversions

Another indicator that something is wrong with your cross-domain tracking is if all (or nearly all) of the transactions on your site are attributed to direct traffic and/or a referral from your own site. The missing code is most likely on one of the pages required during the conversion process.

Finding the Gaps

If there are indications that your cross-domain tracking is not set up completely, start by visiting the pages reported as referring sites. Search through the source code to make sure the _link() method is called consistently.

If the _link() method is everywhere it should be, click on a few of the links. When you reach the next page, look in the address bar at the URL. It should contain a long query string with several query parameters that start with __utm. If it doesn’t, confirm that the tracking code on each page has been modified and that the _link() method is always followed by return false. Check for syntax errors in the JavaScript.

If all of your own code is set up correctly, then it’s possible that the destination page on the other domain is stripping out the extra query parameters. If it’s doing a redirect, that is almost certainly the case.

Next Steps

Check out our Recommended Tools to learn about products that complement Google Analytics.

Troubleshooting Google Analytics Code

One reason that Google Analytics has gained such rapid popularity is its ease of implementation. Google made the installation process easy enough that non-technical website owners have been able to use it.

For most websites, simply copying and pasting the code that Google provides is sufficient. It’s important to be able to test that code implementation immediately, though. Sometimes it’s even necessary to go back into the account to grab the code again.

Does your company keep a backup of your Google Analytics data? If not, start today.

Where is the Code?

When you first create a view, you are presented with a screen that instructs you to copy and paste the code into your website. Below those instructions is a text box with JavaScript code.

Where Does the Tracking Code Go?

The tracking code needs to be pasted into the HTML code for each page of your website. If you use a CMS like WordPress / Joomla / Drupal, there is likely a plugin or module you can install that will insert the code automatically. If not, your web server probably has a global footer template that affects every page of your site.

Paste this code into the footer directly above the closing head tag. That said, the code loads asynchronously and can be placed anywhere in the page.

Exceptions

The standard implementation works for most websites. There are a few scenarios that require some modification to the tracking code before you put it into your site. If your site is an ecommerce site, uses multiple subdomains or if it spans multiple domains (e.g., during a checkout process), you will need to make some changes.

Besides these required changes, there are some more advanced modifications that can be made using built-in JavaScript methods that are outside the scope of this article.

Testing the Implementation

Google Analytics may display a warning icon next to your profile indicating that the code is not set up correctly until it begins to receive data. Data can take up to 24 hours to populate, but we’ve never seen it take that long! The warning icon will go away once data begins to feed into the account. Click a few pages on your site and open the real time reports to see your traffic.

At this point, you may want to check a few things to make sure your code is implemented correctly.

UA Number

Before anything else, make sure the UA number in the code is the same as the UA number for your profile. View the source of a page on your site, search for “analytics.js” (no quotes), and look for a string that looks like this:

(“UA-39341144-1”)

That UA number should be identical to the one for your profile. Confirm by going to the list of your profiles in your Google Analytics account. The UA number is listed next to each one.

Cookies

Google Analytics sets a few on each visitors’ machine by default. The cookie names begin with _ga. Use the browser console (press F12 on your keyboard) to view cookies created by your website – if the _ga cookies are missing, the tracking code isn’t loading correctly.

/collect Request

The tracking code sends all of the information to your Google Analytics account via a request to www.google-analytics.com/collect. It will have a long query string (question mark followed by variables) that contains all the pageview and visit information. You can use the Chrome, Firefox, or Internet Explorer developer console (press F12 on your keyboard) to see if the file is being requested. If it is, your code is working fine. It’s gathering all the information, setting cookies and sending it all to your account.

If the /collect request is not being made, it means the tracking code isn’t loading correctly.

If you can see that analytics.js is being requested from the same server but not __utm.gif, it indicates a problem in the second block of JavaScript. If neither are being requested, it indicates a problem with the first block of JavaScript. In either case it’s usually a syntax error. Usually this is the result of modifications to the code that were done incorrectly or the code being reformatted by an email client. If you copy and paste the tracking code into an email, it may get reformatted when it’s sent. If you must email the code, try copying and pasting into a text document and attaching that to your email.

Next Steps

Check out our Recommended Tools to learn about products that complement Google Analytics.

Google Analytics is Slow

Despite its strengths, Google Analytics can sometimes be slow. It’s not uncommon to hear users complain that Google Analytics is loading more slowly than they would like. These complaints fall under two categories: the interface itself is not responding quickly, or the data is not updating fast enough.

The report sampling feature is intended to combat slow report loading, although some users (like analysts) don’t want to see sampled data. If sampled data is an issue for your environment, we recommend making a backup copy of your Google Analytics data and processing it with Angelfish Software.

Report Updates

Officially, Google Analytics processes data every few hours but it can lag by 24-48 hours. From our observations, updates tend to come every hour or two. But a few metrics, like unique users, are sometimes updated less frequently.

There is no official word from Google on how frequently they update or plan to update data. You can increasing the frequency that your reports update by signing up Google Analytics Premium ($150K/year and up). The good news is that Google Analytics updates have become more frequent since it was first released, and the platform is significantly more stable with each passing year.

Slow Interface

Sometimes the pages and reports just load slowly. Some users have noted an irony when Google Analytics is slow on Chrome, Google’s new browser.

It’s possible that you are requesting data from Google’s servers at a time when they are being overloaded. If this is the case, the issue is usually very temporary and doesn’t last for more than a few minutes. Severe latency issues are almost always caused by to a user’s own machine or network, not Google’s servers.

Processing large amounts of historical data can be a slow process. If you are noticing latency issues while loading reports for a large time range (especially if you have a high traffic site), this is not unusual. You can sample your data to speed this process up in the future, but otherwise there’s not much to do to get around it.

If you are not requesting large amounts of data, it may be an issue with your own browser or computer. Here are some other things to check:

  • Check to see if other websites load quickly. If they don’t, you may have a network issue.
  • Try another browser.
  • See if any other programs on your system are running slowly.

When all else fails, just wait a few minutes and the problem will soon resolve itself. Google has one of the most stable and redundant server networks in the world.

Next Steps

Check out our Recommended Tools to learn about products that complement Google Analytics.

Understanding Web Analysis

Web analytics can be really, really cool. But you have to understand what its limitations are and how to use it.

Let’s give an example: a good web analytics tool is like a powerful microscope. Not like one of those cheap microscopes you used in elementary school to look at thread. It’s like one of those neat scientific microscopes you see in labs on CSI. Now, as neat as an expensive microscope is, it won’t do you any good if you’re trying to watch a comet. For that matter, it won’t even show you what’s across the room.

Web analytics tools are limited. They are designed to measure only certain types of data. This data can be really useful if you know what you’re doing. If you don’t, it can be useless. Like trying to view a comet with a microscope.

What it is

What exactly does a web analytics tool measure? To put it simply, it gives you an estimate of what happened on a website.

With few exceptions, web analytics tools only capture most of the activity on a website. Generally, the sample is quite high, like 95%, but it is only a sample. A survey, if you will.

The Web is anonymous by nature. Most web analytics tools try to cut through the anonymity, and do so with surprising success. To date, analytics tools rely primarily on some combination of log files, cookies and JavaScript. These can be manipulated or masked in one form or another by the visitor. Sometimes certain browsers or mobile devices will handle them in an unexpected way. Sometimes the way the tool calculates an element of a visit won’t reflect reality–or at best it will be counterintuitive. Not a single web analytics metric is 100% accurate.

In short, some visits are missed, some are misrepresented, some data is flat wrong. And there often isn’t a way to discern which pieces are wrong or missing.

What it isn’t

Hopefully you can see now why web analytics tools cannot be used as accounting tools. That is, unless you enjoy the adventure of never knowing exactly how far off your reported revenue is from reality.

Web analytics reports also are not a census of your visitors and their demographics. There is very little demographic information that can be gathered without the visitor explicitly giving it to a website.

Finally, web analytics is not a crystal ball. It doesn’t read minds. It can’t tell you why a visitor did something. It can only tell you what they did.

Purpose

Web analytics tools spot trends and correlations rather than exact figures, and are excellent at helping us evaluate the impact of both the site itself and the marketing initiatives that bring visitors to the site. If you can identify the visitor actions that indicate a successful visit and then tie that to their original traffic source, you can go a long way in evaluating what works and what doesn’t work.

Web analytics is good at identifying the roadblocks to conversion. Which pages on the site have a high abandonment rate? Which seem to be most influential? Which marketing sources bring only confused visitors? Which pages send all your visitors to the contact page to write nasty emails?

Remember: web analytics tools are intended to give you a big picture of what is happening on your site.

Next Steps

Check out our Recommended Tools to learn about products that complement Google Analytics.

Google Analytics for Intranets

Does your company use Google Analytics to track Intranet websites? If so, there’s a slight problem:

Google Analytics isn’t designed for Intranets

Start Analyzing Your Google Analytics Reports

The ultimate goal of web analytics is to improve your site and marketing. To do this, you need to know what’s working and what’s not. And if something isn’t working, you need to understand why not and how you should begin optimizing it. In other words, you need to come away from your analysis with a list of to-do’s.

Many Google Analytics users read the reports without knowing what to do with them. For most people, reports seem to satisfy curiosity more than inform any kind of action.

Having clean data and actionable reports is one thing, but it is another matter altogether to know how to read them and respond. These articles will help you analyze your reports. They will step you through both fundamental and advanced web analytics concepts.

Next Steps

Check out our Recommended Tools to learn about products that complement Google Analytics.

Google Analytics for Intranets

Does your company use Google Analytics to track Intranet websites? If so, there’s a slight problem:

Google Analytics isn’t designed for Intranets

Backup Your Google Analytics Data

Google Analytics is used by millions of businesses. Many of these businesses rely exclusively on Google Analytics for web analytics reports, yet don’t keep a backup copy of their GA data. This isn’t a very smart strategy.

It’s easy to keep a backup copy of your Google Analytics data. You simply configure your GA tracking code to make a copy of the tracking data sent to Google – the copy is stored in your web server log file.

The primary reason to keep a backup copy of anything is to be able to recover from unexpected issues. Google Analytics is no different – consider the following:


1) Business Continuity

Let’s be honest: data loss isn’t a major concern with Google Analytics because Google’s redundant, geographically distributed datacenters will (probably) not simultaneously explode. But consider the following:

  • What happens if Google deletes your historical data?
    (see Data Retention Policy, below)
  • What happens if your agency locks you out of your account over a billing dispute?
    (it happens, unfortunately)
  • What happens if your company can’t use Google Analytics anymore?
    (see Privacy Regulations, below)

The easiest way to prepare for (and overcome) the above scenarios is to start keeping a backup copy of your GA data.


2) Verify Data Collection

Google Analytics is a SaaS (Software as a Service) product. The data shown in the reports is collected from website visitors across the world, and the only time you see the data is when you view the reports. Here’s why this is a problem: you might be violating GDPR / privacy regulations and not know it, because you aren’t seeing the data sent to Google Analytics.

If you have a backup copy of the tracking data sent to Google, you can verify it doesn’t contain any PII (Personally Identifiable Information).

Referrer spam is another issue you’ll encounter when verifying data. This happens when companies send bogus traffic to your Google Analytics account. It’s a cheap promotional stunt – the hope is that you’ll notice a strange Source or Event and ask “what website is this?” and visit it.

One of the fun things about referrer spam is that it generally originates from a single IP address. When you have a backup copy of your GA tracking data, you also see IP addresses…which you can use to Filter out future referrer spam.


3) Data Retention Policy

Google announced a new Data Retention policy in 2018. Once a month, old data is deleted from your Google Analytics account. Once this data is gone you still have aggregate reports (i.e. session totals), but you lose the ability to view ad hoc reports on the data, like segments and custom reports.

If you have a copy of your GA data, you can process it with an on-premises web analytics software solution and keep it around as long as you want.


4) Privacy Regulations

Internet Privacy is a hot topic among legislators. In addition to GDPR in Europe, there are broad usage restrictions for Google Analytics in industries like healthcare, finance, education, and government/military. Looking ahead, Internet Privacy regulations are expected to increase in the coming years.

We can have an exhaustive discussion about this topic but we’re going to keep it brief. Here’s the salient point: if a new law restricts your company from using Google Analytics, you will be better prepared if you have a backup copy of your GA data.


5) Fix Mistakes

C’mon, admit it – you (or someone you know) created an incorrect filter and didn’t realize the mistake until a big chunk of new data was missing. It’s ok – we’ve all done it. 🙂

Google Analytics applies configuration settings before your data appears in the reports. If you make a mistake, you can’t fix any data that was previously processed. But if you have a backup copy of your Google Anaytics data, you can reprocess the data in another web analytics software program and eliminate the mistakes for reporting purposes.


6) See Details Not Shown in GA

Google Analytics reports don’t provide many details. You can use segments and filters to isolate blocks of traffic, but you can’t see details about individual visitors. Plus, the Google Analytics ToS (Terms of Service) doesn’t allow you to store PII (Personally Identifiable Information).

If you keep a backup copy of GA data and process it in a different web analytics product, your reports won’t be governed by the same ToS. This means you can see visitor details like IP address, individual clickpaths, usernames, and PII.

What Next?

Hopefully you now understand the value of keeping a backup copy of your GA data.

But once you have the raw data, there’s another question to answer: how are you going to get the data into the hands of your business users in a format they can actually use? Specifically:

  • Where to store it?
  • How to sessionize it?
  • How to visualize it?

We recommend using Angelfish Software to make sense of your Google Analytics backup data. Angelfish can process this data and create detailed reports. Easy!

Cookies in Google Analytics

Cookies are at the heart of Google Analytics. Not the chocolate chip-filled ones, but browser cookies that store session data and provide a critical link in tracking return visitors and attribution.

There is shockingly little documentation on the cookies created by the tracking code, what they store or how they work. But they are so integral to the Google Analytics reports, it is important to lift the hood and understand exactly what is going on.

***Update: Universal Analytics uses a different cookie “recipe” than the one outlined in this article.

Flavors

First, to dispel some confusion. Cookies are used across the wide expanse of the Interwebs. You might have hundreds of cookies stored on your computer right now. They are small text files stored by the browser and can only be read by the website that created them. Cookies are browser-specific. In other words, if you are using multiple browsers on a computer, they will each have their own set of cookies.

If I am visiting www.mysite.com, and it sets cookies on my machine, those are first-party cookies. If, however, a script from www.annoying-popup-ds-world.com sets cookies on my machine, these are third-party cookies. The difference is in which domain the cookies are tied to, and therefore, which domain can read them.

Google Analytics uses first-party cookies. One primary reason for this is that third-party cookies are often blocked by browsers. It does this by setting cookies with code that is called on your site, the _trackPageview() method.

Cookies come in two more flavors: session and persistent. Session cookies are deleted when the browser closes. Persistent cookies have a defined expiration date. The browser will only delete them when they expire.

How Google Analytics Uses Cookies

Certain reports in Google Analytics rely heavily on cookies. If a visitor deletes or blocks their cookies, information for that visit or visitor will be misinterpreted or lost.

Unique Visitors

Cookies are a major component of unique visitor tracking. They tie all the activity of a visitor into a single visit, and are used to determine when a visit ends.

Activity

Cookies store vital information about each visit. They store the start time of the current visit and keep track of how many pages have been viewed so far. If a visitor closes the browser or is inactive for too long, the cookies will indicate that the visit has ended.

Cookies store the date and time of the visitor’s first visit (allowing for calculations of how many visits it took to convert). The total number of visits from the visitor is stored in cookies, too.

Traffic Source

Cookies are the main vehicle for attributing visit information and conversions to specific marketing campaigns or traffic sources. Each time the visitor comes to the site, the code stores new referral or campaign variable information in the visitor’s cookies.

Dissecting Google Analytics Cookies

Google Analytics uses several cookies to record all of this information. The most common are covered here. The expiration dates for each cookie may be customized with built-in GA code.

All of the cookies store a domain hash that ties them to the same site. In the case that cookie information changes during a visit (e.g., a user-defined variable gets changed from “Prospect” to “Customer”), Google Analytics will attribute the entire visit to the last cookie value.

__utma
This is the main way Google Analytics tracks unique visitors. Stored in this cookie is a unique visitor ID, the date and time of their first visit, the time their current visit started and the total number of visits they have made.

The __utma cookie is a persistent cookie that expires in two years. With each new visit, the expiration date is refreshed.

The expiration time can be customized in the tracking code.

__utmb
This is how Google Analytics decides whether a visit has timed out and also how deep a visit has gotten. It stores the number of pageviews in the current visit and the start time of the visitor’s current visit.

The __utmb cookie is a persistent cookie that expires in 30 minutes. Each pageview refreshes it.

The expiration time can be customized for each site (or page).

__utmc
The __utmc cookie is the only session cookie used by Google Analytics. Its only purpose is to register that the visit ended if the browser gets closed.
__utmz
This is the traffic source cookie. It contains all of the traffic source information for the current visit, if it was different from the previous visit. If no traffic source information can be found for the current visit, the cookie is not changed. This is the way that Google Analytics attributes visit information, including conversions and transactions to a traffic source. It does not contain historical information for previous sources.

This is a persistent cookie with a catch: it expires in six months and is only refreshed when the traffic source changes. Every other cookie is refreshed with each pageview. The impact of this is that a banner ad that brings a visitor to your site will get the credit for all future direct visits for up to six months. After six months, if there have not been visits from any other source, the cookie will expire and start to attribute information to direct visits.

The expiration window can be customized in the tracking code.

__utmv
This is the user-defined variable cookie. Developers can segment visitors by custom variables by calling a native JavaScript method. This new variable gets stored in a persistent cookie which expires in two years.

Sending it to Google Analytics

Finally, all of this cookie information is sent to Google Analytics via the __utm.gif request that it makes with each pageview. When Google Analytics processes data, it relies on this cookie information (among other pieces of data in the query string) to populate your reports.

Next Steps

Check out our Recommended Tools to learn about products that complement Google Analytics.

Tracking Emails With Google Analytics

When you send out marketing emails or occasional newsletters, you can use Google Analytics to track the effectiveness of your emails. You can also use it to determine how to format your emails and what types of information to include.

Tracking Visits from Emails

Tracking visitors that come from emails is simple enough if you use campaign tracking for each link. Without taking this step, visits from emails will be recorded inconsistently. Some will show up as a referral from a webmail address, like mail.yahoo.com. Others will be reported as direct traffic. Using campaign tracking, however, you will be able to analyze your email traffic in great detail.

All of the links in an email ought to be tagged with campaign variables, specifying the campaign, the source and which link was clicked.

What should each value be?

The trickiest part of tagging links in an email is coming up with a consistent naming convention for each variable. None of the data should be redundant. You need to categorize each link in each email so that the information reported is useful. Here are some guidelines:

Campaign Name
This field should contain some of the most specific information about what kind of email this is. It should give some feel for the content of the email. What is your main message or pitch or objective? Is the message seasonal? Will it be a similar message throughout several emails? Is this part of a broader campaign to talk about a new product? If so, you may use the same campaign name for some of your emails, cpc ads and banner ads so that you can get a sense of how well the overall campaign is performing.

A common mistake is to duplicate information in this field from other fields. For example, a bad campaign name would be “Winter 2009 email” because email is the medium, and it restricts your ability to reuse the same campaign name for other mediums.

Campaign Source
Campaign source for an email should not be “email”. Email is the medium of this communication, not the source. Instead, think of source as a label identifying where the email came from or the kind of email it is. For example, if you send out weekly newsletters, this might be “newsletter”. If you use a third-party for some of your emails, you might use that third-party’s name. If you send announcement emails outside the normal flow of newsletters or ads, this might be labeled “announcement”. This should not contain information already in the campaign name or medium fields.

In choosing a source, think in terms of broad categories so that you can do roll-up reports for each type of email. You may want to know how your announcement emails perform compared to your regular emails listing current specials. That would help you determine whether the announcement emails are worthwhile or perhaps whether the regular emails need to be reformatted.

Campaign Medium
Medium should be email. This field should be used to compare broad categories of marketing you do (or may do in the future), like emails, cpc ads, postcards, etc. You should not put information in this field that you have in other fields. For example, if your source is “newsletter”, the medium should not be “email newsletter”. That limits your ability to do roll-up and drill-down reporting.
Ad Content
The ad content field is where you can start to learn exactly how you should be formatting your emails. Tag each link in an email with a different ad content so that you can see which links get clicked on the most, and how traffic from each link compares once the visitors are on the site. Use this field to describe the type or location of the link. For example, label the company logo that shows up on each email as “logo”, or the main picture in an email as “main picture”. If you notice a difference in how links perform against each other, you may decide to change how your emails are laid out, or you may start to pay more attention to which pictures or phrases you use.
Keyword
This field should never be used in an email campaign. It is reserved for campaigns using paid keywords. Any information in this field gets reported in the Keywords report under Traffic Sources, alongside all the search engine traffic.

Tagging your emails like this will give insight into how your emails compare to other types of marketing, how specific messages work across all mediums, which types of links work best in your emails, etc.

Next Steps

Check out our Recommended Tools to learn about products that complement Google Analytics.

Google Analytics for Intranets

Does your company use Google Analytics to track Intranet websites? If so, there’s a slight problem:

Google Analytics isn’t designed for Intranets