Analytics Talk

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.

Subscribe:

28 Comments »

Introducing Urchin 6

October 16, 2007 by Justin Cutroni

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

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

Subscribe:

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

40 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:

8 Comments »

Event Tracking Pt. 1: Overview & Data Model

October 16, 2007 by Justin Cutroni

One of the major new features announced by Google at the EMetrics summit is event tracking. There has been a lot of discussion in our industry about tracking events and only a few vendors offer this feature. I believe that Google is the third. Anyway, this post gives an overview of the new feature. Part 2 covers the actual implementation and part 3 covers the reporting.

What Are Events

Events are actions that visitors take on a web page that don’t generate new pageviews. Interacting with a video player, a widget or an audio player are all common events. Tracking these interactions provides a lot of insight into what visitors are doing on a page.

In the old GA we could track this data as a pageview. But this was really ineffective. First, it created lots of pageviews that polluted our true pageview numbers. Second, the reporting wasn’t built to handle events so it never provided any real insight. That’s why we now have event tracking.

Event tracking adds another layer of data to the visitor data hierarchy:

Visitors
Visits
Pageviews
Events

Now we can really get a good idea of how visitors are engaging our interactive content. This will be vital as web technologies, like Ajax and Flash, continue to evolve.

Every time an event occurs GA will increase the event counter. So if we’re tracking the click button event, GA will show us an agregate count of the clicks. I’ll cover the reporting in Part 3.

Start With Business Questions

Before I get into the structure of event data, I want to talk about analysis. All analysis starts with a business question. What is the most popular organic keyword that visitors searched for? How many sales did I have last week? What was the revenue for a specific campaign? Normally, when you’re using GA, you don’t need to do any special configuration to answer these questions. GA does most of it for you.

But with events, you need to create ALL of the data that will end up in GA. You literally need to define what data you want GA to collect both in name and in value. If you don’t know what business questions you want to answer, you won’t be able to create the correct data.

As I continue this post, I’m going to use an example, Google Maps. If I was an analyst for Maps I would want to answer a lot of questions:

How many people use the zoom and do they zoom in or out?
Which map view is most popular: map, satellite, hybrid, etc.
How many people drag a map waypoint to a new location?

To make things easy, let’s focus on one question: which map view its the most popular. So now that we know the question we want to answer, let’s talk about the data we need to answer it.

Understanding the Data Model

There are 4 parts to the events data model:

Objects
Actions
Labels
Values

Objects

Objects are parts of pages that we want visitors to interact with. This may be a video player or a cool Ajax widget. To continue our example, the object would be ‘Map’. Remember, the business question we want to answer concerns a feature in the map.

Actions

The second part of the data model is Actions. Actions are attached to an object and represent the actions that visitors perform on our object. Actions tell us what the visitor did.

There can be lots of actions associated with an object. Just think about our map. There are so many things that a visitor could do. But we want to define actions that relate directly to the business questions. Here are a few actions that our Map object might have:

Zoom
Change view type
Drag waypoint

Because we’re focused on one business question, we’re going to focus on one action: ‘Change view type’.

Labels

Labels quantify the action that occurred. If the actions tell us what the visitor did, the value tells us the result. So, for the ‘Change view type’ action that I created above, I might have the following labels:

Satellite
Map
Hybrid
Street view

Labels are really important to understanding actions. If an actions only has one value it does not provide any insight into what the visitor did.

Values

The final part of the data model is Values. Values are optional but can provide a lot of insight into certain events. Values can be any type of numeric data that indicates the value of the action and label. While there are not may good values for our example, let’s assign a monetary value to each label. Who knows, maybe someone viewing a hybrid map is worth more than someone viewing a regular map:

Satellite 5
Map 10
Hybrid 15
Street view 20

Values can also be monetary making it easy to identify what actions have real value.

Pulling it All Together

So let’s look at our business question and the data model we’re going to use to answer it.

Questtion:
Which view type do people use more?

Object:
Map

Action:
Change view type

Labels & Values:
Map 5
Satellite 10
Hybrid 15
Street Level 20

The next step is to implement the data model using event tracking code. That’s covered in Part 2. Oh, if the Google Maps team is reading, call me. I’m more than happy to lend a hand. :)

Subscribe:

9 Comments »

Event Tracking Pt. 2: Implementations

October 16, 2007 by Justin Cutroni

In this post I’m going to discuss how to implement event tracking in Google Analytics. If you have not read part 1, I strongly recommend you do so because I reference Part one extensively. When we implement event tracking we add code that creates the data model we defined in Part 1. We’re going to continue our example of tracking an event in Google Maps. We want to find out how which map view people use most.

The Data Model

If you remember part 1, I created a data model for our event data. This will help us answer our business question and it will help use create the code.

Tag Your Pages

I know this seems simple, but the first step is to make sure your pages are tagged with the GA tracking code. Remember, this only works with the new ga.js tracking code.

<script type='text/javascript'>;
var pageTracker = _gat._getTracker("UA-XXXXX-X");
pageTracker._initData();
pageTracker._trackPageview();
</script>

Creating The Object

The first thing we need to do is create the object that we want to analyze. To create a new object we use a method name _createEventTracker(). We pass this method a value and that value is the name of the object we defined in the data model. Our object is called ‘Map’ so let’s use ‘Map’ in the name:

var mapEventTracker  = pageTracker._createEventTracker('Map');

When we look at the reporting interface we will see ‘Map’ in the Objects report. Pretty straight forward, huh?

This code must appear after your GA page tag. The reason is that the _createEvent Tracker() method is attached to the pageTracker object. In this example, I’m going to place it in the same block as the regular tracking code:

<script type='text/javascript'>
// Here’s the standard page tag stuff
var pageTracker = _gat._getTracker("UA-XXXXX-X");
pageTracker._initData();
pageTracker._trackPageview();

// Here is the new event object
var mapEventTracker  = pageTracker._createEventTracker('Map');
</script>

Tracking the Action

Now that we have an object, how do we track an action associated with that object? We add JavaScript to our page code when the action takes place. So, with our Maps example, we would add some code when the visitor clicks on the button to change the Map view type. Here’s how that code might look:

onClick="mapEventTracker._trackEvent('Change Map View', <label>, <value>);"

<label> and <value> should be replaced with one of the labels we identified in our data mode:

Map 5
Satellite 10
Hybrid 15
Street Level 20

What happens when a visitor clicks on a map button is that the code sends the action, label and value to GA and associates it with the map action we defined above. Now you can see how our data model really drives the implementation.

Tracking Multiple Objects

Ok, so here is something that’s pretty cool. Let’s say the map team wants to add two different maps to a single page. We can track both of them using the same map object. We would then differentiate what the visitor does using different labels. The actions would remain the same for both objects, but we’d have different labels.

A Final Note

I’d like to say that every implementation for event tracking can be different. It really depends on the business questions you need to answer and the structure of your pages. I think this post does a very good job of covering the basics, but your specific implementation will probably be a bit different… Unless you’re Google Maps. :)

As we’ll see in the next post, the new Event reports provide a logical structure for analyzing event data.

Subscribe:

14 Comments »

Event Tracking Pt. 3: Reporting & Analysis

October 16, 2007 by Justin Cutroni

This is part three of a three part series about event tracking in Google Analytics. You can find more information in these other posts:

Event Tracking Pt. 1: Overview & Data Model
Event Tracking Pt. 2: Implementation

I wrote this post before having access to the new events reports. As a result, I don’t have any screen shots for you guys! Sorry I don’t have anything to show you guys, but I will try to explain as much as possible.

The new event reports section will have specific reports for objects, actions and labels. If you have not read my post on the event data model then I strongly suggest that you do so. The data model is the driving force behind the structure of the reports.

Event reports will let you see summary information at an Object level, action level and value level. Here’s an example using Google Maps. If we create a ‘Map’ object then we will get a unique count of how many times the map object has been created. We can then drill into that event and see the actions and values of those actions.

Map
|_ Click Map View
|_ Satellite
|_ Hybrid
|_ Map
|_ Traffic
|_ Street view

This drill-down functionality is very similar to the drill down that you can do with campaign tracking.

The interface will also show you the values of each label. Remember, Satellite, Hybrid, Map, Traffic and Street view, are all labels and they have an associated value. GA will total up the value and show a unique count of how many times each action happened, the total value and the average value.

This is fantastic information because we can now measure what people are doing on our media rich pages. We no longer need to rely on Average Time on Page to gauge the success of our content.

I know this is really high level, and I’m sorry I don’t have any screen shots, but I’ll try to get some soon. Hopefully you got a taste of what is possible with the event reporting.

Subscribe:

7 Comments »

GA On Site Search Pt. 1: Overview & Setup

October 16, 2007 by Justin Cutroni

This is part 1 in a two part series about tracking on site search with Google Analytics. In this post I outline the setup and configuration you need to perform to create accurate, usable data in the new reports. If you’d like to get a look at the reports, you can skip to part 2, where I talk about the reports and how to use them.

How to Set It Up

The new search reports are based on a query string parameter that contains the search term that the visitor entered. All you need to do is specify the name of the parameter in the profile settings. As GA processes the data it identifies the search term and builds the reports.

It is important to note that on site search processing happens BEFORE filters are applied. This means that we have no way to modify the way that search data appears in our reports. I personally believe that this is a mistake and it limits our ability as practitioners to generate the data that we need for analysis. I’m hoping that Google can somehow change this.

Basic Setup

The first thing you need to do is turn on site search reporting. This is easy, it’s an option in the profile settings (please see the image below).

Next, you need to tell Google Analytics which query string parameter contains your search term. The best way to identify the query string parameter is to do a search on your site. If I do a search on my site for ‘world series’, and the search results page URL looks like this:

http://www.website.com/search_results.php?q=world+series

then I would add ‘q’ to the search term field. Pretty simple, huh? The query string parameter goes in the ‘Query Parameter’ field (again, located in the profile settings).

You’ll notice that I’ve added two query string parameters in my example. The epikone.com website has two different search engines. You can define up to 5 parameters. This gives you a lot of flexibility if you are using multiple on site search engines.

Category Setup

Many search engines allow users to refine their searches using categories. For example, if I search for ‘lavender’ the search engine might let me focus my search in the ‘soaps’ category or ‘tea’ category. This configuration drives a specific report that show the search terms for each category.

Setting up the categories is the same as setting up the search terms. All you need to do is identify the query string parameter that identifies the category. In the following example I would enter ‘cat’ in the Category Parameter field.

http://www.website.com/search_results.php?q=lavendar&cat=soap

Other Options

There is one final setting that is very important. You may have noticed the radio buttons for strip query parameters out of URL. This setting will remove the on site search query string parameter from the URL after on site search processing is complete. This means that the query string parameter, and the search term, will be removed from ALL other reports. It’s very much like the exclude query string parameters setting in the profile settings.

If you choose yes, GA will consolidate pageviews for the search results page. This can be good and bad.

Here’s an example. If you do a search on my blog the URL will look like this:

http://www.epikone.com/blog/?s=world+series

Now, if I choose to remove the query string parameters GA will process the site search and then merge the resulting URI with all other instances of

/blog/

As you can see this is going to INCREASE the pageviews for /blog/. Is that good or bad? In the case of my blog it’s a bad thing because /blog/ is also the homepage. Removing the query string parameter will artificially inflate pageviews for the homepage.

However, if your on site search engine has a specific results page, like:

http://www.site.com/seach-results.php?q=world+series

Then removing the query string parameters is a good idea. The reason is you’ll have a single line item for your search results page in your reports and you’ll still be able to analyze on site search data using the On Site Search reports.

Common Problems

What if your on site search results page does not contain the search term in the URL? This is usually the case if your search form is using the POST method.

The workaround is to alter the way the search results pageview is created. This means manually creating a pageview for the search results page, that contains the search term. This is done by passing the tracking code on the search results page a value. Make sure that value includes a query string parameter containing the search term. Then specify the query string parameter in the on site search setup.

Here’s how you can modify the tracking code on the search results page to resolve this issue:

Old urchin.js implementation:
urchinTracker('/blog/search?q=<term>');

New ga.js implementation:
pageTracker._trackPageview('/blog/search?q=<term>');

Where <term> is the search term.

NOTE: If you haven’t heard, there is a new GA tracking code. You can read more about it in this post.

Optimizing the Setup

One thing that I’ve noticed is that the reports do not massage the data in any way. They report the raw keywords that the visitor entered. It’s great that we can see raw data, but it’s very easy to have duplicate data based on capitalization or spelling. Here’s an example. The following terms would all appear as different line items in the search reports:

Red Sox
red sox
redsox
red socks

From an analysis standpoint, the above terms are all the same. Visitors are searching for information about ‘red sox’. A certain amount of normalization would help, but we don’t want to eliminate too much data. Unfortunately the site search processing happens BEFORE filters, which means that we can not use filters to modify the data. I had initially thought we could use filters, but that is not the case.

Any data normalization MUST be programatic, it can not be done with filters! So, if you want to force all of your search terms to lowercase you must modify the page tag on your search results page. Specifically, you need to change how the pageview is created in GA. Here’s a sample piece of code that will force the query string parameters to lower case. You’ll need to update the tracking code on your search results page.

New ga.js code:
pageTracker.trackPageview(document.location.pathname + document.location.search.toLowerCase());

Old urchin.js code:
urchinTracker(document.location.pathname + document.location.search.toLowerCase());

This code change will eliminate all duplicates caused by capitalization.

Unfortunately there is no easy way to remove duplicates caused by misspelling. If we could only use filters… :)

Other Uses

What I find interesting is that this framework can be used to track other things. For example, let’s say you have an online ticketing service and the search feature passes certain search characteristics via the query string. I perform a search for tickets to see the Red Sox play at Jacob’s field. I specified the price range of the tickets and the date of the game. The URL might look like this:

http://www.tickets.com/search?price=100-200&date=20071014-20071016

What if I configure the new search reports to use price as the search field and data as a category? The reports should show me some really cool information. I haven’t tried this yet, but it could be very useful.

Subscribe:

27 Comments »

GA On Site Search Pt. 2: Reporting & Usage

October 16, 2007 by Justin Cutroni

This is part two in a two part series about the new GA on site search reports. In part one I discussed the setup.

There is a tremendous amount of information in the new Site Serch reports about ow your visitors interact with your search engine. But it goes way beyond measuring how many searches occurred for a keyword. The new reports actually tie outcomes to searches providing insight into what product sand content your site visitors are looking for. But enough babble, on to the screen shots.

What Reports are Available

First and foremost there is the Usage report. This reports helps you understand if visitors are using site search. If you’re trying to push site search as a navigational tool for your visitors, and only 2% of site traffic is using site search, then your navigation may not be working. You may want to change the visibility of the search box.

The Usage report is pretty good, but everyone wants to know what people are searching for. The Search Terms report contains all of the search terms that visitors entered into your on site search. One thing you should know is that GA is reporting UNIQUE searches. This means that duplicate searches, made in the same visit, are excluded. So it is not a count of how many times a term was search for, but rather how many VISITS contained a search for a specific term.

Take a look at the narrative at the top of the report. It contains a number of new metrics to evaluate on site search. Total Unique Searches indicates what search terms people are entering. % Search Exits indicates what percentage of visitors are leaving immediately from the search results page. This could indicate that visitors are unhappy with the search results. Time after Search and Search Depth indicate the engagement of the visitor after using search.

Google Analytics does not normalize the search terms. This means that misspellings and similar searches are not grouped together. So the search terms ‘red sox’, ‘red socks’ and ‘Red Sox’ would appear as individual line items. You’ll need to review your data and manually normailze it using filters.

Another really cool report is the Site Search Start page. This report shows where your site searches originated. It identifies the page that the visitor was on when the seach occured. This can help identify issues with navigation or the data architecture.

Now we know where people started their searches, but what about where they end up? The Search Destination Report shows which pages people navigate to directly from the search results page.

What’s really cool is if we click on a destination page that is listed in the above report we can see all the search terms that drove people to the page. Here’s what happens if I click on one of the results in the previous report:

There are other reports that do a good job of illustrating how visitors use site search. If you select a search term in any reports you can do a really deep analysis using the analyze drop down. One option is the Search Navigation report. This report shows where someone started their search and where they went after the search.

What about peple who search multiple times? Another analysis option is to use the Search refinement report. This report shows how people refine their search terms during their visit. So, in the image below, visitors began by searching for dog. Then they refined their search using one of the terms in the report.

Ok, one more thing about the Search Reports. Notice that the standard Goal Conversion and Ecommerce tabs exist on most reports. These tabs provide information about which searches lead to conversions and, if you’re an e-commerce site, the revenue that each generated. Pretty darn cool is you ask me.

What’s Missing

The one report that is missing from Google Analytics is the ‘0 Result’ searches. It’s really important to know what on site searches are producing 0 results. This is an indicator of missing site content. You can artificially create this data by creating an event or a pageview (I suggest event) in Google Analytics. I’ll write more about how to do this in another post. But be aware that the new reports to not contain this data.

In Summary

There is a ton that you can do with the new on site search reports. Not only can you analyze what people are looking for and optimize your content, but you can also identify how visitors integrate search into their visit.

Have fun with these reports!

Subscribe:

3 Comments »

Are You Going to eMetrics?

October 8, 2007 by Justin Cutroni

I’m headed to eMetrics next week. I’m actually traveling to California this week and will fly directly to the summit. In between the sessions I usually hang out at the Google booth and try to answer GA questions. So, if you need some help with GA, or just want to say Hi, drop by the booth.

Oh, and if you don’t know what I look like, check out the About Me page.

Subscribe:

7 Comments »