In my opinion, it depends. It depends on your analytics needs.

We’ve worked with plenty of “enterprise” class organizations that were new to web analytics. They had very simple needs and GA met most of them easily. We’ve also told companies that GA is not right for them because it did not fit their core needs.

Your organization may be different. You may need a tool that integrates with ODBC data sources, something that GA doesn’t do very well. If that’s the case then you might need to go with a different tool. But again, it all depends.

But the point of this post is not to debate GA’s “enterpise-y-ness”, but to address some of the common issues that we usually see during an enterprise installation.

Issue #1. Tracking All Sites Logically

Large organizations tend to have more sites, and more sites mean more data. Collecting the data in an organized fashion, that allows room for growth and appropriate access for users, takes time and planing.

During an enterprise implementation we usually create a series of accounts and profiles that segments the data based on business logic and access needs. We create a data hierarchy that provides high level aggregate tracking across the entire online experience (i.e. roll-up reporting) and detailed tracking for each individual property.

Let’s consider the websites for Major League Baseball. Each team has their own site located on a subdomain. There is also an MLB store and different micro sites dedicated to things like the All Star Game and the World Series.

Lots of content on many different sites. While the exact implementation solution will depend on their specific needs, it probably involves collecting all the data in a single profile for roll-up reporting and then creating profiles for each team and micros site for detailed reporting.

Issue #2. Unique Visitors

Tracking lots of domains usually leads to an issue with unique visitor tracking. GA uses a first party cookie to identify each visitor. This means that if a visitor visits 3 different domains they will receive 3 different cookies and appear as three different unique visitors.

Now, I know GA has a cross domain tracking feature. But what happens if an enterprise wants to know the unique visitor count across 50 web properties? Installing cross domain tracking on that scale is a huge task. In fact, it’s a pain in the ass.

Many of the clients that I’ve worked with have compromised and ignored unique visitor tracking.

You may be different. Unique visitors may the one critical metric that you can’t live without. Could you use GA? Maybe, but you should carefully weigh the implementation needs vs. your analysis needs.

Issue #3: Page Tagging

When I first started working with GA I never thought that tagging pages would be an issue, but it is. It’s not so much a technical issue as it is an organizational issue. Big companies can have so many sites with some many nooks and crannies. It can take a lot of work to identify every site, find an owner and then get the tags placed in the appropriate place.

And let’s not forget non-HTML pages. Tracking non-HTML content with Google Analytics can be a huge challenge. You can’t slap a JavaScript Tag on a PDF. When we work with large organizations we usually help then develop an automated click tracking script. This takes more time and more effort and doesn’t always work (usually due to page rendering delays).

Issue #4. URL Structure

This is probably one of the most difficult challenges we face when working with large sites that have hundreds of thousands of pages. GA will only track 50,000 unique URLs per day. While this is completely adequate for most sites “enterprise” sites can exceed this limit, especially if the site is content based (think about a some of today’s largest community sites, they have forums, blogs, and tons of user generated content).

What happens when you fill GA with 50k unique URLs in a day? You start to see ‘(other)’ in your content reports and you can no longer identify which pages visitors are viewing on your site.

To resolve this issue we usually need to create some type of bucketing strategy to ‘roll up’ pageview data into different content categories. This is normally done by matching requested URL patterns at the server level, and then generating a ‘virtual’ pageview in GA.

Sometimes we segment the data into different profiles, thus giving us more ‘buckets’ to store the data.

Again, the exact solution depends on many different factors, but this issue can be mitigated with some effort.

Issue #5. Campaign Tracking

This is a problem for everyone! I find very few clients whoa are diligent about tracking their marketing campaigns using link tagging. A general rule of thumb, the bigger the client the more challenging it is to track all online campaigns. Why?

Big organizations have different people running different campaigns. Many times they’re using one or more agencies to help run their campaigns. Getting everyone to use a cohesive link tagging strategy is a lot of work due to the sheer number of people that are involved. This is more of a training/process issue rather than a technical issue.

Wrapping Up

If you’re an enterprise organization, or consider yourself an enterprise organization, don’t discount GA without taking a hard look at your real analytics experience and your needs. GA might just work for you.

If you do decide to use GA don’t expect to slap the tags on your site and finish the configuration in a week. Like every tool out there, it takes time and planning to get things right.

Do you have experience with GA in a large, “enterprise” environment? Leave a comment and share your thoughts.

“Enterprise” Google Analytics is a post from: Analytics Talk by Justin Cutroni

Related posts:

1. Google Analytics Configuration Mistake #3: Third Party Domains
2. Google Analytics: How to Tell When Something is Wrong
3. Tracking Dynamic Sites With Google Analytics

Each time a visitor visits your site the Google Analytics Tracking code updates this cookie with the appropriate campaign information. When the cookie is updated GA discards the previous campaign information. As a result GA only tracks the current campaign information, not previous campaign information.

With that said, there is a ‘pecking order’ regarding which activities will overwrite the the data in the campaign tracking cookie. Let’s review how GA buckets your traffic in terms of referral information:

• Campaigns: links that you have tagged with campaign information
• Referrals: untagged links on other web page
• Direct: people who type your URL into a browser
• Organic: organic search engine traffic

Here is how GA updates the campaign tracking cookie based on referrer:

• Direct traffic is always overwritten by referrals, organic and tagged campaigns
• New campaign, referral or organic link that brings a visitor to the site always overrides the existing campaign cookie

Here’s an example. A visitor visits your site from a newsletter with tagged links. They look around and decide to leave. When they leave your site the campaign tracking cookie will persist and indicate that they originated from the newsletter.

The same visitor decides to come back the next day and types your URL into the browser. The campaign cookie will still indicate that the visitor arrived via your newsletter because the second visit was a direct visit, and direct traffic does not overwrite existing campaign information.

With that all said, you can configure GA to NOT overwrite the campaign data that is stored in the tracking cookies. This let’s you identify the first campaign that brought the visitor to your site. Here is the link:

http://www.google.com/support/analytics/bin/answer.py?answer=27247

However, this technique does NOT prevent the Google Analytics Tracking Code from updating the campaign cookie if a visitor arrives by organic search or untagged referral link. This technique can only be used to prevent tagged campaign links from overwriting previous referral information from a tagged campaign link.

So how do you get around this? Well we’ve come up with a hack that we’re using with a few of our clients. The goal is to store all referral information about a specific visitor across all of their visits so we get a better understanding of the sales cycle.

The Google Analytics Tracking Code re-writes the data in the campaign tracking cookie every time the visitor hits the site. We need a mechanism that can store data across multiple sessions and would only update the referral data and not overwrite it. To do this we wrote some JavaScript that uses the custom segment functionality to track the visitor’s referral information.

Here’s a brief outline for what the JavaScript does:

• When visitor lands on the site check the previous referral information.
• If there is no previous referral info then gather the referral info and store it in a custom segment using utmSetVar()
• If there is previous referral info, then UPDATE the custom segment to include the current referral information

While this isn’t an ideal situation it does help. Using the User-defined report we can identify conversion rates for the various combinations of referral information that drove the visitor to your site during the sales cycle.

Obviously this takes some technical know-how. But if you’re working with a client, and the client wants to know EVERY step in the process then this is a hack that can help.

So there you have. Some information about how Google Analytics tracks referral information. I think there are two key things to remember.

1. Not all referral information is created equal
2. You can configure GA to let your campaign information persist

You may also be interested in the series I wrote about Campaign Tracking with Google Analytics:
Google Analytics Campaign Tracking Pt. 0: An Overview
Google Analytics Campaign Tracking Pt. 1: Link Tagging
Google Analytics Campaign Tracking Pt. 2: The EpikOne Link Tagging Tool
Google Analytics Campaign Tracking Pt. 3: Reports and Analysis

Thoughts? Questions? Leave a comment.

How Does Google Analytics Track Conversion Referrals? is a post from: Analytics Talk by Justin Cutroni

Related posts:

1. Track your Google Analytics Changes
2. Tracking Offline Advertising With Google Analytics
3. How Google Analytics Tracks Third-Party Domains

1. Compare your GA data to another source

Comparing the data in Google Analytics to the data in another application is helpful. I prefer to compare GA data to data from other types of applications BUT not other web analytics applications. A transactions system, a CRM system or any other system that collects data can be used. If the data is off by more than 10% to 15% then there is probably a problem.

Today I was working with a client that had a large discrepancy between the number of goals in GA and the number of ‘goals’ in their internal order system (60% delta). After looking at the profile we identified an issue with their configuration which was causing the problem.

I don’t like comparing GA data to that of another web analytics application. Why? Primarily because each application tracks data in a different way. This makes it very difficult to identify if there is a problems with Google Analytics or if the discrepancy is due to the differences in the applications.

2. Look for ‘(other)’ in your reports

If you see a line item for ‘(other)’ in some of your GA reports (like the Top Content report) then there is something wrong with your profile.

Each Google Analytics account has a data storage limit. That means that your account will only hold so much information. Once you reach that limit Google Analytics will continue to collect data BUT it will be recorded in a nondescript record named ‘(other)’.

Here’s an example. Let’s say that GA limits you to 10,000 records in each database table*. One of those tables records unique pages. Your website is huge, it has 200,000 unique pages. Obviously something has to give. You can’t fit 200,000 records into a 10,000 row table.

What happens is GA tracks the first 9,999 unique page views correctly. When GA tries to record the 10,000th page view it stops because it knows that it’s about to record the 10,00th record and that will be the last record in the database table. Rather than record the data, GA creates a ‘bucket’ to catch all subsequent data. This bucket is called ‘(other)’. So, for every unique page greater than 10,000, the counter for ‘(other)’ is incremented by one. GA is still tracking the total number of unique pages, it’s just not identifying them uniquely.

This means that perfectly valid page views will be missing from your reports. It also means that any features, like goals or funnels, that depend on these page views will also malfunction.

If you see ‘(other)’ in your reports check your profile configuration. You’re probably filling your database with bad data. You may need to exclude some query string parameters. Read Google Analytics Configuration Mistake #2: Query String Variables or the official Google Analytics help docs.

* DISCALIMER: I have no idea how much data a GA account can hold. I picked the number 10,000 randomly.

3. All your e-commerce referrals come from your domain

If you have an e-commerce website, and all your transaction referrals are from your own domain, then there is a problem. Or, if you have e-commerce data but no values for $Index then you may have a problem. These are two symptoms of the same problem.

I usually see this problem when people have not followed the configuration instructions for a third-party shopping cart. The GA tracking cookies are not transferred correctly between the two sites causing the report data to be incorrect.

You can read the official Google Analytics support instructions or read my post about third party domains.

One more thought about Google Analytics data…

Don’t freak if there are huge chunks of data missing from your Google Analytics reports. From time to time the Google Analytics team updates the GA system. This can cause your reports to loose data. Be assured that your data is still there. The system is probably just slow in processing the data.

If Google is NOT updating they system then you should worry :)

Google Analytics: How to Tell When Something is Wrong is a post from: Analytics Talk by Justin Cutroni

Related posts:

1. Google Analytics Configuration Mistake #2: Query String Variables
2. Track your Google Analytics Changes
3. Making Google Analytics Content Reports more Readable

Here’s my list of the top mistakes made when working with a third party domain:

1. Missing GA tracking code

This is a simple step that many people forget. Make sure that you add the GA tracking code to all the pages on both domains. If the code is missing then the visitor will not be tracked. If the third party site does not allow you to add JavaScript to the pages then you may be out of luck.

Remember, the JavaScript code snippet needs to be modified slightly to look like this:

<script type="text/javascript">
  _uacct="UA-xxxx-x";
  _udn="none";
  _ulink=1;
  urchinTracker();
</script>

Don’t forget to replace “UA-XXXX-X” with your GA account number.

2. Missing __utmLinker() or __utmLinkPost()

The technology that GA uses to track visitors between multiple domains depends on two JavaScript functions: __utmLinker() and __utmLinkPost(). Both functions are included in the urchin.js tracking code. These functions transfer the GA tracking cookies from one domain to another via the URL. This is vital to identifying unique visitors and connecting which marketing activities lead to conversions.

Why do we need to transfer cookies between domains? Well, that’s a bit complicated and pretty technical. Think of it this way. Each visitor has their own set of cookies. For security reasons, we need a mechanism to transfer the cookies from one domain to the other. __utmLinker() and __utmLinkPost() are the mechanisms we use to transfer the cookies from one domain to another.

If you move visitors from one domain to another using regular links then you need to modify those links with the __utmLinker() function. Here’s an example:

<script type="text/javascript">document.write('
Log in Now');
</script>

<noscript>
Log in Now
</noscript>

If you move visitors between domains using a form, then you need to modify said form using __utmLinkPost(), like this:

<form action="http://www.mysite.com/process.asp" onSubmit="javascript:__utmLinkPost(this)">

How do you know if you’ve done it right? Go to your site and click on a link or form that drives the visitor from your site to the third party site. When you arrive on the third party site look at the URL in your browser’s location bar. You should see information like this:

http://www.cutroni.com/blog/index.htm?
__utma=var1&__utmb=var2&__utmc=var3&__utmv=var4&utmz=var5&__utmk=1232

The query string variables are the actual tracking cookies from the original domain. __utmLinker or __utmLinkPost placed them in the URL. When the visitor arrives on the third party site the urchin.js JavaScript will pluck them from the URL and create a set of cookies for the third party domain using the values from the URL.

3. Incompatible Architectures

If you’re banging your head against the monitor trying to figure out why GA is not working with a third party domain it could be that the third party site is not compatible with Google Analytics. This is very common.

First, the third party provider must let you add JavaScript to your pages. We discussed this above. No JavaScript tracking code, no visitor tracking.

Second, make sure the third party site lets you pass data to their site via the URL. Remember, that’s how __utmLinker() and __utmLinkPost() work. I’ve come across many third party sites that strip out query string variables which breaks the GA tracking.

To determine if the third party site is stripping out the query string variables use the method I described above. Go to your site and click on a link or form that drives the visitor from your site to the third party site. When you arrive on the third party site look at the URL in your browser’s location bar. You should see information like this:

http://www.cutroni.com/blog/index.htm?
__utma=var1&__utmb=var2&__utmc=var3&__utmv=var4&utmz=var5&__utmk=1232

The query string variables above (bolded) are the actual tracking cookies from the original domain.

If the third party provider’s architecture does not appear to be compatible with GA give them a call. Sometimes they’re willing to change. I’ve actually worked with quite a few vendors to help make their systems GA compatible.

Google Analytics Configuration Mistake #3: Third Party Domains is a post from: Analytics Talk by Justin Cutroni

Related posts:

1. How Google Analytics Tracks Third-Party Domains
2. Google Analytics Configuration Mistake #2: Query String Variables
3. Google Analytics Configuration Mistake #1: Missing Default Page

Google Analytics creates a unique page view using the path name, the file name and any query string parameters present in the location bar of the browser. Remember, the query string parameters are all the junk after the question mark. GA strips the domain name from the URL and the remaining info becomes a unique page.

This URL:
http://www.mysite.com/dir/index.php?sess=1234&ocId=3&var1=foo&var2=bar
Results in this page view:
/dir/index.php?sess=1234&ocId=3&var1=foo&var2=bar

And this URL:
http://www.mysite.com/dir/index.php?sess=4567&ocId=6&var1=bar&var2=foo

Results in this page view:
/dir/index.php?sess=4567&ocId=6&var1=bar&var2=foo

Now, if the query string parameters passed between pages have no functional significance, i.e. they do not influence the content that is shown to the user, they should be ignored when GA creates a unique page view. Because the query string parameters do not offer any insight into what the visitor is doing, we want GA to track the above URLs as two views to a single page, not two views for two different pages.

The concept here is that the query string parameters do not tell us anything about the visitor’s actions. If your query string parameters describe what the visitor is doing then you do not want to remove them. Example, if one of your query string parameters is a product ID then you would not want to remove it. You want to know which products a visitor views during their session.

To force GA to skip certain query string parameters when processing we enter the unwanted parameters in the ‘Exclude URL Query Parameters:’ filed in the ‘Main Website Profile Information’ section.

Just enter a comma separated list of the parameters in the field I’ve outlined above. Here’s an example:
sess,ocId,var1,var2
If your site uses query string parameters to pass ANY information, I recommend you audit all query string parameters and identify which ones can be ignored. Here’s a tip, use the Top Content report to quickly identify the website query string parameters. When you pull up the Top Content report use the in-report-filter and enter \?. This will immediately display all the records containing query string parameters.

Remember, this is going to affect other parts of Google Analytics. Once you add a query string parameter to the list, it will be completely ignored. It will not be listed in ANY of the GA reports. Also, when you exclude a query string parameter you no longer need match that variable when creating goals and funnels.

As usual, changing this setting will not affect the data that has already been processed by Google Analytics. Only data processed in the future will reflect this change.

Google Analytics Configuration Mistake #2: Query String Variables is a post from: Analytics Talk by Justin Cutroni

Related posts:

1. Google Analytics Configuration Mistake #1: Missing Default Page
2. Tracking Dynamic Sites With Google Analytics
3. The Two Types of Google Analytics Configuration

Why does this matter to GA? When the urchin.js tracking code executes it creates pageviews using the page name that the visitor requested. What if there is no page name, as is the case above? GA creates a pageview for /. When people type http://www.cutroni.com/index.php GA create a pageview for index.php. See how this can cause a problem? GA collects pageviews for / and for index.php. Two pageviews for the same page.

Pageviews for a page should be summarized in a single line item, not two! Note: I know the above example isn’t all that great. It would be better if 50% of the traffic was for / and 50% was for index.php. But I don’t have any profiles with bad data :)

To remedy this problem enter the default page for your website in the ‘Default page:’ field in the ‘Main Website Profile Information’ configuration section.

Be sure to only enter the page name, no ‘/’ before the page name and no regular expressions. Just the name of the page, nothing else.

Remember, this change will not affect data that has already been processed by Google Analytics. It will only affect data that will be processed in the future.

Google Analytics Configuration Mistake #1: Missing Default Page is a post from: Analytics Talk by Justin Cutroni

Related posts:

1. Page Titles Report for Urchin
2. The Two Types of Google Analytics Configuration
3. Tracking Dynamic Sites With Google Analytics