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.


Share:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • Digg
  • Technorati
  • del.icio.us
  • Slashdot
  • StumbleUpon
  • Ma.gnolia
  • YahooMyWeb
  • co.mments
  • Reddit
Subscribe:

This, That and a Web Analytics Survey

November 16, 2007 by Justin Cutroni

I’m back… finally. Sorry for the long layoff, things have been absolutely crazy here. I wanted to take a moment and say a few things.

First, I’m sorry I have not gotten to all of your comments. I think there are over 50 in my moderation queue. I’m usually very prompt at responding but I needed to back-burner comments for the past few weeks. I should have the queue cleared out by Monday. If you’ve asked a question I will get to it.

Second, I wanted to remind everyone that Eric T. Peterson is conducting his bi-annual survey of web analytics practitioners, consultants, and vendors. This year’s survey focuses on tools.

The survey can be found here:

http://www.webanalyticsdemystified.com/survey/

As a thank you, Eric is offering a discount coupon good for $10.00 OFF of the “Big Book of Key Performance Indicators”. If you don’t have this book this is a great opportunity to pick it up for a fantastic price.

And Finally….

I’m working on the next version of Google Analytics Short Cut. I thought I would have it done and published by now, but I wanted to wait for all the new GA features announced last month to go live. I’ve also been incorporating the feedback that everyone has provided.

If you’ve already purchased GA Short Cut you will automatically receive an update when it is done. Not bad fora $10 investment.


Share:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • Digg
  • Technorati
  • del.icio.us
  • Slashdot
  • StumbleUpon
  • Ma.gnolia
  • YahooMyWeb
  • co.mments
  • Reddit
Subscribe:

Come to Web Analytics Wednesday in Burlington, VT

November 6, 2007 by Justin Cutroni

EpikOne is sponsoring Web Analytics Wednesday TOMORROW night, November 7, at Halverson’s Upstreet Cafe (16 Church St.). We’ll kick things of at 6:00 PM. If you’d like to attend please register at http://www.webanalyticsdemystified.com/wednesday/

If you’ve never been to a WaW event you should really try to make it. It’s a fantastic opportunity to network with other industry professionals and share your web analytics war stories! So, if you’re one of the 438 Vermonters that reads this blog please try to make an effort to attend. I’m looking forward to meeting some of you!


View Larger Map


Share:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • Digg
  • Technorati
  • del.icio.us
  • Slashdot
  • StumbleUpon
  • Ma.gnolia
  • YahooMyWeb
  • co.mments
  • Reddit
Subscribe:

Make GA Data Quality Suck Less!

November 6, 2007 by Justin Cutroni

Frustrated with GA Data?  Get a grip!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:

Google Analytics Lowercase Filter

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.

Google Analytics AdVanced Filter for URI ReWrite

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:

20071104-exclude-parameters.png

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:

Google Analytics Include Filter

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.

Google Analytics Filter: Exclude IP Address

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.


Share:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • Digg
  • Technorati
  • del.icio.us
  • Slashdot
  • StumbleUpon
  • Ma.gnolia
  • YahooMyWeb
  • co.mments
  • Reddit
Subscribe:

Visit Vermont for Online Marketing BootCamp

October 30, 2007 by Justin Cutroni

Online Marketing BookcampOn November 12-16 we’ll be holding our second Online Marketing BootCamp. This 5 day event is a series of talks and training sessions about online marketing and how to power your online marketing with Google tools. We have sessions ranging from the State of Online Advertising to Advanced Google Analytics Configurations. Can you guess what I’ll be speaking about? :)

We learned a lot from our first Boot Camp. Based on participant feedback we’ve re-tooled the format and the content. Even if you attended the first BootCamp you’ll probably find something new this time around.

I think one of the best parts of OM BootCamp is the format. Each day is focused on a specific part of online marketing. Interested in testing? Come to the testing day. Want to learn about analytics? Come to the analytics day. Come for a day or for the entire week; it all depends on what you want to learn.

Each day ends with an Ask the Experts session. These informal meetings provide a relaxed environment where participants can work through specific issues with speakers. Got a really hard GA question? I’ll be there to help. This is what I’m most excited about, working directly with people.

If you’re interested in OM BootCamp, or if you have any questions, email us at info -AT- epikone . com.


Share:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • Digg
  • Technorati
  • del.icio.us
  • Slashdot
  • StumbleUpon
  • Ma.gnolia
  • YahooMyWeb
  • co.mments
  • Reddit
Subscribe:

Integrating Google Analytics With a CRM

October 29, 2007 by Justin Cutroni

20071025-gears.jpgA lot of people ask about integrating Google Analytics data with other types of data. Most people are interested in some type of CRM integration so that’s what I’m going to write about.

Let me start by saying that there is no API to Google Analytics. There is no formal way to pull data out and integrate it into some other application. Sure, there are some hacks out there to manipulate the report URLs but, in my opinion, this is a pretty big hack and I don’t recommend it to our clients.

When we talk about integrating Google Analytics with a CRM we’re talking about pulling information about the visitor’s originating source and sending it to a CRM system. We’re not going to pull the visitor’s entire history, just where they came from and attach it to other information that they enter into a form.

Why do this?

Happy Customers!Pulling a visitor’s source information is very helpful to a sales team. Image if a sales rep could identify how a sales lead found the website before picking up the phone and contacting them? Remember, a visitor’s source info describes how the visitor found the site. Did they respond to a specific email with a certain offer? Or did they come from search and, if so, what was the keyword they used? This type of info can help a sales team understand the intent of the prospect but where in the buying process they are. That makes life for the team a little easier.

So how do we connect a visitor’s source to a visitor?

Conceptual Overview

Google Analytics stores a visitor’s source data in a cookie. That cookie is named __utmz. The data can be extracted from the cookie and added to a lead generation form. When the visitor submits the form the source information is connected to the other information that the visitor entered into the form (usually her name and other contact information).

If the contact form is integrated with a CRM application, like SalesForce.com or NetSuite, it may be possible to store the marketing information with the individual’s contact information. Direct CRM integration depends on your CRM system. Some systems allow form fields to be pulled directly into the application. Check with your CRM provider for information about your specific system.

I would like to note that you don’t need to use some fancy CRM to take advantage of this technique. You can use the technique below even if your lead form generates an email or dumps the data into a database. The key is that we’re leveraging the data in the Google Analytics cookies and connecting it with information that the visitor sends you.

Detailed Instructions

Ok, so how do you actually do this? It takes some coding, either client side coding (JavaScript) or server side code (PHP, ColdFusion, .NET, Java, etc.). My example uses JavaScript. Here’s a basic explanation of what the code needs to do:

1. Extract the visitor’s source data from the __utmz cookie
2. Manipulate data as needed
3. Place data in hidden form fields

When the visitor submits the form the source data in the hidden form fields will be sent back to the server where it can be used.

The sample code below extracts the source information from the cookie and places it in some hidden form fields. Then, when the form is submitted the information is passed to the server.


<html> 
<head> 

<script src="http://www.google-analytics.com/urchin.js"></script> 

<script> 
_uact="XXXXXX-X"; 
urchinTracker(); 
</script> 

<script> 
// 
// Get the __utmz cookie value. This is the cookies that 
// stores all campaign information. 
// 
var z = _uGC(document.cookie, '__utmz=', ';'); 
// 
// The cookie has a number of name-value pairs. 
// Each identifies an aspect of the campaign. 
// 
// utmcsr  = campaign source 
// utmcmd  = campaign medium 
// utmctr  = campaign term (keyword) 
// utmcct  = campaign content (used for A/B testing) 
// utmccn  = campaign name 
// utmgclid = unique identifier used when AdWords auto tagging is enabled 
// 
// This is very basic code. It separates the campaign-tracking cookie 
// and populates a variable with each piece of campaign info. 
// 
var source  = _uGC(z, 'utmcsr=', '|'); 
var medium  = _uGC(z, 'utmcmd=', '|'); 
var term    = _uGC(z, 'utmctr=', '|'); 
var content = _uGC(z, 'utmcct=', '|'); 
var campaign = _uGC(z, 'utmccn=', '|'); 
var gclid   = _uGC(z, 'utmgclid=', '|'); 
// 
// The gclid is ONLY present when auto tagging has been enabled. 
// All other variables, except the term variable, will be '(not set)'. 
// Because the gclid is only present for Google AdWords we can 
// populate some other variables that would normally 
// be left blank. 
// 
if (gclid !="-") { 
      source = 'google'; 
      medium = 'cpc'; 
} 
// Data from the custom segmentation cookie can also be passed 
// back to your server via a hidden form field 
var csegment = _uGC(document.cookie, '__utmv=', ';'); 
if (csegment != '-') { 
      var csegmentex = /[1-9]*?\.(.*)/;
      csegment    = csegment.match(csegmentex); 
      csegment    = csegment[1]; 
} else { 
      csegment = ''; 
} 
function populateHiddenFields(f) { 
      f.source.value  = source; 
      f.medium.value  = medium; 
      f.term.value    = term; 
      f.content.value = content; 
      f.campaign.value = campaign; 
      f.segment.value = csegment; 
      return true; 
} 
</script> 
</head> 
<body> 
<form name='contactform' 
onSubmit="javascript:populateHiddenFields(this);"> 
<input type='hidden' name='source' /> 
<input type='hidden' name='medium' /> 
<input type='hidden' name='term' /> 
<input type='hidden' name='content' /> 
<input type='hidden' name='campaign' /> 
<input type='hidden' name='segment' /> 
</form> 
</body> 
</html> 

Now, if this form is directly connected to a CRM then the data in the hidden form fields will go directly into the CRM along with other form info. That’s the magic. Again, you can use this method to collect source information even if the form is not connected to a CRM. Any type of lead generation form will be more valuable if you use this technique.

How The Code Works

When the above page loads in the browser the JavaScript starts to execute and extracts data from the cookies. First, it extracts the value of the __utmz cookie and stores it in a variable named z. Then it parses the z variable and looks for information about the visitor’s source. The __utmz cookie has a number of name-value pairs separated by a pipe (’|') character. Each name=value pair holds a different attribute of the visitor’s source. Here’s an example of the __utmz cookie.

12454562.1193706926.14.5.utmcsr=google|utmccn=(organic)|
utmcmd=organic|utmctr=google%2Banalytics%2Bshortcut

20071029-z.pngYou can see that the name value pairs look very similar to the parameters we use for link tagging. Just by looking at the above cookie you can figure out that the visitor performed an organic search on Google for the term ‘google%2Banalytics%2Bshortcut’ or ‘google analytics shortcut’. That’s the type of information that we want to put in hidden form fields and send back to the server. [You can learn more about the __utmz cookie in the reference section below.]

Getting back to the code, we were talking about how the code extracts the information from the z variable. It uses a function named _uGC(), which is found in the urchin.js JavaScript, to do all of the work. __uGC() extracts the value part of all the name-value pairs in the cookie. We call _uGC() for each name-value pair that exists in the cookie. It parses the cookie and pulls out the information that we want. [If you want to know more about _uGC() please see the reference section at the end of this post.]

Once the information is out of the z variable the populateHiddenFileds() functions puts the data in a series of hidden form fields. Then, when the form is submitted, the data is sent to the server.

You’ll notice a few things about the above code. I’ve added some logic to deal with AdWords auto-tagging. Auto tagging populates part of the cookie with a value named gclid. This variable hides some of the info that we need, like source and medium. The logic in the above code populates data that would otherwise be missing. I’ve also added some code that extracts the custom segment value which is stored in the __utmv cookie. I thought it would be useful to send this info back to the server as well.

Conclusion

Pulling visitor source data and connecting it with a visitor is very valuable. While your implementation will almost certainly be different, the concept illustrated above is the foundation for all implementations. Regardless of your implementation the business use for this data is fantastic.

Good luck!

20071029-reference.png

Reference

About the _uGC() Function

_uGC() takes three arguments:

_uGC(string, start-string, end-string)

• A string to search (target string)
• A start string
• An end string

The function will return the string between start string and end string. If the start string is not found then the function will return a dash (-).

About The _utmz Cookie

The __utmz cookie is the referral-tracking cookie. It tracks all referral information regardless of the referral medium or source. This means that all organic, CPC, campaign, or plain referral information is stored in the __utmz cookie. By default the cookie expires in six months, but that can be customized by changing the tracking code.

Cookie Format:


domain-hash.ctime.nsessions.nresponses.utmcsr= X(|utmccn=X|utmctr=X|utmcmd=X|utmci

Data about the referrer is stored in a number of name-value pairs, one for each attribute of the referral:

utmcsr
Identifies a search engine, newsletter name, or other source specified in the
utm_source query parameter See the “Marketing Campaign Tracking”
section for more information about query parameters.

utmccn
Stores the campaign name or value in the utm_campaign query parameter.

utmctr
Identifies the keywords used in an organic search or the value in the utm_term query parameter.

utmcmd
A campaign medium or value of utm_medium query parameter.

utmcct
Campaign content or the content of a particular ad (used for A/B testing)
The value from utm_content query parameter.

utmgclid
A unique identifier used when AdWords auto tagging is enabled This value
is reconciled during data processing with information from AdWords.


Share:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • Digg
  • Technorati
  • del.icio.us
  • Slashdot
  • StumbleUpon
  • Ma.gnolia
  • YahooMyWeb
  • co.mments
  • Reddit
Subscribe:

SiteScan for All!

October 23, 2007 by Justin Cutroni

SiteScan from EpikOne.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!


Share:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • Digg
  • Technorati
  • del.icio.us
  • Slashdot
  • StumbleUpon
  • Ma.gnolia
  • YahooMyWeb
  • co.mments
  • Reddit
Subscribe:

New Google Analytics Features & Announcements

October 16, 2007 by Justin Cutroni

Today Google announced a number of new features for Google Analytics. I’m really excited about these features because they will greatly improve our ability to understand our site site visitors and what they want to do. You should know that this is a true beta. Google is taking signups for the new features and they should be rolled out to beta testers soon.


Links for More Information

It would be impossible to thoroughly explain each feature in a single post, so I’ve written a number of articles to cover everything you need to know.

GA.JS: New Google Analytics Tracking Code
GA On Site Search Pt. 1: Overview & Setup
GA On Site Search Pt. 2: Reporting & Usage
GA Event Tracking Pt. 1: Overview & Data Model
GA Event Tracking Pt. 2: Implementation
GA Event Tracking Pt. 3: Reporting
Urchin 6 Software
Automatic Oubound Link Tracking

New GA.JS Tracking Code

The first big change is a new version of the Google Analytics Tracking Code (GATC). The new code is object oriented, has a smaller file size and enables a number of features. The old tracking code is not going away (yet), so you don’t need to rush out and change all the tags on your pages. But you may want to given the next announcement…

Event Tracking

Google Analytics now supports Event tracking. A lot of people have been asking for it and now it exists. Google changed the GATC to enable event tracking.

You can now use Google Analytics to logically track anything, like video player interactions, visitor clicks, etc. The beauty is that you no longer need to create extra pageviews. Google has created a logical data model to help understand visitor actions and intent. I must admit, when I first heard that they were adding Event tracking to GA I was skeptical, but this feature is completely awesome! It is really well done.

Internal Site Search Reporting

The next addition is a series of reports that focus on internal site search. These reports provide a structured, logical way to evaluate the value of your onsite search. I’ve been testing these reports for a while and they are truly remarkable. I can’t tell you how much insight I’ve gained into site visitors by using them. Setup is really easy and I think everyone is going to like them. Note that the search reports are not related to, or affected by, the new tracking code.

Urchin 6 Software

And finally, Google announced a new version of Urchin software. Urchin 6 will be available in beta form starting October 22. For those of you unfamiliar with Urchin, it is a log analysis tool. You install it on your server, it crunches your log files and produces pretty graphs. Urchin 6 is a complete upgrade from Urchin 5. It has a new data processing engine and a new interface. It’s NOT using the current GA interface, it’s using the OLD GA interface. But it is a huge upgrade.


Share:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • Digg
  • Technorati
  • del.icio.us
  • Slashdot
  • StumbleUpon
  • Ma.gnolia
  • YahooMyWeb
  • co.mments
  • Reddit
Subscribe:

Introducing Urchin 6

October 16, 2007 by Justin Cutroni

Urchin 6 is Here!It’s finally here. After almost 3 years there is a new version of Urchin. For those of you that do not know what Urchin is, it is a log processing web analytics tool and the predecessor to Google Analytics. Urchin 6 will be released as a beta product on October 22 to existing Urchin customers only. If you are not an Urchin customer then you will have to wait until the beta period expires.

This is a true beta. I’ve been testing Urchin 6 for a few weeks and it looks very promising. However, there are a couple of ‘kinks’ and I would not make any business decisions based on the data. However, if you’re an Urchin 5 owner, and you will never move to GA, I suggest you get a copy of the beta and test it out. The usability is much better than Urchin 5.

Getting Urchin 6

To get a copy of the beta software contact EpikOne (or one of the other resellers). I’m partial to EpikOne. Be sure to have the following information ready when you contact your reseller:

  • Name
  • Email
  • Website URL
  • Google Account ID (e.g. gmail address)
  • Urchin serial code
  • Reason for using Urchin Software instead of Google Analytic

Pricing

urchin 6 costThe pricing for Urchin 6 is pretty straight forward. The complete product will be $2,995 US and there will be discounts for some existing users. The price includes the full functionality. You no longer need to worry about purchasing different modules. Urchin 6 includes everything, you can run Urchin 6 with e-commerce and campaign tracking functionality on lots of servers with no extra cost.

Urchin 5 owners who previously purchased an Advanced Support contract with Urchin directly will get Urchin Software for free. This is an important point. Free is a pretty good cost.

If you are a regular Urchin 5 owner then the price of Urchin 6 will be discounted based on the price you paid for Urchin 5. So, if you purchased Urchin 5 for $895 US then the price of Urchin for you will be $2,100 US ($2,995 US - $895 US).

Front End Changes

The front end of Urchin has been completely updated. In fact, Urchin 6 has the old Google Analytics interface. That means that features like cross segmentation have been added to the product. They’ve also removed the custom old SVG graphics and added Flash graphs. I did not have a chance to take any screenshots, but the interface is a tremendous improvement, both in usability and functionality, over the old Urchin 5.

Back End Changes

Urchin’s back end has been completely re-written to accommodate the new front end. The processing engine has been changed, the database structure has been expanded and a new MySQL database has been added to manage users. I want to stress this last point, that MySQL is now used to store Urchin 6 user data and not visitor data.

General Thoughts

I really like the new Urchin 6… but I really like Google Analytics. For the past few years I’ve been suggesting to clients that they migrate to GA. It’s easier to setup and the reporting is far superior. With that said, some organizations can not use GA. If you’re one of them I would strongly recommend taking a look at Urchin 6. For the price, it is a robust tool with lots of features.


Share:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • Digg
  • Technorati
  • del.icio.us
  • Slashdot
  • StumbleUpon
  • Ma.gnolia
  • YahooMyWeb
  • co.mments
  • Reddit
Subscribe:

GA.JS: New Google Analytics Tracking Code

October 16, 2007 by Justin Cutroni

ga.js - Google Analytics tracking codeOn 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:

urchin.js code

Code #2: Page tag using ga.js

ga.js code

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!


Share:
These icons link to social bookmarking sites where readers can share and discover new web pages.

  • Digg
  • Technorati
  • del.icio.us
  • Slashdot
  • StumbleUpon
  • Ma.gnolia
  • YahooMyWeb
  • co.mments
  • Reddit
Subscribe: