Just find the root you want to serve and use:

python -m SimpleHTTPServer

Now just point your browser to localhost:8000.

Bye bye local apache.

Google Analytics Usage on top websites:

source: builtwith.com

Imagine the responsibility of the Google engineering team that maintains the ga.js javascript file. While having to deal with multiple recent changes and new features on Google Analytics still have to make sure that their code runs as fast as possible and on all browsers that exist. They must support ie5.5 and low end mobile devices, otherwise these browsers wouldn’t show up on Google analytics reports. Still they must do it while keeping the code from affecting the website performance.

I must say that they do a great work on keeping that code. The asynchronous syntax while confusing at first is a very clever way to push code execution and loading way down on the queue, so browsers don’t delay the page loading to register a GA pageview. It’s clear that the GA team takes great care when it comes to how fast and seamless their code is.

The one point that still bothers me a lot regarding performance are the Google Analytics cookies. Let’s take a look at what GA cookies look like:

>document.cookie
"__utma=96182344.347392035.1326382423.1326382423.1326382423.1; __utmb=96182344.1.10.1326382423; __utmc=96182344; __utmz=96182344.1326382423.1.1.utmcsr=(direct)|utmccn=(direct)|utmcmd=(none)"
>document.cookie.length
188

This is a minimum GA cookie. It can get longer if you use Custom Variables and Google Website Optimizer. But let’s settle down with the minimum for now.
These cookies are used iternally in GA to keep state and are manipulated by the code on ga.js javascript file. Different from most other cookies you might see out there these cookies don’t need to hit your webservers never. Still they hit your website every single time an HTTP request is made.

According to Google SPDY whitepaper the average HTTP request is 700-800 bytes long. That means that GA Cookies represent about 25% of that HTTP request size. The moment you notice GA is present in about 50% of top websites you notice that useless GA cookies going around the internet represent 12% of all HTTP requests.

I’ve posted a bug regarding this issue on GA-Issues a while ago. The idea is to use HTML5 localStorage to store the cookies on browsers that support it. Still it has attracted no attention so far. This bug fix could easily make the average HTTP request around 5% faster. We’re talking about the average speed of the whole internet.

The real picture is not that bad, since this only affect HTTP requests and not HTTP responses and that’s where the real data is. Still it’s funny to see something that huge going around unnoticed.

With the social Tracking one specific bug bit me the other day. Google Analytics won’t apply hostname filter’s to the social interactions, and it may cause profiles that are filtered to only include traffic to domain A, showing social interactions for domain B. From there all sorts of bad things follow: 0 pageview visits, lower pages/visit and so on.

At first I thought about disabling the socialTracking on the +1 buttons, but it seems that the API don’t support it yet. But I found an undocumented feature to disable it. Now you can disable the socialtracking on the +1 button and use Events instead, since they go through the filters before showing up in your Google Analytics profile.

You’ll only want to use it if you are having problems with social tracking and hostnames filter. Otherwise the default behavior is way better since it will populate in separate Social reports.

Update

If you are using the asynchronous code for Google +1 button, loading the syntax is a little bit different.

Thanks Fábio Phms.

This kind of strategy is just sad, telling from the perspective of an SEO.

I came up with a nice oneliner to clear all that nasty code. Works great for me. May be useful for others.

find . -name "*.php" -print0 | \
xargs -0 -n 1 grep -l -Z eval.*base64 | \
xargs -0 -n 1 sed -i'.old' '/eval.*base64/ d'

Essa semana ocorreu o Search Labs 2010 em São Paulo. Eu participei junto com meu amigo Gerson Ribeiro com uma palestra sobre otimização de Landing Pages.
A Palestra está hospedada no Slide Share.

Returning Visitor

• Direct never overrides
• Campaign always overrides
• Referral always overrides
• Organic always overrides

Same Visit

• Direct never overrides
• Campaign always overrides
• Referral never overrides
• Organic always overrides

Extra

I created a graphic to illustrate precedence.

People complained about the graphic being insanely hard to read. Here are the rules that make the graphic. Looks simpler but the graphic took me too much time to just remove it now. Besides it makes the post look good.

• Campaign, Organic and Referral source always override a previous source
• Direct never overrides a previous source
• If it’s inside the same session a referral source will never override previous source

You can also use the parameter utm_nooverride=1 in your URLs. If you use this parameter and already have a previous origin it  will never overrides the existing origin.

Suppose you have something like this:

• Domain http://test.cereto.net/ that has a GATC for multiple sub-domains.
• Domain http://test2.cereto.net/ that has both our tracker and a secondary default tracker that we don’t control.

If you use this configuration it should work as expected. Two sets of cookies are gonna be created. One set inside domain test2.cereto.net and the second set inside .cereto.net. GATC will know which cookie to look at on both cases.

But now suppose you also want to track domain www.my-other-domain.com in the same account. What you’d need to do is:

• Use _setAllowLinker(true) on both accounts.
• Use _getLinkerUrl() or _link() on the links that go from one site to another and vice versa.
• Use _setAllowHash(false) on both domains.

_link() and _getLinkerUrl() will move the cookies from one domain to another. _setAllowLinker(true) is needed for GATC to look on URI for cookie parameters.

Q: Now why would you need _setAllowHash(false)? A: The GA cookies have a parameter that is a domain hash (in red below ). Of course the hashes from both our domains are gonna be diferent. In that case Google will trash the cookie when it sees that the hash doesn’t match the current domain. So we set _setAllowHash(false) and everything is  fine. Is it?

Cookie with a domain hash
__utma=253008534.504424944.1258547704.1258547704.1258547704.1

Cookie with Domain Hash disabled
__utma=1.504424944.1258547704.1258547704.1258547704.1

But now we don’t have the Hash anymore and it’s very important to GATC. When we’re reading cookies with javascript we have no information about the cookie besides value and name. The Hash is important so GATC knows which is the right cookie for that specific GATC.

In our setup we’ll have two sets of cookies available from test2.directperformance.com.br. If we disable the Domain Hash on both there’s no way for GATC to get the correct one. This will lead to ga.js firing pageviews with mixed data from both the cookies. This will mix origin, user hash, custom variables and more. Generating unexpected results on Analytics Interface.

This is an old bug. You must avoid it but sometimes there’s no way. It’s present no matter if you use default _gat or the new Async Tracker _gaq.

Example

I created a little test to illustrate the issue:

• Access first domain using a url with campaign variables. This has a single tracker/single cookie
• Now access second domain directly. It has two trackers each in a diferent domain, so 2 different cookies.
• The cookies were created accordingly, one for each tracker. The first one still has the campaign origin, and the second should be a refferal from this blog now.
• Since you have _setAllowHash(false) on both trackers, GATC don’t know which cookie to parse.
• You can see using HttpFox or similar that both pageviews have the same origin.

As explained GATC didn’t know which was the correct cookie, and got the first one.

Solution

There’s no good solution at this time, besides avoiding this setup.

All could be solved if _setAllowLinker(true) simply ignored the domain hash and used the hash for the current domain instead, after all it makes no sense to check the domain hash on the cookies you’re importing.

There’s an undocumented feature on ga.js that seems to fix it. It’s the function _setNamespace(‘ns’). If you use this on one or both trackers (with different Namespace for each of course). This problem is gone. But it’s not safe to use undocumented features as it might change in the future or removed completely generating unexpected results. You won’t want to use that on your production code.

This post is intended to get this bug properly documented since there’s no public bug tracker for ga.js and I didn’t get proper response or position from Google on any related user groups out there;

Here’s the code I used to test.

<html>
<head>
 <title>Event Tests</title>
 <script>
 if(window.addEventListener){
 window.addEventListener('load',function(){alert('event1')},false);
 }else if(window.attachEvent){
 window.attachEvent('onload',function(){alert('event1');})
 }
 </script>
 <script src='jquery-min.js'></script>
 <script>
 $(document).ready(function(){
 alert('jq1');
 });

 if(window.addEventListener){
 window.addEventListener('load',function(){alert('event2')},false);
 }else if(window.attachEvent){
 window.attachEvent('onload',function(){alert('event2');})
 }

 $(document).ready(function(){
 alert('jq2');
 });
 </script>
</head>
<body onload='alert("event3")'>
 <script>
 if(window.addEventListener){
 window.addEventListener('load',function(){alert('event4')},false);
 }else if(window.attachEvent){
 window.attachEvent('onload',function(){alert('event4');})
 }
 $(document).ready(function(){
 alert('jq3');
 });
 if(window.addEventListener){
 window.addEventListener('load',function(){alert('event5')},false);
 }else if(window.attachEvent){
 window.attachEvent('onload',function(){alert('event5');})
 }
 </script>
 <h1>Event Tests</h1>
</body>
</html>

Firefox 3.5 & Google Chrome

Firefox and Chrome both worked as expected. The jQuery Events were triggered first as I suspected and I was starting to get happy. Here’s the order they executed.

1. jq1
2. jq2
3. jq3
4. event1
5. event2
6. event3
7. event4
8. event5

Internet Explorer 8

Here on the other hand things started to get ugly. My smile fade away while ie shouted the following:

1. jq1
2. jq2
3. jq3
4. event3
5. event5
6. event4
7. event2
8. event1

Internet Explorer 6 & 7

Run while you can.

1. jq1
2. jq2
3. jq3
4. event3
5. event2
6. event4
7. event5
8. event1

I think these results are completely nonsense. I’d be glad if someone could shed some light on this behavior. At least jQuery can save you from this madness.

Conclusion

Do you want to control the way your events trigger cross-browser without insane hacks? Go with jQuery.