Designing A Google Analytics Friendly Site
“So we’re designing a new site,” the question usually starts, “And, we want to make it Google Analytics friendly.” As you design (and if you design with GA in mind), here are some things to think about. Yes, there are plenty of workarounds if you don’t design for GA and then discover it later, but if it’s all the same, why not make your site easily measurable? BTW, I always say, don’t sacrifice your conversion for your measurement. If you know that something is hard to measure but you also have some data that leads you to believe that it converts well — go for it.
Try to have a unique “thank you” page for every goal you are going to measure. Also, think about rolling up thank you pages into one goal that you can later take apart, as needed. For example, you might want the following two thank you (success) pages: www.mysite.com/thanks/contactus and www.mysite.com/thanks/request-bid. You can now make those into two separate goals, each with their own success page, or roll them together using this head match, /thanks/ — then when you want to look at the contribution of each, check out the “Goal Verification” report.
Tracking sections of your site
Companies who are interested in tracking whole sections of their site — maybe even creating a separate profile for those sections — would be wise to name the URLs so that they can be easily accessed in the Content > Content Drilldown report. That report is ultimately just a report of directories, so you will see www.mysite.com/folderA and www.mysite.com/folderB, etc. Then when you drill down on /folderA, you see /folderA/subfolder1 and /folderB/subfolder2, etc. So if you name your URLs with a strong parent/child architecture, working to keep like content in like folders, you’ll go a long way toward tracking it. Plus, you can create a profile that just includes everything in /folderA, and one that … oh, you get it.
The domain issue
Jonathan Weber from here at Luna pointed out to me that this breaks down into two issues – a) try to use your own domain at all times (yes, there are workarounds) and b) If you can’t, determine if the third party domain(s) support cross-domain tracking.
If you have the luxury of staying on the same domain throughout your whole site, try to. I am often surprised by companies who choose to create a second domain in an effort to have a “micro site” strategy — it is not only harder on your GA, but harder for your SEO team. If you must go from domain to domain, be prepared to do the cross domain work required of GA, or be prepared to live without data you might otherwise want (such as unique visits, or referring source for those visits that went to the other domain.)
Above, I assumed a variety of things about that third party domain. The big question is, can you put code on it? You can’t put code on a wordpress.com site (as opposed to to your WordPress.org blog that is software you have downloaded.) You can’t put code on your PayPal checkout. Everyone who has cool workarounds for these is welcome to weigh in.
People always ask if they should do blog.mysite.com or mysite.com/blog. Since this post is about Google Analytics — the former, i.e. blog.mysite.com, just requires an extra line of code in your Google Analytics tracking code (not such a big deal.) But if you are choosing — subdomains are not nearly as good for SEO as folders (mysite.com/blog) are.
Frames and iframes
They are just hard to work with. Not impossible, but since “you asked,” you probably want to have a good reason for them if you care about GA Friendly (and easy.)
Server side redirects are the easiest way to go — be sure that they pass along query parameters.
The small stuff
Well, they say that you shouldn’t sweat the small stuff. So if you have /path and /path/ (i.e. an extra trailing slash) or if you have the same page with various names, you can change it with filters. Of course, when your site becomes millions of pages, that is no longer so easy — but then, it’s no longer small stuff, is it?
Your turn — Robbin