Google Analytics Tips Learned, Part I - Introduction

This post is a continuation of a multi-part series on Google Analytics.

1. Part I - Introduction
2. Part II - Setup
   

Since returning form HigherEdWebDev 2007 in October, I have received many emails from followers of this blog and developers in the higher ed community asking me to help shed some light on Google Analytics. Questions have ranged from how to set up GA, to best practices with advanced features such as campaign and newsletter tracking. I'm happy to help, and as I have done so, I've learned many new tricks and techniques along the way.

Website analytics has, as of lately, picked up steam in our industry. Much of this, I feel, is related to adoption of Google Analytics. Data used for major decision making has become easily and inexpensively obtainable. A well-rounded web worker is no longer defined by his or her coding and design ability, but also his or her ability to decipher analytics and either make decisive decisions based on these statistics, or assist in the decision making.

With this in mind, I am starting a multi-part series of posts related to Google Analytics. I will explore topics ranging from basic setup to advanced filtering and goal setting. I will share many of my experiences and tips that I have found through trial-and-error. In the end, I hope you will have enough information to get started with Google Analytics.

WHAT GOOGLE ANALYTICS IS AND ISN'T
Much like there are two web-scripting technologies - server-side and client-side - there are two analytics technologies - also server-side and client-side. Server-side analytics process web server log files (or image file requests) and regurgitate data into presentable statistics. While these technologies are usually very thorough, they are slow and require relatively large amounts of overhead and server processing. Changes to report criteria take time to reprocess and render. Inclusion of future data also requires reprocessing. In addition to latency, the more robust of packages are expensive.

Google Analytics takes a different approach; it works on the client-side and tracks data through a JavaScript call. User data is sent to the Google servers, where it is deciphered and generated into easy-to-use reports. This allows for quick, on-the-fly processing. In addition, the data is stored on a different server than your website thus, freeing up overhead. Because GA uses JavaScript calls, it by nature leaves out users with JavaScript turned off. While at first this may seem like a deal-breaker, you have to understand web analytics will never be an exact science. The anonymity of the web and the fluid changes in technology make exact measures impossible. Therefore, we should be tracking trends, not individual activities. By excluding users without JavaScript enabled, we are only leaving out a small percentage of users.

The JavaScript is embedded into every page in which you want to track statistics. Usually this is every HTML page in your site. When a user lands on a page with the code embedded (more on the code and embedding later), two majors functions happen: a cookie is created/updated on the client machine, and tracking information is exchanged between the cookie and the GA JavaScript file. GA then processes the information, runs any saved filters you may have, and displays the data the GA reporting environment.

WHERE TO BEGIN
Most of my early mistakes were made in the initial setup of Google Analytics. Out of the box, GA works great. However to expand and customize GA further, a few extra steps need to be taken. Since these steps are crucial to future-proofing the GA strategy, they require a separate post.