3 ms·

_utm.gif is apparently requested 3 times with the same google analytics account id.

davidp 13y ago
In Chrome's F12 tools I see three _utm.gif requests from the article itself. According to http://utmgifparser.appspot.com/ http://utmgifparser.appspot.com/, the three requests appear identical except for the "X10 data" ('utme'); not sure of the significance of that w.r.t. GA reporting. Any GA experts care to enlighten?
true_religion 13y ago
_utm.gif is the generic way that Google Analatics communicates back with its servers---there's no rest API. So if you're doing things like event tracking, without counting the event as a page view, then you'll still see another request to _utm.gif They appear to have one normal _trackPageView call in the header, then one or more other calls coming from within minimized JavaScript files. Here's one: _gaq.push(["_trackEvent", e, t, n.toString(), parseInt(r, 10), !0]) This is the signature for _trackEvent _trackEvent(category, action, opt_label, opt_value, opt_noninteraction) !0 evaluates to true in javascript so this event is marked as non-interactive, and thus doesn't count as an extra page view and won't be used in bounce-rate calculations. Presuming the other calls are identical, then their reported bounce rate should be correct.
- integraton 13y ago
  Looking at the two additional requests, they do currently have the utmni parameter, marking them as non-interactive. However, the top comment references Google Analytics events on scroll that don't appear to be there now. One of FastCo.Labs folks also made the following comment: This made me curious as well. It turns out there was a technical change made at around the same time that is going to account for some of it. We're running an experiment now and will update with results. I don't see the update from him. Given all of this, I would guess that they were triggering events incorrectly and have since fixed it (the article is 3 months old).
  - irollboozers 13y ago
    That's extremely embarrassing.

In Chrome's F12 tools I see three _utm.gif requests from the article itself. According to http://utmgifparser.appspot.com/ http://utmgifparser.appspot.com/, the three requests appear identical except for the "X10 data" ('utme'); not sure of the significance of that w.r.t. GA reporting. Any GA experts care to enlighten?

true_religion 13y ago

_utm.gif is the generic way that Google Analatics communicates back with its servers---there's no rest API. So if you're doing things like event tracking, without counting the event as a page view, then you'll still see another request to _utm.gif They appear to have one normal _trackPageView call in the header, then one or more other calls coming from within minimized JavaScript files. Here's one: _gaq.push(["_trackEvent", e, t, n.toString(), parseInt(r, 10), !0]) This is the signature for _trackEvent _trackEvent(category, action, opt_label, opt_value, opt_noninteraction) !0 evaluates to true in javascript so this event is marked as non-interactive, and thus doesn't count as an extra page view and won't be used in bounce-rate calculations. Presuming the other calls are identical, then their reported bounce rate should be correct.

integraton 13y ago
Looking at the two additional requests, they do currently have the utmni parameter, marking them as non-interactive. However, the top comment references Google Analytics events on scroll that don't appear to be there now. One of FastCo.Labs folks also made the following comment: This made me curious as well. It turns out there was a technical change made at around the same time that is going to account for some of it. We're running an experiment now and will update with results. I don't see the update from him. Given all of this, I would guess that they were triggering events incorrectly and have since fixed it (the article is 3 months old).
- irollboozers 13y ago
  That's extremely embarrassing.