Analytics Talk

New Google Analytics Features & Announcements

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.

28 Comments »

GA.JS: New Google Analytics Tracking Code

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!

40 Comments »

Automatic Outbound Link Tracking

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.

8 Comments »

Event Tracking Pt. 1: Overview & Data Model

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

9 Comments »

Event Tracking Pt. 2: Implementations

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.

14 Comments »

Event Tracking Pt. 3: Reporting & Analysis

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.

7 Comments »

GA On Site Search Pt. 1: Overview & Setup

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.

27 Comments »

GA On Site Search Pt. 2: Reporting & Usage

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!

3 Comments »

Give Me What I Want and I’ll Do What You Ask

I’m not a testing guru. I love testing and think it’s a vital part of the web analytics process, but I’m still learning about the ins and outs. One thing that I have learned is that there is more to testing than changing the color of a button or the format of an email. It is equally important to test the offer that you’re making to the customer. Which works better, ‘20% Off’ or ‘Free Shipping’? Unless you test both you’ll never know.

This week I was reminded how important it is to test the offer when I received an email from Northwest Airlines. I don’t fly NWA much, but I have in the past. Anyway, what really caught my attention was, you guessed it, the offer.

I don’t know about you, but I’ll do almost anything for frequent flier miles. What a great deal, I can get 1,000 miles AND reduce my postal mail. Sign me up! The offer was perfect for me. Would I have taken to the time to subscribe to their email if they did not offer the frequent flier miles? Probably not.

There are so many things that NWA could have tested. First, they probably tested the offer. Then I bet they tested how many miles they needed to offer before someone would convert. Would I have enrolled for 500 miles? Probably not. I wonder if they tested the subject line of the email? I think more people would respond to the message if the offer was in the email subject line, but I could be wrong… Another benefit of testing the offer: understanding the financial impact, i.e. ROI, of the offer.

The bottom line is testing the message is just as important as testing your formats and layouts.

Tracking Email Conversions with Google Analytics

This post would feel naked if I didn’t mention something about GA. :)

The key to measuring the effectiveness of an email offer is identifying how many conversions occur. Measuring email conversions is pretty easy with Google Analytics. It all starts with link tagging. If you’re unfamiliar with link tagging then you may want to take a moment and review how it’s done. Testing emails with GA starts with creating different variations. Once the variations have been created you need to tag the emails so GA can identify each one.

Add a utm_campaign, utm_medium, utm_source and utm_content parameter to each link in each email. While the campaign, medium and source parameters can have the same values, each variation should have a unique content parameter. The following table lists the query string parameters for a simple A/B test.

After you’ve sent out the email, use the Traffic Sources > Ad Versions Report to measure the traffic volume and conversions generated by the message. The Ad Versions report shows a line item for each utm_content variable. Note: you should know that this report, by default, contains information from AdWords. If you’re using auto-tagging then GA will automatically pull in the title of the ad that the visitor clicked on. Just keep that in mind when you open the Ad Versions report and see more data than you expected. :)

You can also get creative with your link tagging. I like to add a lot of information in the utm_content variable. In the example above I added the offer that was different in each email. I could also add information that identifies which link in the email that the visitor clicked on. Here’s an example:

Adding additional information to utm_content creates a lot of data and sometimes it is not useful. Plus, many email distribution tools will also report which link visitors click on, so this technique can create duplicate data. But the option is there if you want to try it.

So there you have it. Don’t forget to test different offers in your email marketing. And there is no better way to measure email conversions than with Google Analytics.

5 Comments »

Google Analytics Short Cut

As some of you may have noticed, my book PDF e-book has been published! Google Analytics Short Cut hit the web on August 31 and is now available for purchase at O’Reilly’s website.

In my opinion, and I’m a bit biased after writing for all those hours, it’s a pretty good deal for $10 US. Let me tell you why…

If you’re interested in learning more about GA Short Cut please visit gashortcut.com and please make sure you read the acknowledgments. If you’d like to hear what others are saying you can read the reviews on O’Reilly’s site or check the reviews on gahortcut.com (If you’re interested in writing a review please let me know. I would be honored.)

Finally, I’d like to thank all of you. Thank you for sharing your thoughts, questions and ideas with me. Thanks for adding to the discussion and helping me grow and learn. I had no idea that blogging would lead to so many opportunities. But, more importantly, I had no idea it would lead to so many new friends.

19 Comments »