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.
_utmz=1.1267299040.3.4.utmcsr=Source|utmccn=Campaign|utmcmd=Media|utmcct=Content|utmctr=Term
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.
Google has changed the way it creates new visits. Note that the rules here still aplies. The only difference now is that any time a new source overwrites a previous source a new visit is created.
Before this change if the change occurred on the same visit a new visit would not be spawned but the new origin was still sent to analytics, this could cause sources with 0 visits in Google Analytics Reports.
GATC (Google Analytics Tracking Code) has an annoying bug with _setAllowHash.
Suppose you have something like this:
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:
_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.1Cookie 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.
I created a little test to illustrate the issue:
As explained GATC didn’t know which was the correct cookie, and got the first one.
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;
I had an issue today where my event had to be triggered after another event in the onload property of body. I wasn’t sure if my event would be triggered after or before so I wrote a quick code to test it. I was pretty sure, from the very start, that the results would disappoint me.
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 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.
Here on the other hand things started to get ugly. My smile fade away while ie shouted the following:
Run while you can.
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.
Do you want to control the way your events trigger cross-browser without insane hacks? Go with jQuery.