During some troubleshooting this week, I came across something that some of you may find useful or interesting (or maybe not.)

You may already know that the pageTracker._initData() line in the GATC has been deprecated.  It can still be used however, and is often in place on many websites.

But when you call pageTracker._initData() on some pages, and Don’t call it on other pages, that is when you have a problem.  It seems that the cookies are written slightly differently when initData is present vs when it is absent.  This causes GA to lose track of the visitor, and lose track of how they arrived at your site (Source, Medium, etc).

Make sure you are consistent throughout your site, with pageTracker._initData(), and you should be fine. Either use it everywhere, or use it nowhere.

— Update/Addition/Clarification:—

If you include initData you need to make sure it is placed after any instructions that alter the way GA writes cookies, such as _setAllowHash(false) or _setDomainName(’none’)

Example:

Bad:

var pageTracker = _gat._getTracker(”UA-xxxxxxx-y”);

pageTracker._initData();

pageTracker._setDomainName(”sub.domain.com”);

pageTracker._setAllowHash(false);

pageTracker._setAllowLinker(true);

pageTracker._trackPageview();

Okay:

var pageTracker = _gat._getTracker(”UA-xxxxxxx-y”);

pageTracker._setDomainName(”sub.domain.com”);

pageTracker._setAllowHash(false);

pageTracker._setAllowLinker(true);

pageTracker._initData();

pageTracker._trackPageview();

* Thanks to Charles at Epik One for this addition

———————————–

John

Our Google Analytics training on May 12, 2009 in DC is packed. We are not accepting any more registrations for individuals who want to do configuration and implementation (techie) since that room will be filled; we can only take new registrations for those who want to learn about marketing/analysis.

However, we still have space for everyone at our NYC Google Analytics training on June 2, 2009.  It will be identical to the DC training:  one day with a marketing/analysis track and a techie track, $285/person, breakfast and lunch included as well as slides, answers to all your questions and Google goodies.

You can read about the training in either city and start the registration process here.

Robbin

When I’m looking for insights about a website, I often have a laundry list of ideas of things that might be interesting, but only if they happen to pan out. There are lots of false starts and dead ends.

That’s why it’s nice to have a way to quickly get a rough notion about whether certain kinds of visits are significant. The “Test Segment” button that appears when you’re creating Advanced Segments can help you out here.

You can try different criteria and use the Test Segment button to get the number of visits that match — all without actually creating the segments. Play around with the criteria until you get one that’s interesting, and then you’ll probably want to give the segment a meaningful name and save it. But you can cut down time creating a lot of advanced segments that turn out to be not so useful by playing with the Test Segment feature.

This is from a question that I answered on the support forum that involved cross-domain tracking and the use of a _setVar().

The problem was that the session information was being lost.  That is, GA was losing track of the visitor and started a new visit for them.  This not only would alter the visit data, but in the ’second’ visit, you would lose all of your referral knowledge and this ’second’ visit would appear direct.  Since this is where the conversion was happening, it was a real problem.

The code being used was:

var pageTracker = _gat._getTracker(”UA-xxxxxxx-y”);
pageTracker._setVar(’buyer’);
pageTracker._setAllowAnchor(true);
pageTracker._setAllowLinker(true);
pageTracker._setAllowHash(false);
pageTracker._trackPageview();

The problem here is the placement of pageTracker._setVar(’buyer’);

This is a non-obvious problem that actually comes from _setAllowHash(false);

One of the things that _setAllowHash(false) does is to alter the format that GA uses to write cookies to the visitors computer.  There are 2 lines here that write cookies, the _setVar and the _trackPageview.  One happens before the _setAllowHash and one after.  So what was happening was this:

1. pageTracker object gets set up
2. _setVar writes cookies using “Format A”
3. _setAllowHash changes cookie format to B
4. _trackPageview writes cookies using “Format B”

So what we really have is GA getting confused because of some cookie mismatches, and this is what causes the problem.

The solution is simply to make sure you call any _setVar()’s After _setAllowHash.  (Or after pageTracker._setDomainName(’none’); if you use that line.)

This was the first time I’d seen this problem.  It is probably pretty uncommon may not be very useful by itself.  But a slightly better understanding of what the JavaScript is doing may help you troubleshoot some other situation.  (And, more importantly, Robbin wanted me to write a blog post. . .)

I was afraid that with the recession, training wouldn’t be all the rage this year. But one of our Google Analytics training sessions is half-filled already, with six weeks to go.

So I rushed through all my work today in time to write this post, about our Google Analytics training in NYC, June 2, 2o09. It feels like a lifetime away, with the weather just starting to get warm (in this hemisphere. No nasty comments from Australia or S. Africa, thank you.) It’s a one-day training with two tracks. There’s a track for analysts/marketers to learn everything from GA 101 to Actionable Insights to on-sight search and Advanced Segments.  And, there’s a configuration/implementation track for techies, where you get to study cross- and sub-domain tracking, profiles, advanced filters and goals, event tracking and more. You can see the schedule here and register here.

It’s $285/person, and will be at 23rd and 5th Avenue, easily accessible by the PATH and subway.  The day includes breakfast, lunch, Google goodies and copies of all the presentations.

Robbin

Here’s the main link to the event.

In a post from last week, I talked about some of the shortcomings of Site Overlay. If understanding what visitors click on on your site is interesting to you, but Site Overlay doesn’t quite fit the bill, here are a couple of alternative recommendations.

CrazyEgg

CrazyEgg is a tool that’s designed to track what visitors click on. It will give you an overlay view similar to Google Analytics’ Site Overlay, as well as heatmap and “confetti” views showing where users clicked. The heatmap shows a “hot and cold” overview of the page, shading from blue to red, while the confetti viewYou can also get a list view of the raw data that can be exported into a spreadsheet.

CrazyEgg installs just like Google Analytics, with a simple Javascript snippet that gets copied into the pages you want to track. It lets you block internal visitors (by IP address or by special URLs).

CrazyEgg used to offer a limited free plan, but unfortunately they seem to have nixed that. Pricing starts at $9/month and is based on the number of visits and pages you want to be able to track.

ClickTale

ClickTale is another tool for tracking how visitors interact with a page, and it does some really cool things. It basically records all the mouse movements a visitor executes on your pages. Then it takes that data and provides reports that tell you things like where people hover, how many of them eventually click, where do they hesitate, and so on. It can show you things like how far down the page visitors tend to scroll, and how many fields in a form visitors fill out, whether they skip some fields, hesitate, etc. And you can even watch recordings of interaction — kind of like an informal, no-audio user test of your site.

ClickTale is also a Javascript tag-based tracking solution and offers several alternatives for blocking internal visitors. ClickTale offers a free plan for up to 400 pageviews per month. Paid plans start at $99/month.

An Example

Here’s an example of a question about a website that only using a tool like one of these could help answer. RedZone Robotics was interested in visitor behavior on their Contact Us page. The page includes a form to submit contact information and a lookup of sales representatives’ contact information based on your geographic region — both of which are tracked by goals in Google Analytics. But we were interested in people who abandoned the page without completing either of these goals.

We installed ClickTale to use its form analytics reports to see if we could understand what was going on — maybe people were turned off by filling in one of the form fields, for example.

What we found turned out to be entirely a surprise. People weren’t filling out the form, but that was because we saw a large number of visitors to the page do this:

(click to watch the recording)

They were copying and pasting the phone number from the site! The Contact Us page was a gateway to leads that came in via telephone, in a way we couldn’t have measured without a tool like ClickTale.

Other Alternatives

There are a number of other tools that offer heatmaps and similar click-tracking functions out there, including ClickDensity and Pagealizer. If you know of more, or have specific recommendations about particular tools, leave them in the comments.

—Jonathan

Do you know what the definition of an Analytics Ninja is? By rights, I should link to the blogpost of the person who coined the term, but he gets so much link love already. Plus, I think the definition should be changed:  “Analytics Ninjas have cool Ninja t-shirts.”  The sleeves are just the best, they are wide and then banded.  (You can tell that I am writing a fashion column and not an analytics or conversion blog.)  While I am at it, let me show you where to get your own.  Jeremy Hutton did all the work.  I think Jeremy or Caleb Whitmore bought this Analytics Ninja shirt for me, and I know that I have to figure out how to thank one or both of them.

Continuing on the topic of late-Friday superfluous blog posts, I have to tell you about the case of beer John Henson of LunaMetrics Fame received this week. I got an email last week with the  title, “Regarding John Henson.”  I was wondering what kind of trouble he had gotten himself into…. Anyway, the email went like this, edited a little to disguise the writer:

“I called today to ask about getting some technical support from your team on a GA Subdomain tracking issue. I spoke with John about the issue and he said shoot him over the info and he would take a look. My jaw dropped when he offered to take a look and see if there was a quick fix.

“John got back to me within 10 minutes with the catch. I have to tell you that with all the companies I have worked with this was one of the most impressive examples of customer service I have experienced. I work with many startups, have consulted for numerous clients, and have called on dozens of vendors. Never once have I seen something this gracious. [Comment from Robbin: He is talking about JOHN? Who insults me every day?]

“I am sending John a case of beer as a personal thanks. Know that any opportunity I have to recommend your company and services I will do so ….”

We didn’t really believe the beer was coming (because it is hard to get beer from another country into this one, much less into Pennsylvania), but you can see the picture here of the case John received earlier this week.

OK, enjoy your weekend; next week Jonathan will write about site overlay, part II, and I’ll tell everyone to hold June 2 for GA Training in NYC.

Robbin

People ask me a lot about the Site Overlay in Google Analytics. I always feel bad that I don’t have many good things to say about it. But to be a little more constructive, here’s some additional information about the Site Overlay.

What it’s supposed to do

It shows you an overlay of your pages with information about how many clicks each (internal) link gets, as well as conversion rates for visitors who followed the link. When you hover over the links, you can see the information. It looks something like the following when it’s working:

What can go wrong

1. You might get all zeroes for the click and conversion data.

   Why? Probably you are using a filter to rewrite your URLs, and then they don’t match what GA expects (like adding a domain name to the URL to distinguish subdomains). As a rule of thumb, if clicking on a page in Top Content to open it on the site doesn’t work, neither will Site Overlay.

   Is there a solution? You could make a profile without your filters that alter URLs, and use that for the Site Overlay. But if you have the same URLs on different subdomains, for example, the data might not be what you expect.

2. You might get nothing.

   Why? JavaScripty evilness. If you have a lot of JavaScript going on on your site, it’s possible that something interferes with the site overlay scripts that display on the site, and it just doesn’t work.

   Is there a solution? You can try to track down what’s interfering and change it to work around the site overlay, but this tends to be much more trouble than it’s worth.

Pageviews, not actual clicks

One last thing to be aware of with the site overlay: it’s based on pageviews, not actual clicks on links. So suppose your homepage has two links to the same page — maybe one in the navigation and one in the copy of the page — not that uncommon. Site overlay will report ALL the clicks for BOTH links, on both of them. It can’t tell the difference; it just knows that a visitor went to page #2 after this one.

So what can we do?

In many cases, I think the best thing you can do is forget about site overlay entirely. It’s easy to get caught up and interested in a fancy feature like this, but take a step back and ask if this kind of information is actually going to give you some actionable data. If not, why are you worrying about it?

Now, there are some decent reasons to be interested in this kind of data. Maybe you’re running internal banner campaigns cross-promoting products, and you want to see whether people click on those. Maybe what you’re really trying to do is get inside the head of a user and understand how they’re interacting with a page, sort of an informal, distributed user testing.

If you’re really interested in who clicks on what, there are a couple of tools I often recommend as alternatives to Site Overlay. They tend to work better and give more (and more interesting) data. Watch for a followup post later in the week about these. UPDATE: Here’s the post on alternatives to Site Overlay.

— Jonathan

Save the date (well, that’s what all those Bar Mitzvah and wedding pre-invitations always tell me, so I’m just stealing that line, no?)

Anyway, we’re bringing our famous one-day, two-track Google Analytics training back to Washington DC on May 12, 2009. Once again we’ll be in the amazing American Institute of Architects building. You would expect architects to have a great building themselves, and they do - awesome stadium seating, fast internet, you name it. Plus you get breakfast and lunch and all the handouts, not to mention just about unlimited access to the LunaMetrics staff and our time. (And then after the training, I write everyone to see if they have an outstanding question or two…)

We have a track for non-techies and another one for techies, and you can go back and forth if that works for you.   We ask attendees to volunteer their sites for live use, and we always get a couple of people who agree to, ahead of time.  Those people get the most out of the session, but of course, they have to share their data… When we taught in NYC in December, the UN let us use their data (nice, eh?)

Oh wait. I need some testimonials. Here is what Alec from Greenpeace wrote about us:

The GA training was great.  It definitely answered a lot of my questions and gave me some cool tools to use in the future.  More importantly though it gave me some solid direction to go in with my GA work.  Sorry we didn’t get to meet, I actually had to leave a little early so I wasn’t around for the meet and greet at the end.  I’ve been checking out your blog for a while now.  It’s definitely given me some useful stuff over the past few months, and I definitely plan on staying up on it.

And you can check out this post about someone who attended another training and decided that Google Analytics is “so much fun, it should be illegal.”

So here’s the first page of the registration for our DC Google Analytics Training. There are also FAQs, and don’t be afraid to send me email.  Address it to my last name at lunametrics.com.

Robbin Steif

The problems discussed in the previous post have been due to both sets of GA using the same cookies for holding information. Another option is to intentionally tell GA to use different cookies.  We can’t change the name of the cookies that GA uses, but we can change the domain and the path of the cookies to make them distinct.

If you have a simple site such as www.domain.com and domain.com redirects to www.domain.com this is no problem. You can use:

<script type=”text/javascript”>
var gaJsHost = ((”https:” == document.location.protocol) ? “https://ssl.” : “http://www.”);
document.write(unescape(”%3Cscript src=’” + gaJsHost + “google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E”));
</script>

<script type=”text/javascript”>
var pageTracker = _gat._getTracker(”UA-11111-1″);
pageTracker._setDomainName(’www.domain.com’);
pageTracker._trackPageview();

var otherTracker = _gat._getTracker(”UA-22222-1″);
otherTracker._setDomainName(’domain.com’);
otherTracker._trackPageview();
</script>

This causes each tracker to use completely different cookies.  At this point you no longer have the problems listed above.  You can track some pages to both accounts, and other pages to just one account without any conflict. You can use different User Defined Segments on each. And you can use cross domain tracking for one set of Tracking Code but not the other.

In addition to every cookie having a Domain that you can set, every cookie has a Path that you can set as well.  By default the Path would just be “/”.  But with GA we can use the _setCookiePath(…); method to set it to the subdirectory that we are operating in.

Just like _setDomainName can’t set the domain of the cookie to something other than the domain you’re actually on, _setCookiePath must be used to set the Path to a subdirectory that the page you are tracking is actually in.

For example, if you wanted to additionally track just one subdirectory to its own account you could use the following change on the tracking code for the pages that appear inside that subdirectory on your website. (Where “subdirectory” below is replaced with the actual subdirectory you are tracking.)

<script type=”text/javascript”>
var gaJsHost = ((”https:” == document.location.protocol) ? “https://ssl.” : “http://www.”);
document.write(unescape(”%3Cscript src=’” + gaJsHost + “google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E”));
</script>

<script type=”text/javascript”>
var pageTracker = _gat._getTracker(”UA-11111-1″);

pageTracker._setDomainName(’domain.com’);

pageTracker._setCookiePath(’/subdirectory/’);
pageTracker._trackPageview();

var otherTracker = _gat._getTracker(”UA-22222-1″);
otherTracker._setDomainName(’domain.com’);
otherTracker._trackPageview();
</script>

Again, these two trackers will use different cookies and will not interfere with each other.

Finally, I’d like to point out a comment from my previous post made by André Scholten:

Also don’t forget to add an extra trackPageview call on the links you tagged manually. For example: if you added some tracking code to a print button it wil look like this: onclick=”pageTracker._trackPageview(’print’); otherTracker._trackPageview(’print’);”

If you want the data to appear in all accounts, then anytime you call _trackPageview for one tracker, you have to call it again for every other tracker you created (In this case, just 2).