Upcoming LunaMetrics Events
San Francisco, Apr 28-30 Los Angeles, May 12-16 New York City, May 19-23 Chicago, Jun 16-18

Author Archive

Privacy and GA for Flash

You can use GA to track visitors without any JavaScript on your pages. It’s called GA for Flash. It can be done entirely within a tiny Adobe Flash file embedded on every page of the site. This method uses “flash cookies” to persist data, so that even if visitors turn off or delete their browser cookies, these Flash Cookies will still exist. They can be deleted, but not with the same tools/settings used to control browser cookies — they are a separate thing.

Is this a privacy concern?

Why do some people feel that browser cookies are okay to track with, but not flash cookies?

What can we do and should we do to ease those concerns?

These were some of the questions brought up in a recent discussion. My take is that it is really all about one thing:

** It is about empowering visitors with the ability to control their own privacy. **

Browser cookies have 3 things that make this happen:

1. Sensible browser defaults to control cookies
2. General knowledge and awareness of what cookies are and what they do
3. Accessible tools with which to control the behavior of cookies

Think of it in terms of buying a new car.

Did you know, that if you don’t change the oil in your car, it will stop running?!?

Hey, wait a minute! Is that fair? Can they do that??

It is fair for the same 3 reasons:
1. Sensible Defaults: Oil gauge denoting low oil, light indicating oil change needed, prominent checklist in the manual
2. General Knowledge: (nearly) everyone knows they need to change their oil.
3. Accessible Tools: Oil change shop on every other block, prominent oil displays at Auto Zone, etc

But what if you bought a new car that also required you to change the Flash-Oil in your car or it will stop running? Huh? The dealer never told me about this new Flash-Oil stuff. They don’t do that at Jiffy Lube. It’s not part of the standard maintenance when I take in my car to the dealer.

Of course, the mechanics and car lovers all know about the Flash-Oil. They say, “It’s nearly as easy as changing your regular oil, we don’t see what the big deal is. You can buy it and change it yourself.” But for everyone else, it’s a huge WTF moment!

Sure, Flash-Oil might be in some obscure page of the user manual, and hidden on a back-shelf in AutoZone. But if your car stopped running because you didn’t change the Flash-Oil, would you be happy when the dealer said it was your fault, told you that you’d need to buy a new engine and pointed to a single paragraph on page 203 of the manual and said “see, it’s right there, you have to change the Flash-Oil or the engine locks up”. Would you sue? Maybe. Would you win? Possibly.

But would any car manufacturer do this? Absolutely not.

Once flash cookies have those 3 key things, it will be much harder to consider them “stealth” tracking, and the concern about them will be greatly lessened.

How do we get there?

Well, how did we get there with browser cookies?

It seems that early on, those 3 key things didn’t exist. Once cookies started to gain more widespread use to track people and persist information, people began speaking out, and raising concerns, this led to the general awareness. Pressure was put on browser makers to create sensible defaults, and individuals interested in privacy and control began to make tools and browser plugins to control cookie behavior.

We’re going down much the same path with flash cookies. We are at the early stages now. They are starting to be more widely used, and people are beginning to speak out about privacy concerns.

This doesn’t mean that tracking visitors with flash cookies is wrong.  We can’t wait until all these things are in place before we start using it to track . . .because those things are only going to happen if flash tracking gets used.

We just need to be aware of our responsibilities to our fellow internet users. We should encourage the support of flash cookie settings in browsers, aid in the general knowledge about Flash tracking and how to monitor/delete/control that data.

Sure, we can put it in our websites’ privacy policies, but doing that and saying “well, our job here is done” is equivalent to that single reference to Flash-Oil on page 203.

Much better is, as Jeremy Aube suggested, putting it in your privacy policy and then saying “. . .and here are the methods and tools you can use to manage these flash cookies . . .”

Part of the struggle is that, by ourselves, there isn’t a lot more we can do.  I can’t force Firefox to add settings for Flash Cookies, for example.

Again, it all comes down to trying to make sure the visitor is in control of their own privacy.

Of course, whether or not there should be or can be privacy on the internet is another issue.  And maybe the legitimate answer to all of this is that privacy can no more be expected on the internet than it can be expected walking down the streets of New York.

Finally, thanks to Brian Clifton, Jeremy Aube, and everyone else who got me thinking about about this issue.

- John Henson

Change the way GA Reports look

This is an update to some Custom CSS that I published a while back.

At the time I was working on some analysis and was incredibly frustrated because all I saw was a bunch of URLs that looked like this:

no-overflow

This was especially frustrating because up to the point that the URLs got cut off, they were exactly the same!

I had been frustrated by this before, but this time it was unbearable and I put things on pause to write some custom CSS that gave me something like this:

Overflow-1

Now, I could see the URLs and actually learn what I needed to learn.

Now, Why is this version different?

With the upcoming Secondary Dimensions, you have more information and less room:

no-overflow-secondary

Using my Custom CSS, we can see what all these URLs are at the expense of a longer report:

overflow-secondary

To me, this is a lot better than trying to mouse-over each item and quickly look at the tool-tip.

In addition to getting ready for the Secondary Dimension release, this CSS also makes some modifications to some other areas of the GA Report Interface that I found annoying.

Many areas in the Interface ask you to input URLs or Regular Expressions into this Tiny, Tiny text box:css-filter-old

Look at all that room on the right side of the screen.  Why aren’t we using that?  That’s just crazy.

So now, the Henson-version:css-filter

Oh yea, that’s much better.

In this new version, you’ll find much longer form fields like this in most places.

Instructions

The new .css file can be found at http://www.lunametrics.com/overflow.css

I use the Firefox extension “Stylish” for this.

1. Once Stylish is installed, download the overflow.css.

2. Right click on the Stylish Icon in your browser’s status bar.

3. Select Write New Style -> Blank Style

4. And paste in the contents of overflow.css into the text box.

5. Give this new style a Name, and click save.

If you don’t use Firefox or don’t want to use Stylish, there are additional instructions in the original article.

(Just use the css from overflow.css instead of what is in that article.)

Additional Reports modified:

Goal Funnel: Entrance and Exits use previously empty space.

Custom Reports: Overflow should work here

Content Detail: Content Pulldown menu is longer

And I’m pretty sure there are a bunch of others.

PLEASE NOTE: I am not a CSS expert. In fact, a lot of this was trial and error (mostly error). It displays well at the resolutions I generally use.  Your results may vary.

As always, let me know if you find any problems, and thanks to everyone who helped me out by testing this and giving feedback.

Enjoy,

John Henson

Mistakes with Include Filters

There is one particular mistake I see over and over with regard to setting up filters in Google Analytics.  This has been talked about before, but it comes up so often that I don’t feel bad about addressing it again (and again, and again).

The Mistake

Multiple Include Filters, causing no data to get into the profile.

What it looks like

1. Include – Request URI – /page.html

2. Include – Request URI – /other.html

What is intended?

The person that adds these 2 filters to a profile wants to include both /page.html AND /other.html.

But why doesn’t that work?

The Technical:

When GA processes filters it does so, sequentially, one at a time.  Filters are like a series of gates, in-line, along a road. In order for data to get from point A to point B, it has to pass through each gate in turn. If there is any one gate that it can’t get past, then no point B and it doesn’t end

Create New Filter - Google Analytics

up in the profile.

Each Include filter can be thought of as an “Include Only” filter.  Let’s look at the 2 example Include filters above with that wording in mind, and see how far our data makes gets.

Data –> A) /page.html, B) /other.html, C) /index.html

1. Include – Request URI – /page.html
2. Include – Request URI – /other.html

The first thing that happens is our data is checked against Filter 1.

Filter 1 says “Include ONLY data that has a Request URI that matches /page.html”
Data A matches /page.html
Data B does not match /page.html
Data C does not match /page.html

Now we have
Data –> B) /other.html, C) /index.html   -> didn’t make it past the filter
1. Include – Request URI – /page.html
Data –> A) /page.html
2. Include – Request URI – /other.html

The only piece of data that made it past Filter 1 was Data A, /page.html

Now it is tested against Filter 2, which says “Include ONLY data that has a Request URI that matches /other.html”

/page.html, is tested against Filter 2, /other.html.  It does not match, and ends its trip short.

So, no data in our set can possibly make it past both filters, since there is no single page that can match BOTH /page.html AND /other.html

Just above the enter key

The Solution

The solution is to use a single filter that looks like this:

1. Include – Request URI – /page.html|/other.html

We put both pages that we want to include into a single filter and seperated them with a pipe.  The pipe is the vertical bar symbol usually located just above the Enter key.  This is a Regular Expression (RegEx) symbol that can be read as “Or”.  So the filter says Include ONLY pages that match either /page.html OR /other.html.

Dot or Not

We often hear variations on the question “Do we need the leading dot when using _setDomainName”.

With the dot:
pageTracker._trackPageview(‘.lunametrics.com’);

Without the dot:
pageTracker._trackPageview(‘lunametrics.com’);

The _setDomainName method is used to tell GA what to set the “domain” to, for the cookies that it uses to keep track of visitor information.  This “domain” field for the cookies are used as part of the security in browsers to determine what websites can access what cookies. (You don’t want porn.com getting access to your amazon.com cookies, for example.)

The Google Analytics documentation recommends using a preceding dot.  For example: pageTracker._setDomainName(‘.lunametrics.com’)

The example above allows any lunametrics.com subdomain to access the same cookies.  (blog.lunametrics.com and help.lunametrics.com are both still “lunametrics.com” so the browser says this is okay)

In most cases, it doesn’t really matter whether you use ‘.lunametrics.com’ or ‘lunametrics.com’.  As long as you’re consistent across the entire website that you’re tracking. That’s part of the confusion.  Both ways work fine.

However, Google explains, in cases with multiple levels of subdomains, you can sometimes run into problems if you don’t use the preceding dot with _setDomainName.  If we had robbin.posts.blog.lunametrics.com the browser may not let the GA code on that page have access to cookies written with _setDomainName(‘lunametrics.com’), but it would allow access to cookies written with _setDomainName(‘.lunametrics.com’).

_initData() — Always there, or always not.

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

Cross-domain tracking and _setVar

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

Using Different Cookies When Tracking to Multiple Accounts in Google Analytics





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.

cookies

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

Pitfalls of Tracking to Multiple Accounts in Google Analytics





Tracking to multiple accounts? What’s that?

googleyticslogoWhen you create a GA account, you get an account number starting with “UA-” followed by a string of digits. When you put the GA Tracking Code on your pages you must specify what account you want it to send the data to by including this account number. If you want to send that data to multiple accounts you need to duplicate portions of the Tracking Code and include both account numbers:

<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._trackPageview();

var otherTracker = _gat._getTracker(“UA-22222-1″);
otherTracker._trackPageview();
</script>

Async Version:

<script type=”text/javascript”>

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-11111-1']);
_gaq.push(['_trackPageview']);

_gaq.push(['_setAccount', 'UA-22222-1']);
_gaq.push(['_trackPageview']);

(function() {
var ga = document.createElement(‘script’); ga.type = ‘text/javascript’; ga.async = true;
ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl’ : ‘http://www’) + ‘.google-analytics.com/ga.js’;
var s = document.getElementsByTagName(‘script’)[0]; s.parentNode.insertBefore(ga, s);
})();

</script>

Above we see two lines duplicated with different UA numbers. The data for the page that includes this code will be sent first to the account UA-11111-1 and then to the account UA-22222-1.

But when you do this there is the possibility that you may not get what you think you’ll get.

Using this method, the same cookies are used for both keeping tracking of information sent to both accounts. This opens the door for some potential problems.

1. Non-Identical Code

Some things you can do with the GA code can cause it to write cookies in different formats. If this happens GA can get a little confused. Okay, a lot confused. Here’s an example that will cause you you problems:

<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._setAllowHash(false);
pageTracker._setAllowLinker(true);
pageTracker._trackPageview();

var otherTracker = _gat._getTracker(“UA-22222-1″);
otherTracker._trackPageview();
</script>

Async Version

<script type=”text/javascript”>

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-11111-1']);
_gaq.push(['_setAllowHash','false']);
_gaq.push(['_setAllowLinker','true']);
_gaq.push(['_trackPageview']);

_gaq.push(['_setAccount', 'UA-22222-1']);
_gaq.push(['_trackPageview']);

(function() {
var ga = document.createElement(‘script’); ga.type = ‘text/javascript’; ga.async = true;
ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl’ : ‘http://www’) + ‘.google-analytics.com/ga.js’;
var s = document.getElementsByTagName(‘script’)[0]; s.parentNode.insertBefore(ga, s);
})();

</script>

In the above code, the first tracker includes the lines to allow for Cross-domain tracking in GA. This means that the first set of code will try to write cookies in one format, but the second set of code will try to use a different format.

Using Cross-domain tracking is fine, but you have to make sure that the code is the same for both trackers. If you do it in one, make sure you put the same lines into any additional trackers.

2. Different Pages

Another problem you can encounter is not having the Tracking Code on all the same pages. That is, some pages are tracked to both accounts, while others are only tracked to one account.

The problem here is, again, that the same cookies are being used. So, I view a page that is only tracked to Account A, and then view a page that is tracked to both Account A and Account B.  The Account B code will see the cookies that were originally created by a page that had No Account B tracking code. The first pageview recorded to Account B will have referral information created on a different page. It will think this is the second pageview, etc.

So, make sure the same code is on all the same pages for consistent tracking.

3. User Defined Segments

The User Defined Segment value is stored in a cookie (__utmv). Since both sets of code are using the same cookies, once you set a User Defined Segment for one, you’ve set it for the other as well. You can’t have one set of User Defined Segments for the first set of code, and another set of User Defined Segments for the second set of code.

For example, you can’t use the first set to keep track of Member/Non-member and the second set to keep track of Male/Female because they will overwrite each other.

<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._setVar(‘Member’);
pageTracker._trackPageview();

var otherTracker = _gat._getTracker(“UA-22222-1″);
otherTracker._setVar(‘Male’);
otherTracker._trackPageview();
</script>

Async Version:

<script type=”text/javascript”>

var _gaq = _gaq || [];

_gaq.push(['_setAccount', 'UA-11111-1']);

_gaq.push(['_setVar','Member']);
_gaq.push(['_trackPageview']);

_gaq.push(['_setAccount', 'UA-22222-1']);

_gaq.push(['_setVar','Male']);

_gaq.push(['_trackPageview']);

(function() {
var ga = document.createElement(‘script’); ga.type = ‘text/javascript’; ga.async = true;
ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl’ : ‘http://www’) + ‘.google-analytics.com/ga.js’;
var s = document.getElementsByTagName(‘script’)[0]; s.parentNode.insertBefore(ga, s);
})();

</script>

In this example, because of the way that GA handles _setVar, when the visitor comes back for a second visit he will be classified as “Male” in both accounts.

These are some of the most common issues I’ve seen when troubleshooting these types of implementations.  Hope this gives you some things to look out for, and if you have any questions, feel free to use the comments to ask.

John

Campaign Tracking using _setAllowAnchor

As you know, Google Analytics allows you to define a campaign with marketing parameters at the end of a URL linking to your site.  You can set things such as the name of the campaign, the medium, the source, etc.

The _setAllowAnchor method [http://code.google.com/apis/analytics/docs/gaJSApi.html#_gat.GA_Tracker_._setAllowAnchor] in GA allows you indicate these parameters in the URL with a # symbol instead of the ? symbol that is normally used.

However, the documentation for this method is a little confusing, so I’d like to go over how to use it.

The JavaScript

To enable the use of the # symbol for your GA campaigns we need to add one line into the middle of your existing GATC.  Everyone’s GATC may look a little different, but everyone should have the lines below.

var pageTracker._gat._getTracker(‘UA-xxxxxx-y’);
pageTracker._trackPageview();

Somewhere in between those two lines you need to add a line of JavaScript:

var pageTracker._gat._getTracker(‘UA-xxxxxx-y’);
pageTracker._setAllowAnchor(true);
pageTracker._trackPageview();

This change should happen on every page of your website.

The Campaign URLS

After making the above change to your GATC, you can still use the standard campaign tracking parameters.  You do not need to change any of your existing campaigns.  But you also get the option to use an alternate version of campaign tracking. In the alternate version, you are just replacing the ? with a #.

This standard method for campaign tracking uses a URL that looks like this:

http://www.lunametrics.com/index.html?utm_source=december&utm_medium=email&utm_campaign=monthlynewsletter

The alternate method for campaign tracking uses a URL that looks like this:

http://www.lunametrics.com/index.html#utm_source=december&utm_medium=email&
utm_campaign=monthlynewsletter

The Example in the GA Documentation looks like this (This doesn’t work):

http://www.lunametrics.com/index.html?utm_source=december#utm_medium=email#utm_campaign=monthlynewsletter

Four Examples in GA

Here is an example of 4 different variations and what you will see in Google Analytics as a result:

1.   ?utm_campaign=1&utm_medium=1&utm_source=1
2.   ?utm_campaign=2#utm_medium=2#utm_source=2
3.   #utm_campaign=3&utm_medium=3&utm_source=3
4.   #utm_campaign=4#utm_medium=4#utm_source=4
all-traffic-sources1
As you can see, when the # is used in place of the &, GA doesn’t seem to recognize it as a separator.

So there you have it.  I hope it is fairly straight-forward.

UPDATE

Someone pointed out that I had overlooked a possible situation.  What happens if your URL already contains a query parameter such as ?page=123, what then?

**If your original URL looks like this, then the # replaces the first ampersand.**

This URL:

http://lunametrics.com/?page=1234#utm_source=henson&utm_medium=john&utm_campaign=test

Will provide this result:

campaign-google-analytics

And remember, campaign tracking doesn’t have to be cam-painful.

(more…)

When to not do cross-domain tracking

Cross-domain tracking is great.  But just because you can do something doesn’t always mean you should.  This goes for cross-domain tracking as well.  Sometimes tracking two domains as separate sites instead of together, may be the right approach.

While there is no hard-and-fast way to make this decision (that I know of), here are a couple things to consider.

*Can visitors be commonly expected to cross from one domain to another to accomplish your goals?  Their goals?
*Do the domains serve different audiences?

Imagine, for example, pbs.org and pbskids.org.  These two sites (usually) serve very different audiences. And someone would not normally be required to cross from one domain to the other in order to accomplish their goal.  This situation is probably best served by tracking them as different sites without any cross-domain tracking.

Another example is a company such as Perillo Tours that sells vacation tours.  There is one domain that is the consumer facing site (perillotours.com)– you and I can buy a tour on this domain.  The other domain is for travel agents to purchase tours for their customers (perilloagents.com).  Both sites are virtually identical (they provide almost the exact same functionality, after all).  Although you can move between sites, the two domains are serving different audiences and the visitors would not need to cross domains in order to accomplish goals. This is another example of when you’d not want to use cross domain tracking.

Again, these are just a couple examples and some things to think about when trying to decide if you want to implement cross-domain tracking. It may not apply to most of you, but for those in a situation like this, I hope it helps get you thinking about how to implement GA for your domains.

John