Google Analytics is the best free traffic analysis software available. It can handle pretty much any sized website (at least within reason), and has a number of fairly advanced capabilities.
Basic Install is pretty well covered by Google's Docs. Be sure to use the new _gaq asynchronous code, not any of the older codes (urchin.js, _gat code, etc.). Make sure that the tracking code appears once, and only once, on all of your pages.
Once you get that done, login and start looking at your reports. Note that (annoyingly) any configuration changes you make to your reports (e.g. apply a new filter, change your default homepage filename, etc.) only affect data from that day onward. You can't go back and reprocess old data.
Google Analytics has five tracking areas in the Standard Reporting section: Audience, Advertising, Traffic Sources, Content and Conversions.
In most reports, Google Analytics tracks pretty much everything via Visits, which is one person being active on the site. They can be active as long as they want, but as soon as they are inactive for 30min or more, their visit ends. If they come back, they are counted as a new visit. They also offer Visitors; these are unique across the entire time period you're looking at. So if somebody visited on Monday, and then visited again on Wednesday, they'd have two visits but be one visitor. The visitor cookie doesn't expire for two years.
Pageviews counts the number of individual pages that has been viewed; a reload of a page means that page is counted again. Unique Pageviews filters out reloads (so if you reload a page ten times, that's ten pageviews but one unique pageview). Unique Pageviews only count across visits, meaning if someone views a page, waits 30 minutes (and thus their 'visit' ends), and then views the same page again, that is two unique pageviews (one from the first visit and one from the second visit). Thus, 'unique pageviews' is not the same as 'pageviews by unique visitors', since a single unique visitor may record multiple unique pageviews if they visit the same page in more than one visit.
Each GA profile gives you up to four Goal Sets that you can track, each of which can contain up to five Goals. You don't have to insert any special code into your pages for these; GA matches your goals based on the URL of the page. In my opinion, the best thing to do is to write regular expression matches against the URL; this allows you a lot of flexibility you wouldn't have otherwise.
For example, WHMCS 3.4.1 has a checkout process that can end on either creditcard.php?invoiceid=XXXX OR order.php?step=6. So, you'd make your Goal URL (order.php\?step\=6)|(creditcard\.php\?invoiceid\=[\d]*), which would match either page. If you make your Goal URL a regular expression, you need to make your goal steps the same, e.g. order\.php$, which matches any URL that ends in order.php.
In 2011, Google added Event Goals, which allow you to track goals based on Event actions rather than just pageviews.
Filters are one of the most powerful features of GA. They let you include or exclude certain pages/subdirectories, and do search and replace operations on URLs (or other variables).
The most important (and most annoying) thing about filters is that they run when the original data is collected, and ONLY when the original data is collected. If you make a mistake, or you just want to go retroactively apply a new filter to your data, you can't.
Google recently provided a new piece of code, ga_debug.js, which you can use for debugging Google Analytics. To use it, simply change your call from '/ga.js' to /u/ga_debug.js in your Google Analytics code. Detailed information about what GA is doing will start appearing in your console window.
You can exclude certain query parameters in your URLs from being counted as separate pageviews. For example, one vendor I've worked with routinely sends traffic that looks like this:
/mypage.html?tqnm=xj5xevt811023430&o=106423&c=CL&p=585330&cl=&cp=&eb=1&ci=&bq=&r=&lang=&cista=0
However, every time they send different parameters, which GA records as unique pages. That's not what I want, since I really only care about hits on /mypage.html. To fix this, I go into 'Profile Settings', and add the string:
tqnm,o,c,p,cl,cp,eb,ci,bq,r,lang,cista
to the 'Exclude URL Query Parameters'. GA basically strips those params from my URLs, meaning 'mypage.html' is recorded consistently.
You can track your inbound sources of traffic with utm_ campaign tracking variables. See Using and Standardizing UTM Campaign Variables in GA.
GA lets you set a 'default page' in the profile settings (e.g. index.html or index.php). It then converts any root level (/) requests to the equivalent default page URL (e.g. /index.php), and displays those in its reports. The problem is that sometimes you might have those files redirected, or they otherwise can't be accessed at /index.php. You also can't set more than one page to be your 'default page'.
A better solution is to setup a filter, which renames index.php, home.php, and whatever else you want to /. Then all of your URLS are listed in GA as /, which is more useful. To do this, setup a 'Search & Replace' filter on the 'Request URI'. Search for /+index\.php and replace with / .
You can use the GA campaign feature to track marketing campaigns, including email.
If a user loads your page out of the Google Search cache, your Google Analytics code WILL run, and you'll record a hit for that page. Generally, this is probably OK… I think a cached hit is still a 'hit' on your site. If you don't want this to happen, you can setup a filter to filter out the cached traffic.
Update 1 Nov 2012: This method of tracking users is deprecated; use ''_setCustomVar()'' instead.
GA has a 'user defined' segment, and you can pass your own variable into it and then segment your reports on that variable. To do this, call _setVar() in your code:
// any user with $isLoggedIn set to true will have the user defined GA variable // set to 'logged-in' pageTracker._setVar(<?= $isLoggedIn ? "'logged-in'": "'logged-out'"; ?>); pageTracker._trackPageview();
There are a few things to keep in mind:
_setVar() again, it will overwrite the existing variable. There is a way to set more than one, but it is a bit cumbersome._setVar('logged-in'); ) on his visit today, and he comes back tomorrow, tomorrow's visit will still be tagged with 'logged-in', even though you didn't explicitly set it again. As before, this can be good or bad, depending on what you want to do._setVar() on every page load, it may break the bounce rate calculation in GA. This is because _setVar() records a secret second pageview every time it is called. I wrote up some code to fix this 'zero bounce rate' problem, so _setVar() is only called once and then the value is read out of the cookie.
If you want, you can inject a pageview into the Google Analytics stats. This is done by calling _trackPageview() again, but with an argument. Generally, you'll want to do this with a 'click' event, or similar:
_gaq.push(['_trackPageview', '/my/named/url/here']);
Needless to say, the main google code should have loaded before you try to call this function, but if you're putting it in an onclick, odds are that it has.
Google Analytics can also track events. An event is some sort of in-page action, such as clicking on a popup. An event has several properties, and you call it like this:
_trackEvent(category, action, label, value, noninteraction)
category (required): A name for the group of events you want to track. This might be a section of your website, like 'Products'action (required): The name of the action in that group. E.g. 'ClickProductDropDown' label (optional): Additional data about the event. In the above example, it might be the item they clicked on in the product drop down.value (optional): a numeric value you can passnoninteraction (optional): set to true if you don't want this event used in the bounce rate calculationIf you're using event tracking, I suggest that you wrap your tracking code in an if statement to check if an event has been tracked already. For example:
var trackShareSubmit = false;
$('#home .btnShareSubmit').mousedown(function() {
if (!trackShareSubmit) {
_gaq.push(['_trackEvent', 'Home', 'ShareForm', 'Submit']);
trackShareSubmit = true;
}
});
Why do this? For most applications, it helps keep your data clean. For example, what if you're trying to figure out what percentage of people clicked on your 'Contact Us' popup? If somebody clicked on it, closed it, clicked on it again, etc. they'll record an event each time. You can filter this out in GA, but it makes your life harder.
Lastly, notice how I used mousedown() above, rather than click()? You'll usually want to track your events that way, especially the button takes the user to another page. The few hundred milliseconds between a mousedown event and the mouseup event gives your tracking time to call Google before the page is destroyed, so you get more reliable results, especially on slow connections.
Finally, you can |track social events. Social event tracking feeds data into the new Social Traffic Sources report. Google Plus is tracked automatically; for other sites you'll need to setup a manual link, as described in the doc linked above.
In contrast to the doc above, I recommend you only track 'positive' actions (e.g. like, tweet, etc.) and not include 'negative' actions. This makes the social report a little easier to read; by default GA displays all actions and so a like followed by an unlike would be counted as two actions. Thus, without complex filtering, you might think some like buttons are performing better than others (e.g. have more actions), when they're actually performing worse, due to the high number of unlikes.
Both Facebook and Twitter happen only on an actual action (e.g. actually tweeting something). That's because they use the public API's on the respective services, and fire on a callback. Pintrest, as of this writing (Nov 2012) doesn't have a similar public API, so your only option is to fire the social tracking event when you click on the pintrest button. I'm 50/50 on that approach, because it means you'll likely over-count your social interactions.
GA doesn't seem to like 301/302 redirects when validating tracking codes. It's a fairly common technique to redirect startupcto.com to www.startupcto.com (or vice versa). If you tell GA that your tracking code is on startupcto.com, and that redirects to www.startupcto.com, GA will never validate that you have properly installed your tracking code. You must set your Website URL to the non-redirected domain, e.g. www.startupcto.com.
There are numerous ways to track sub-domains in Google Analytics, but I think this one is the best. The basic idea is using one profile for all sub-domains, and then creating sub-profiles (with filters applied) for each sub-domain.
You may want to set the campaign cookie timeout to something short (such as seven days) rather than the standard six months. For more, see the article on old campaign data appearing in new reports.
The full GA API is available.