4 ms·

I'm not convinced the defined track function is fixing what's described. If following Google's instruction for "installing" ga.js [0], there shouldn't be any si

I'm not convinced the defined track function is fixing what's described. If following Google's instruction for "installing" ga.js [0], there shouldn't be any sites breaking that block ga.js from loading. That is, Google suggests var _gaq = _gaq || []; at the start of the script installation. If ga.js never loads, _gaq is still an array and can be pushed onto to your heart's content. If you're concerned with an ever growing array of garbage, the suggestion in the comments is great: __gaq = __gaq || {push: function(){return 0}} [0] https://developers.google.com/analytics/devguides/collection/gajs/asyncTracking https://developers.google.com/analytics/devguides/collection...

jeresig 14y ago
If that's the case then there are a lot of sites that are willfully ignoring the correct snippet. Perhaps this was something new that they added recently - or perhaps there's a frequently-incorrect snippet that's copied?
- thezilch 14y ago
  Honestly, it could be either. Though, I can't recall anything different after the move off urchin.js -- years ago [0]. What's worse is those that call "private" methods directly; for example, some use _gaq._link(...) over _gaq.push(["_link", ...]), which unravels a mess really quickly if you want to provide surrogates for all the methods exposed by _gaq [1]. [0] 2010, Dec 09 11:12:41 -0800 commit on a site that would be most likely "with the times" [1] https://developers.google.com/analytics/devguides/collection/gajs/methods/ https://developers.google.com/analytics/devguides/collection...
- yahelc 14y ago
  No, it's not particular new or regularly misimplemented. It's usually implementing cross-domain tracking that breaks things, not regular use of GA, because it does `return false` in an onclick handler. I have some fixes for that here: https://github.com/yahelc/GA-Better-Crossdomain-Tracking https://github.com/yahelc/GA-Better-Crossdomain-Tracking
  - jeresig 14y ago
    The issue you outline is tangential (but still important). The issues I'm seeing are actual exceptions occurring where sites are missing the reference to the GA object, not issues with _link tracking and redirects.
    - yahelc 14y ago
      Can you provide live examples? `_gaq.push([]);` shouldn't result in any errors with Ghostery. I'm curious as to what's happening.

jeresig 14y ago

If that's the case then there are a lot of sites that are willfully ignoring the correct snippet. Perhaps this was something new that they added recently - or perhaps there's a frequently-incorrect snippet that's copied?

thezilch 14y ago
Honestly, it could be either. Though, I can't recall anything different after the move off urchin.js -- years ago [0]. What's worse is those that call "private" methods directly; for example, some use _gaq._link(...) over _gaq.push(["_link", ...]), which unravels a mess really quickly if you want to provide surrogates for all the methods exposed by _gaq [1]. [0] 2010, Dec 09 11:12:41 -0800 commit on a site that would be most likely "with the times" [1] https://developers.google.com/analytics/devguides/collection/gajs/methods/ https://developers.google.com/analytics/devguides/collection...
yahelc 14y ago
No, it's not particular new or regularly misimplemented. It's usually implementing cross-domain tracking that breaks things, not regular use of GA, because it does `return false` in an onclick handler. I have some fixes for that here: https://github.com/yahelc/GA-Better-Crossdomain-Tracking https://github.com/yahelc/GA-Better-Crossdomain-Tracking
- jeresig 14y ago
  The issue you outline is tangential (but still important). The issues I'm seeing are actual exceptions occurring where sites are missing the reference to the GA object, not issues with _link tracking and redirects.
  - yahelc 14y ago
    Can you provide live examples? `_gaq.push([]);` shouldn't result in any errors with Ghostery. I'm curious as to what's happening.