April 9, 2014

List of IP addresses from Cloud Providers

I wanted to create a list of all IP address from Cloud solutions out there. The initial idea was to create filters and remove those from my Google Analytics reports. I have since abandoned this idea due to the gigantic number of IPs used by these guys. No wonder we ran out of IPv4s.

Figured this list might come handy again sometime. So I'm just dropping here.

This list includes IP addresses for Google Cloud, Rackspace and Amazon. These are most likely going to change in the future, which only turns my original task even less viable.

Google Cloud

Updated 04/09/2014


They are Dynamic and can change. Can be updated with this dig request.


$ dig txt _cloud-netblocks.googleusercontent.com +short


  • 8.34.208.0/20
  • 8.35.192.0/21
  • 8.35.200.0/23
  • 108.59.80.0/20
  • 108.170.192.0/20
  • 108.170.208.0/21
  • 108.170.216.0/22
  • 108.170.220.0/23
  • 108.170.222.0/24
  • 199.192.112.0/22
  • 199.223.232.0/22
  • 199.223.236.0/23
  • 23.236.48.0/20
  • 23.251.128.0/19
  • 146.148.8.0/21
  • 146.148.16.0/20
  • 146.148.32.0/19
  • 146.148.64.0/18


Rackspace

Updated on 04/09/2014

DFW 1 Outbound IP Addresses

  • Primary: 74.205.61.228
  • Secondary: 74.205.61.229
  • Additional: 72.32.36.144/28 (72.32.36.145 - 72.32.36.158)

DFW 2 Outbound IP Addresses

  • Primary: 174.143.11.196
  • Secondary: 174.143.11.197
  • Additional: 67.192.46.0/28 (67.192.46.1 - 67.192.46.14)

ORD Outbound IP Addresses

  • Primary: 184.106.10.128
  • Secondary: 184.106.10.129 - 184.106.10.135 | 184.106.55.253

ServiceNet Outbound IPs

  • DFW: 10.187.240.5 - 10.187.240.15
  • ORD: 10.187.244.0/22 (10.187.244.1 - 10.187.247.254) | 10.187.248.0/22 (10.187.248.1 - 10.187.251.254)

Other

  • 174.143.132.196
  • 174.143.132.202


Amazon EC2

Updated on 04/09/2014

US East (Northern Virginia):

  • 72.44.32.0/19 (72.44.32.0 - 72.44.63.255)
  • 67.202.0.0/18 (67.202.0.0 - 67.202.63.255)
  • 75.101.128.0/17 (75.101.128.0 - 75.101.255.255)
  • 174.129.0.0/16 (174.129.0.0 - 174.129.255.255)
  • 204.236.192.0/18 (204.236.192.0 - 204.236.255.255)
  • 184.73.0.0/16 (184.73.0.0 - 184.73.255.255)
  • 184.72.128.0/17 (184.72.128.0 - 184.72.255.255)
  • 184.72.64.0/18 (184.72.64.0 - 184.72.127.255)
  • 50.16.0.0/15 (50.16.0.0 - 50.17.255.255)
  • 50.19.0.0/16 (50.19.0.0 - 50.19.255.255)
  • 107.20.0.0/14 (107.20.0.0 - 107.23.255.255)
  • 23.20.0.0/14 (23.20.0.0 - 23.23.255.255)
  • 54.242.0.0/15 (54.242.0.0 - 54.243.255.255)
  • 54.234.0.0/15 (54.234.0.0 - 54.235.255.255)
  • 54.236.0.0/15 (54.236.0.0 - 54.237.255.255)
  • 54.224.0.0/15 (54.224.0.0 - 54.225.255.255)
  • 54.226.0.0/15 (54.226.0.0 - 54.227.255.255)
  • 54.208.0.0/15 (54.208.0.0 - 54.209.255.255)
  • 54.210.0.0/15 (54.210.0.0 - 54.211.255.255)
  • 54.221.0.0/16 (54.221.0.0 - 54.221.255.255)
  • 54.204.0.0/15 (54.204.0.0 - 54.205.255.255)
  • 54.196.0.0/15 (54.196.0.0 - 54.197.255.255)
  • 54.198.0.0/16 (54.198.0.0 - 54.198.255.255)
  • 54.80.0.0/13 (54.80.0.0 - 54.87.255.255)



US West (Oregon):

  • 50.112.0.0/16 (50.112.0.0 - 50.112.255.255)
  • 54.245.0.0/16 (54.245.0.0 - 54.245.255.255)
  • 54.244.0.0/16 (54.244.0.0 - 54.244.255.255)
  • 54.214.0.0/16 (54.214.0.0 - 54.214.255.255)
  • 54.212.0.0/15 (54.212.0.0 - 54.213.255.255)
  • 54.218.0.0/16 (54.218.0.0 - 54.218.255.255)
  • 54.200.0.0/15 (54.200.0.0 - 54.201.255.255)
  • 54.202.0.0/15 (54.202.0.0 - 54.203.255.255)
  • 54.184.0.0/13 (54.184.0.0 - 54.191.255.255)


US West (Northern California):

  • 204.236.128.0/18 (204.236.128.0 - 204.236.191.255)
  • 184.72.0.0/18 (184.72.0.0 - 184.72.63.255)
  • 50.18.0.0/16 (50.18.0.0 - 50.18.255.255)
  • 184.169.128.0/17 (184.169.128.0 - 184.169.255.255)
  • 54.241.0.0/16 (54.241.0.0 - 54.241.255.255)
  • 54.215.0.0/16 (54.215.0.0 - 54.215.255.255)
  • 54.219.0.0/16 (54.219.0.0 - 54.219.255.255)
  • 54.193.0.0/16 (54.193.0.0 - 54.193.255.255)
  • 54.176.0.0/15 (54.176.0.0 - 54.177.255.255)
  • 54.183.0.0/16 (54.183.0.0 - 54.183.255.255)


EU (Ireland):

  • 79.125.0.0/17 (79.125.0.0 - 79.125.127.255)
  • 46.51.128.0/18 (46.51.128.0 - 46.51.191.255)
  • 46.51.192.0/20 (46.51.192.0 - 46.51.207.255)
  • 46.137.0.0/17 (46.137.0.0 - 46.137.127.255)
  • 46.137.128.0/18 (46.137.128.0 - 46.137.191.255)
  • 176.34.128.0/17 (176.34.128.0 - 176.34.255.255)
  • 176.34.64.0/18 (176.34.64.0 - 176.34.127.255)
  • 54.247.0.0/16 (54.247.0.0 - 54.247.255.255)
  • 54.246.0.0/16 (54.246.0.0 - 54.246.255.255)
  • 54.228.0.0/16 (54.228.0.0 - 54.228.255.255)
  • 54.216.0.0/15 (54.216.0.0 - 54.217.255.255)
  • 54.229.0.0/16 (54.229.0.0 - 54.229.255.255)
  • 54.220.0.0/16 (54.220.0.0 - 54.220.255.255)
  • 54.194.0.0/15 (54.194.0.0 - 54.195.255.255)
  • 54.72.0.0/14 (54.72.0.0 - 54.75.255.255)
  • 54.76.0.0/15 (54.76.0.0 - 54.77.255.255)
  • 54.78.0.0/16 (54.78.0.0 - 54.78.255.255)


Asia Pacific (Singapore)

  • 175.41.128.0/18 (175.41.128.0 - 175.41.191.255)
  • 122.248.192.0/18 (122.248.192.0 - 122.248.255.255)
  • 46.137.192.0/18 (46.137.192.0 - 46.137.255.255)
  • 46.51.216.0/21 (46.51.216.0 - 46.51.223.255)
  • 54.251.0.0/16 (54.251.0.0 - 54.251.255.255)
  • 54.254.0.0/16 (54.254.0.0 - 54.254.255.255)
  • 54.255.0.0/16 (54.255.0.0 - 54.255.255.255)
  • 54.179.0.0/16 (54.179.0.0 - 54.179.255.255)


Asia Pacific (Sydney

  • 54.252.0.0/16 (54.252.0.0 - 54.252.255.255)
  • 54.253.0.0/16 (54.253.0.0 - 54.253.255.255)
  • 54.206.0.0/16 (54.206.0.0 - 54.206.255.255)
  • 54.79.0.0/16 (54.79.0.0 - 54.79.255.255)


Asia Pacific (Tokyo)

  • 175.41.192.0/18 (175.41.192.0 - 175.41.255.255)
  • 46.51.224.0/19 (46.51.224.0 - 46.51.255.255)
  • 176.32.64.0/19 (176.32.64.0 - 176.32.95.255)
  • 103.4.8.0/21 (103.4.8.0 - 103.4.15.255)
  • 176.34.0.0/18 (176.34.0.0 - 176.34.63.255)
  • 54.248.0.0/15 (54.248.0.0 - 54.249.255.255)
  • 54.250.0.0/16 (54.250.0.0 - 54.250.255.255)
  • 54.238.0.0/16 (54.238.0.0 - 54.238.255.255)
  • 54.199.0.0/16 (54.199.0.0 - 54.199.255.255)
  • 54.178.0.0/16 (54.178.0.0 - 54.178.255.255)
  • 54.95.0.0/16 (54.95.0.0-54.95.255.255)


South America (Sao Paulo)

  • 177.71.128.0/17 (177.71.128.0 - 177.71.255.255)
  • 54.232.0.0/16 (54.232.0.0 - 54.232.255.255)
  • 54.233.0.0/18 (54.233.0.0 - 54.233.63.255)
  • 54.207.0.0/16 (54.207.0.0 - 54.207.255.255)


GovCloud

  • 96.127.0.0/18 (96.127.0.0 - 96.127.63.255)

February 21, 2012

Response to: Google Bypassing User Privacy Settings

The clueless guys from ie blog posted this blog post a couple hours ago:

http://blogs.msdn.com/b/ie/archive/2012/02/20/google-bypassing-user-privacy-settings.aspx

These are my comments on that post.

They evoke the most broken standards of all time to base their accusations. The P3P. A standard that only Internet Explorer implements.

But my point here is not to beat the dead horse that P3P is, but to comment on Microsofts accusations.
By default, IE blocks third-party cookies unless the site presents a P3P Compact Policy Statement indicating how the site will use the cookie and that the site’s use does not include tracking the user. Google’s P3P policy causes Internet Explorer to accept Google’s cookies even though the policy does not state Google’s intent.

P3P is not a standard to block tracking. It's a standard to identify what you're tracking and for what purposes. It just blocks any 3rd party cookie from a domain that doesn't have a P3P CP and accepts everything for domains that have any string inside P3P CP. But tracking cookies are not just allowed by the P3P but the whole idea of P3P is to support tracking cookies.

Later they show the Microsofts own P3P settings, as if it was a good example of P3P usage:
By the way here's what Microsoft's P3P stands for:

P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"

What they don't explain in the post is what does that mean. So here I try to list what these letters stand for. They are indications of what information Microsoft tracks, for what purpose and who has access to this data.

  • ALL - All Identified Data: access is given to all identified data.

  • IND - Indefinitely: Information is retained for an indeterminate period of time. The absence of a retention policy would be reflected under this option. Where the recipient is a public fora, this is the appropriate retention policy.

  • DSP - there are some DISPUTES

  • COR - Errors or wrongful actions arising in connection with the privacy policy will be remedied by the service.

  • ADM - Web Site and System Administration: Information may be used for the technical support of the Web site and its computer system. This would include processing computer account information, information used in the course of securing and maintaining the site, and verification of Web site activity by the site or its agents.

  • CONo - Contacting Visitors for Marketing of Services or Products: Information may be used to contact the individual, through a communications channel other than voice telephone, for the promotion of a product or service. This includes notifying visitors about updates to the Web site. This does not include a direct reply to a question or comment or customer service for a single transaction -- in those cases, would be used. In addition, this does not include marketing via customized Web content or banner advertisements embedded in sites the user is visiting -- these cases would be covered by the , and , or and purposes.

  • CUR - Completion and Support of Activity For Which Data Was Provided: Information may be used by the service provider to complete the activity for which it was provided, whether a one-time activity such as returning the results from a Web search, forwarding an email message, or placing an order; or a recurring activity such as providing a subscription service, or allowing access to an online address book or electronic wallet.

  • IVAo - Individual Analysis: Information may be used to determine the habits, interests, or other characteristics of individuals and combine it with identified data for the purpose of research, analysis and reporting. For example, an online Web site for a physical store may wish to analyze how online shoppers make offline purchases.

  • IVDo - Individual Decision: Information may be used to determine the habits, interests, or other characteristics of individuals and combine it with identified data to make a decision that directly affects that individual. For example, an online store suggests items a visitor may wish to purchase based on items he has purchased during previous visits to the Web site.

  • PSA - Pseudonymous Analysis: Information may be used to create or build a record of a particular individual or computer that is tied to a pseudonymous identifier, without tying identified data (such as name, address, phone number, or email address) to the record. This profile will be used to determine the habits, interests, or other characteristics of individuals for purpose of research, analysis and reporting, but it will not be used to attempt to identify specific individuals. For example, a marketer may wish to understand the interests of visitors to different portions of a Web site.

  • PSD - Pseudonymous Decision: Information may be used to create or build a record of a particular individual or computer that is tied to a pseudonymous identifier, without tying identified data (such as name, address, phone number, or email address) to the record. This profile will be used to determine the habits, interests, or other characteristics of individuals to make a decision that directly affects that individual, but it will not be used to attempt to identify specific individuals. For example, a marketer may tailor or modify content displayed to the browser based on pages viewed during previous visits.

  • TAI - One-time Tailoring: Information may be used to tailor or modify content or design of the site where the information is used only for a single visit to the site and not used for any kind of future customization. For example, an online store might suggest other items a visitor may wish to purchase based on the items he has already placed in his shopping basket.

  • TELo - Contacting Visitors for Marketing of Services or Products Via Telephone: Information may be used to contact the individual via a voice telephone call for promotion of a product or service.

  • OUR - Ourselves and/or entities acting as our agents or entities for whom we are acting as an agent: An agent in this instance is defined as a third party that processes data only on behalf of the service provider for the completion of the stated purposes. (e.g., the service provider and its printing bureau which prints address labels and does nothing further with the information.)

  • SAMo - Legal entities following our practices: Legal entities who use the data on their own behalf under equable practices. (e.g., consider a service provider that grants the user access to collected personal information, and also provides it to a partner who uses it once but discards it. Since the recipient, who has otherwise similar practices, cannot grant the user access to information that it discarded, they are considered to have equable practices.)

  • CNT - Content : The words and expressions contained in the body of a communication -- such as the text of email, bulletin board postings, or chat room communications.

  • COM - Computer Information: Information about the computer system that the individual is using to access the network -- such as the IP number, domain name, browser type or operating system.

  • INT - Interactive Data: Data actively generated from or reflecting explicit interactions with a service provider through its site -- such as queries to a search engine, or logs of account activity.

  • NAV - Navigation and Click-stream Data: Data passively generated by browsing the Web site -- such as which pages are visited, and how long users stay on each page.

  • ONL - Online Contact Information: Information that allows an individual to be contacted or located on the Internet -- such as email. Often, this information is independent of the specific computer used to access the network. (See the category "Computer Information")

  • PHY - Physical Contact Information: Information that allows an individual to be contacted or located in the physical world -- such as telephone number or address.

  • PRE - Preference Data: Data about an individual's likes and dislikes -- such as favorite color or musical tastes.

  • PUR - Purchase Information: Information actively generated by the purchase of a product or service, including information about the method of payment.

  • UNI - Unique Identifiers: Non-financial identifiers, excluding government-issued identifiers, issued for purposes of consistently identifying or recognizing the individual. These include identifiers issued by a Web site or service.


They basically use every single options they have to tell you that they have the most possible freedom to use your data as P3P allows and that they track every single thing that P3P allows them to track.

So what's the difference of not providing a compliant P3P CP just for the sake of making it work on internet explorer and saying that you own all your user information?

Reference:


February 1, 2012

Serve static files locally with python

This is just a self reference and of course can't be used in production code. But if you're willing to test something static real quick and want to avoid file:// protocol you can setup a convenient webserver with python.

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.

January 12, 2012

The bugfix that could make the internet 5% faster

I've been working with Google Analytics for the last 3 years. When I started working with it it was already a very huge player on the market, but I've seen enormous growth on these  years. Google Analytics is the most used web analytics solution in the world. It's used on currently 44.67% of the top million websites on the internet. ga.js is the most popular javascript snippet in the history of the internet.

Google Analytics Usage on top websites:

[caption id="attachment_177" align="aligncenter" width="600" caption="source: builtwith.com"][/caption]

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.

July 12, 2011

Track social interactions as events for the google +1 button

Google Analytics released recently the _trackSocial  for Google Analytics. It was part of a bigger release on several Social applications including Google+. Sometimes things have to be pushed out before they're extensively tested, and a couple of bugs may come up.

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.

May 19, 2011

Cleaning up files with eval(base64 Malware

This blog was recently infected with a eval(base64 malware. This kind of malware use site vulnerabilities to inject a long list of link in the beginning of pages so it theoretically improves those site's SEO performance.

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'

July 30, 2010

Otimização de Landing Pages no Search Labs



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.

February 27, 2010

Google Analytics source override precedence

Google Analytics keeps track of 5 campaign variables all this information goes into _utmz cookie. This cookie has the following format:



_utmz=1.1267299040.3.4.utmcsr=Source|utmccn=Campaign|utmcmd=Media|utmcct=Content|utmctr=Term



There are basically 4 types of origins:



  • Campaigns: this means the user clicked on an AdWords link or a link with campaign variables.

    • You can customized all 5 Campaign Variables

    • If this is an AdWords visit the cookie is slightly different, it has the gclid number. GA will pull the correct value for the 5 variables from AdWords provided the accounts are linked.







  • Organic: When the user clicks on a link from a Search engine (e.g. google, bing, yahoo!, etc)

    • Source: google/bing/yahoo/etc

    • Campaign: (organic)

    • Media: organic

    • Term: Searched keyword







  • Referral: When a user clicks on a link from another site.

    • Source: www.referral-site.com

    • Campaign: (referral)

    • Media: referral

    • Content: /path/from/clicked/link







  • Direct: When Google can't determine a better origin it uses this one. Usually it means the user typed the address directly in the address bar. But it could mean the user bookmarked the link or still clicked this link in msn, or another desktop application.

    • Source: (direct)

    • Campaign: (direct)

    • Media: (none)





What happens if you change your source during a visit? What if it happens in a different visit?

It all depends, here are the basic rules for this precedence.

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.



Update 1:



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



Update 2:


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.



Update 3:


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.

February 23, 2010

Google Analytics _setAllowHash bug

GATC (Google Analytics Tracking Code) has an annoying bug with _setAllowHash.

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;

July 30, 2009

Event order in different browsers

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