Analytics Talk

Google Analytics E-Commerce Tracking Pt. 2: Installation & Setup

January 22, 2008 by Justin Cutroni

This is part 2 in my series on Google Analytics e-commerce tracking. In part 1 I described, at a conceptual level, how GA e-commerce tracking works. In this post I’ll get into the specifics of the code and how to install it.

This isn’t the most exciting stuff (that will be part 3), but a correct setup leads to correct data. :)

Step 1: Activate the Reports

The first step in setting up GA e-commerce tracking is enabling the e-commerce reports. Log into GA and edit the profile settings. Specify that your site is an e-commerce site. This activates the e-commerce reports.

There are other e-commerce settings that don’t get much use (unless you’re an international site). You can specify one of 25 different currencies (wow!) and the number of decimal places you would like displayed (1,2 or 3). Even if you use USD you can specify 3 decimal places. Go ahead and try it, it’s interesting.

Remember, e-commerce reports is a profile setting that is “off” by default. You’ll need to activate the reports for each new profile you create.

Step 2: Tag your Receipt Page

I know this seems like a silly step, but make sure you add the GA tracking code you your receipt page. You must have the standard GA tracking code on your receipt page in order to track transactions. The reason is that the e-commerce tracking code is stored in the ga.js. If this file is not included on the receipt page then you can’t track transactions.

Step 3: Install the Code

This is the hard part: code construction. As we learned in part 1, GA uses a JavaScript collection technique to track e-commerce transactions. Your server code must inject transaction information into the GA JavaScript before sending the receipt page back to the browser. When the receipt page renders in the visitor’s browser the JavaScipt executes and sends the transaction info to GA.

Let’s take a look at the code:

<script type="text/javascript">
pageTracker._addTrans(
      "order-id", // required
      "affiliate or store name",
      "total",
      "tax",
      "shipping",
      "city",
      "state",
      "country"
); 

pageTracker._addItem(
      "order-id", // required
      "SKU",
      "product name",
      "product category",
      "unit price",  // required
      "quantity"  //required
); 

pageTracker._trackTrans();
</script>

The first thing that you’ll notice is that there are three distinct parts to the JavaScript. Each is a different method. The first section, identified by the _addTrans() method, creates the transaction and stores all the information about the transaction.

The second section, identified by the _addItem() method, is used to add an item to the transaction. You need to create an _addItem() section for each different item, or SKU, in the transaction. The order ID in the _addItem() method must be the same order ID used in the _addTrans() method. That’s how GA ties an item to a transactions.

The final section is the _trackTrans() method. This method actually sends the data to GA by requesting the __utm.gif file once for the transaction and once for each item in the transaction. So if you have 3 different SKUs in a transaction there will be 4 requests fot the __utm.gif.

The above JavaScript can appear anywhere on your receipt page. Just make sure that it appears after the main GA page tag. The reason is that the e-commerce code is part of the pageTracker object. If the pageTracker object has not been created then you can’t call the e-commerce methods.

Just to reiterate a point: you must create server side code that outputs the transaction data in the format above. If you do not have access to your shopping cart code, and your cart provider does not provide e-commerce tracking, then you may be out of luck.

Once the code has been installed you should begin to see e-commerce data in your reports.

Notes and Suggestions

Like many things in Google Analytics, there are some things that can trip you up:

• If you do not wish to pass a certain piece of data to GA then do not add anything between the quotation marks. The only required fields are the order ID, the unit price of each item and the quantity of each item. Everything else is optional.
• Do not use currency identifiers or commas (to separate thousands) in any of the numeric fields (i.e. total, tax, shipping). These characters have caused problems in the past.
• Each piece of transaction data that you send to Google Analytics becomes a data element in GA, just like any other piece of data in GA (geo data, campaign data, browser data, etc.). You can do all sorts of neat things with filters and e-commerce data. More on this later.
• The affiliate or store name field is no longer used in the GA reports. However, the data is still collected by GA so you can use it in a filter.
• The transaction geographic data collected by GA is no longer used BUT it is collected. Google Analytics determines the location of the user, and thus their transaction, based on their IP address. The old version of the GA tracking code used the data specified in the transaction. Like the affiliate field, the data can be used in a filter.

Up Next

In the next post I’m going to talk about some creative ways to use e-commerce tracking. Specifically, why I believe that everyone should use e-commerce tracking on their website.

Subscribe:

11 Comments »

Google Analytics E-Commerce Tracking Pt. 1: How It Works

January 13, 2008 by Justin Cutroni

This post is the first in a series of e-commerce transaction tracking with Google Analytics. Why is e-commerce tracking important? Well, transaction data is a vital piece of information when analyzing online business performance.

Sure, it’s great to measure things like conversion rate, but revenue is much more tangible to many business owners. Having the e-commerce data in your web analytics application makes it easier to perform analysis. Do you need to set up e-commerce tracking? No, but it sure helps. :)

The Big Pictures

E-commerce tracking is based on the same principal as standard pageview tracking. JavaScript code sends the data to a Google Analytic servers by requesting an invisible gif file. The big difference is that e-commerce data is sent rather than pageview data.

But how does Google Analytics get the e-commerce data? That’s the tricky part. You, the site owner, must create some type of code that inserts the transaction data into the GA JavaScript. Sounds tricky, huh? Well, its not that bad.

Step by Step: How it Works

Let’s break it down and walk through what actually happens.

1. The visitor submits their transaction to your server.

2. Your server receives the transaction data and processes the transaction. This may include a number of steps at the server level, such as sending a confirmation email, checking a credit card number, etc.

3. After processing the transaction the server prepares to send the receipt page back to the visitor. While preparing the receipt page your server must extract some the transaction data and insert it into the Google Analytics JavaScript. This is the code that you must create.

4. The receipt page is sent to the visitor’s browser.

5. While the receipt page renders in the visitor’s browser the e-commerce data is sent to Google Analytics via special GA JavaScript.

Here’s a basic diagram of the process. Again, the biggest challenge during implementation is adding code to your web server that inserts the transaction data, in the appropriate format, into the receipt page. I’ll cover the setup in part 2 of this series.

What Data can be Tracked?

Google Analytics collect two types of e-commerce data: transaction data and item data. Transaction data describes the overall transaction (transaction ID, total sale, tax, shipping, etc.) while item data describes the items purchased in the transaction (sku, description, category, etc.). All of this data eventually ends up in GA reports. Here’s a complete list of the data:

Transaction Data

• Transaction ID: your internal transaction ID [required]
• Affiliate or store name
• Total
• Tax
• Shipping
• City
• State or region
• Country

Item Data

• Transaction ID: same as in transaction data [required]
• SKU
• Product name
• Product category or product variation
• Unit price [required]
• Quantity [required]

A few notes about the data. First, the geo-location data is no longer used by Google Analytics. The new version of GA tries to identify where the buyer is located using an IP address lookup. Also, you should avoid using any non-alpha numeric characters in the data. Especially in the numeric fields. Do not add a currency identifier (i.e. dollar sign) in the total, tax or shipping fields. this can cause problems with the data.

Coming Up Next

Next time, in part 2, we’ll look at the code and how to actually add it to your site.

Subscribe:

14 Comments »

Updated GA.JS Tracking Code

December 17, 2007 by Justin Cutroni

I’ve gotten a lot of comments over the weekend about using the new ga.js code with ASP sites. It turns out that the code does not work with nested SP script tags. Also, the new tracking code that GA spits out is not XHTML compliant. These are unrelated issues that are causing a number of issues.

Google knows of these issues and will be pushing a solution soon. I’m not sure when, but soon. In the meantime, here is a copy of the new code that you should use on your site.

<script type="text/javascript">
 var gaJsHost = (("https:" == document.location.protocol) ?
"https://ssl." : "http://www.");
 document.write(unescape("%3Cscript src='" + gaJsHost +
"google-analytics.com/ga.js'
type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
 var pageTracker = _gat._getTracker("UA-xxxxx-x");

 pageTracker._initData();
 pageTracker._trackPageview();
</script>

Remember, you need to replace “UA-xxxxx-x” with the appropriate information for your profile.

Sorry for the short post… I’m pretty tied up at work but wanted to post this information.

Props to Eivind Savio for sending me a nice email about the problem and a number of solutions.

Subscribe:

16 Comments »

New and Improved GA.JS Documentation

December 13, 2007 by Justin Cutroni

Along with some other features, Google Analytics today launched Google Analytics Custom Tracking. This is a new website (code.google.com/apis/analytics/, a section of code.google.com) that deals with the Google Analytics Tracking Code. The site does a nice job of pulling together information about ga.js and Event Tracking. Plus it has a snazzy movie of Avinash, what a bonus!

While the new graphing features are nice, I think this is a very significant event. Google is really pushing Google Analytics and a data collection and analysis service, not just a web analytics tool. Sure, most of the data is generated via a web interface, but think of the proliferation of web-based applications and services.

Let’s not forget about Event Tracking. It’s not a rigid data structure that we have to adhere to. It is a flexible data model where we can define the data. It will work perfectly with web application.

I’d like to point out that the term API is all over this site. This has nothing to do with extracting data from Google Analytics. There is no API to extract data from Google Analytics.

Subscribe:

9 Comments »

Tracking Sub Domains with Google Analytics

November 19, 2007 by Justin Cutroni

Tracking websites that have multiple sub domains may not seem like a complicated thing. In fact, the GA support docs clearly outlines two ways to track sub domains. You can track all sub domains in a single profile or you can track sub domains in separate profiles.

But what if you want more flexibility? What if you want to track one group of sub domains in one profile and a different group of sub domains in another profile? Or what if you want to create new profiles for a different groups of sub domains in the future?

I like to use an approach that let’s you decide how you want to group sub domain traffic. This setup will give you the most flexibility now and in the future. Some of the benefits include:

1. It let’s you collect all data in a master profile. This facilitates ‘roll up’ reporting and gives you an easy way to measure traffic to the primary domain and all of the sub domains.

2. This technique lets you track each individual sub domain in it’s own profile which is useful for deeper analysis.

3. You can easily create new profiles in the future based on groups of sub domains.

Here’s the exact process to get this working.

1. Create Profile for The Primary Domain

The first step is to create a master profile. All other profiles for the website, including profiles for the various sub domains, will be based on this profile. When you enter the domain for the website use the primary website domain. In the example below, I’m using www.sitedomain.com as the website domain.

After creating the profile GA will display the tracking code for the site. Before you add it to your pages it must be modified. You need to force GA to use the primary website domain for the cookie domain. This modification will let you track each unique visitor across all sub domains. This in turn let’s us collect all site data in a single profile and do ‘roll up’ reporting.

Old urchin.js tracking code:

<script type="text/javascript">
_uacct = "UA-XXXXXXX-1";
_udn = "sitedomain.com";
urchinTracker();
</script>

New ga.js tracking code:

<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-XXXXXX-1");
pageTracker._setDomainName("sitedomain.com");
pageTracker._initData();
pageTracker._trackPageview();
</script>

Use this profile as a way to measure overall traffic across all of your sub domains. To facilitate page analysis in this profile add a filter that concatenates the hostname to the Request URI, which is the piece of data in the Top Content report. This will help you differentiate traffic to pages with the same URI that may reside on different sub domains.

A handy report that you’ll want to use in this profile is the Visitors > Network Properties > Hostnames report. This report will show traffic to the primary domain and all of the sub domains. It’s an easy way to compare traffic to the various sub domains.

2. Create Profiles for All Sub Domains

Once you have created the master profile you can start creating profiles for each of the sub domains. Remember, each sub domain profile is based on the master profile, that we created in step 1. Here’s how to set up the new profile:

Now that you’ve created the profile, make sure you add the tracking code to the pages on the sub domain. The tracking code for the sub domain is the same as the tracking code that goes on the primary domain (it’s the code from step 1).

3. Add Filters to Sub Domain Profiles

The next step is to add a filter to the sub domain profile so it only contains data for the appropriate sub domain. This is done using an include filter based on the hostname. Once this filter is in place you’ll have the master profile which will contain data for all sub domains, and this profile that will contain data for a specific sub domain.

To create additional profiles for other domains just repeat steps 2 and 3. Obviously the settings for the filter used in step 3 will depend on the sub domain that you want to include in the profile.

Creating Additional Profiles

Let’s say you need to create a profile for two sub domains: 1.website.com and 2.website.com. This can easily be done because the same tracking code is on both sites. All you need to do is add an include filter with the following settings:

While Google’s documentation describes a good way to track sub domains, I think this approach is better due to it’s flexibility. Plus, because the same tracking code is used all all sub domains you don’t need to worry about placing the wrong tracking code on a sub domain.

Good luck with your setup!

Subscribe:

29 Comments »

UPDATED: GA On Site Search Setup

November 17, 2007 by Justin Cutroni

I’ve updated my post about setting up Google Analytics On Site Search Reporting. Since its launch I’ve learned a few new things and wanted to pass on the information.

For example, you can’t use filters to change the data in the reports. That’s a HUGE problem because we have no easy way to manipulate the data in the reports. Also, if you configure on site search to strip the on site search query string parameter you could artificially inflate pageviews for some pages. Now that’s trouble! You can read the complete post here:

GA On Site Search Pt. 1: Overview & Setup

If there’s anything I missed, or if you have any questions, please leave a comment.

Subscribe:

No Comments »

Make GA Data Quality Suck Less!

November 6, 2007 by Justin Cutroni

We all know that data quality sucks! But there are a few, vital steps that you can take to insure that your Google Analytics data is as accurate as possible. Remember, accurate data makes for happy, and accurate, analysts.

Here are three simple tips that can help make your data more accurate.

1. Eliminate Duplicate Data

Many sites that I work on have duplicate data. The usual cause is mixed case URLs. Google Analytics is case sensitive, it captures the data exactly as it appears in the location bar of the browser. So if a URL is of mixed case in the browser, it will be captured and displayed in mixed case within GA.

It’s very easy to have two URLs, that have the same functional meaning, appear as two line items in GA because they have a different case. Here’s an example:

/worldseries/index.php?year=2007&keyword=lowell
/Worldseries/index.php?year=2007&keyword=Lowell

Both URLs are probably the same, they just appear different because of the case. We want to force both URLs to have the same case and thus make them appear as a single line item in GA. This can be done with a Lowercase or Uppercase filter. I like the lowercase filter, but you could easily use the uppercase filter. It’s a personal preference.

The filter below will force the Request URI to lowercase:

I recommend adding a case changing filter to any data element (i.e. filter field) that could be mixed case. This includes:

• Request URI
• Campaign Name
• Campaign Term
• Campaign Medium
• Campaign Source

Another cause of duplicate data is multiple URLs that display the same content but have a different file extension. Here’s an example:

/champions/redsox.php
/champions/redsox.htm

These URLs may appear different (because of the file extension), but the web server might interpret them as the same file. Please note that not every web server behaves this way. It all depends on your web server. Check with your IT guru if your site has URLs with multiple file extensions.

You should merge duplicates URLs, that have different file extensions, into a single line item. I find the best way to do this is with an advanced filter.

Some may think that a search and replace filter is the best way to remove these duplicates. But you would need to create a search and replace filter for each set of URLs that needs to be merged. An advanced filter, because it uses a regular expression, will change every URL that ends in ‘.htm’ to a ‘.php’ extension.

2. Remove Irrelevant Information

Extra information in the URL can cause big problems in Google Analytics. The reason is that GA will capture all of the data in a URL, which includes the query string parameters. Query string parameters that don’t have a functional meaning should be removed from the URL.

An easy way eliminate these parameters is to collect data for a week and then analyze the top content report. Any query string parameter that does not provide insight into what the visitor sees or does should be eliminated.

To remove a query string parameter from GA simply add it to the ‘Exclude URL Query Parameters’ field in the profile settings:

Enter multiple parameters as a comma separated list.

Be aware that once you remove a query string parameter from GA it is completely eliminated from the system. So any goals, funnels or other filters that use that parameter will no longer work.

Also remember that you should remove any query string parameters that contain personally identifiable information. It is against the GA terms of service to collect PII.

3. Identify Your Segment

I could have easily named this tip ‘exclude internal data’ but I wanted to change the way we all think about profiles and the data that’s in them. I believe we should think of profile data in terms of the segment we want to analyze, not who we want to exclude. I know these statements are very close in meaning, but there is a slight difference. Segmentation is so important to analysis. I believe that every time we create a profile we should consider what segment of data it will contain.

I can think if a few segments of data that I would like to analyze:

• CPC traffic
• New visitors
• Return visitors
• European visitors
• Traffic from a specific marketing campaign
• Non-employee traffic
• Traffic generated by my call center

All of the above segments can be created as different profiles using include filters. Each will provide some insight into that segment. Don’t get me wrong, you’ll probably want to exclude internal traffic from 99% of your profiles. But try to think in broader terms, focus on the segment that you want to analyze.

Creating a profile based on a particular segment of traffic is pretty easy. The first thing you want to do is identify what segment of traffic you want to include in your profile. Then create a filter based on the filter filed that represents that segment.

Let’s say I want to see all traffic generated from visitors performing some type of external search on my name. I could apply the following include filter to a profile:

This filter can easily be modified to include a specific marketing campaign (using the Campaign Name field), a specific country (using the Visitor Country field) or any other segment of data so long as it is represented by one of the filter fields. Please note that this will work even if you’re using AdWords auto tagging on, even though you haven’t done any heavy lifting to define the Campaign Term.

By the way, you will want to exclude internal traffic from many profiles. My favorite way to remove internal traffic from a profile is with an ‘Exclude all traffic from an IP address’. Make sure you use anchors at the beginning and end of the regular expression.

Another good way to exclude internal traffic, especially if you don’t have a static IP address, is to use a little hack called Count Me Out. This hack uses the GA custom segment cookie to identify users.

So remember, yes, you need to exclude internal traffic, but try to take a broad view and think about segmentation when you filter your profiles.

Subscribe:

6 Comments »

SiteScan for All!

October 23, 2007 by Justin Cutroni

Google got a lot of attention last week when it introduced some really cool new features in Google Analytics. One of these features, Event Tracking, is enabled by a new version of the Google Analytics Tracking Code (GATC).

This is a big change. Updating the GATC on our site can be a big project if you have a complicated implementation. If the GATC is not correct then tracking will cease and you’ll loose data. Migrating can be complicated because there are now two versions of the tracking code (urchin.js and ga.js) AND they’re incompatible.

Please note that the new tracking code has not officially been launched. It is currently in beta and should be out soon.

To help everyone transition from the old tracking code to the new tracking code some of the guys at EpikOne completely rebuilt SiteScan to support the new GATC.

For those of you that don’t know about SiteScan, it is a tool that scans the pages on your site for the GATC and insures that your installation is correct. The new version of SiteScan will parse your pages for the old tracking code (urchin.js) OR the new tracking code (ga.js). But here’s the best part…

SiteScan is Now Free!

That’s right, SiteScan is free… for everyone. So go on, give it a try. There is no reason not to.

Features

Besides being free, SiteScan has some other cool features.

The new SiteScan is smart enough to know what functions should, and should not, be used with each version of the tracking code. So, if you’re using ga.js SiteScan will know that you should NOT be using urchinTracker(). (If you have no idea what ga.js is check out this post).

Once SiteScan scans your site it spits out a CSV file listing all the pages scaned and any issues on each page. For those of you who used SiteScan in the past you know how hard it was to interpret the results. The new CSV file makes it extremely easy to find problems with your installation. Check out these sample results (right click and choose Save As).

The Brains and Brawn

A big congratulations to Alex and Casey who put a ton of work into SiteScan. Great job guys!

Subscribe:

3 Comments »

GA.JS: New Google Analytics Tracking Code

October 16, 2007 by Justin Cutroni

On October 16, 2007 Google announced a new version of the Google Analytics Tracking Code named ga.js. This means that there are now two versions of the GATC: the old urchin.js and the new ga.js. What makes the new ga.js different from urchin.js?

• The ability to track events
• New object oriented style; no more functions like urchinTracker()
• Smaller size for faster downloads

This post is all about why Google introduced a new GATC, what has changed and how this is going to affect your GA implementation.

Why the Change?

Simply put, Google changed the code to support event tracking. I’m not going to focus on event tracking here, this post is just about the style and usage of the new tracking code. Please see my posts on Event tracking for more information.

Did Google need to create a new tracking code? Maybe not. But I think the modifications necessary to implement event tracking were easier using a completely new set of code rather than the old code. If you look at the entire GA system, almost every part had been re-worked since the acquisition of Urchin in 2005 except the javascript tracking code. It was time for an update and, with the addition of event tracking, the timing was right.

What Exactly has Changed?

In short, everything has changed. All of the functions that we’ve been using are now gone. Functions like urchinTracker() and __utmSetVar() no longer exist. The reason is that the new tracking code is completely object oriented. For those of you that are unfamiliar with programming styles, object oriented programming is a more modular way of creating code.

Object oriented programming does not have functions and variables, it has objects, methods and properties. Each object has an associated set of methods and an associated set of properties. Think of an object as a car. The methods are the actions that you can do with a car, like start, stop. Properties are characteristics of the car, like the color, number of doors, etc.

Details of the New Page Tag

Let’s look at the old and new code to better understand the difference. I’ve numbered the lines so I can better explain what’s going on.

Code #1: Page Tag using urchin.js:

Code #2: Page tag using ga.js

While there are some similarities, you can see that the new code is different. Let me walk you through what it does.

The first part of the code is the reference to ga.js (line #1-#4). This is analogous to the call for urchin.js in the old code (line #1). The big change here is that the code will automatically detect if the current page is secure or non-secure (i.e. using HTTP or HTTPS). It will then dynamically request the appropriate ga.js file from the server. This is a little piece of code that was borrowed from website optimizer.

Next section of code, lines #6 - #8, is where all the work happens. First, we tell GA the account number using pageTracker._gat.__getTracker() (line #6). This is similar to setting the account number variable in the old code (line #4). Then we call the pageTracker._initData() method. This method collects information about the browser, the referral information, etc. And finally, on line #8, we call pageTracker._trackPageview(). This is the new urchinTracker(). This is how we send the data to GA and create pageviews.

The new code does the same thing as the old code, but in a very different way. Again, all of the old functions have changed and in some cases they’ve gone away. If you were using urchinTracker() to generate pageviews (like I was) then you will eventually need to replace that code with pageTracker._trackPageview().

Should you Upgrade?

This is the question that everyone is going to ask and there is no right or wrong answer. Eventually Google will kill urchin.js and you will have to change. But I don’t think that will happen for at least 18 months.

Here’s how I would approach the decision making process. First, do you absolutely need event tracking? If yes, then you should upgrade. You can read all about event tracking in this series of posts.

If you don’t need event tracking then my suggestion is to evaluate the complexity of your current GA implementation and then decide. If it’s fairly straight forward, i.e. you’re not an e-commerce site or you don’t have additional urchinTraker() calls, then I would suggest migrating.

However, if you have a complex implementation, one where you’re calling urchinTracker() a lot, you’re doing cross domain tracking, or you’ve implemented e-commerce tracking, then I would take my time. Plan your migration. There is no rush and you want to get it right.

No matter when you choose to upgrade, make sure you test your implementation before migrating. You don’t want a big hole in your data due to a mistake.

And Finally…

There is a lot more to the ga.js. As I mentioned before, all of the old functions have been replaced. I’ll have a listing of all the new methods soon. Until then, start thinking about your migration!

Subscribe:

36 Comments »

Automatic Outbound Link Tracking

October 16, 2007 by Justin Cutroni

With the release of the new GA.JS tracking code Google Analytics now supports automatic outbound link tracking. No more adding urchinTracking() to links!

In order to get outbound link tracking to work you need to migrate to the new ga.js.

I don’t have any reports to show you, but hope to have some soon.

Subscribe:

6 Comments »