[regal]

The site appears to have Google Analytics placed multiple times into its source code. This messes up tracking and artificially dramatically drops bounce rates.

In my experience working with content sites, the real bounce rate reduction you see in moving from shorter articles to longer ones is closer to 5% or so - from, say, 77% to 72%. Still dramatic, but not nearly as dramatic as the drop you'll get by double-inserting GA code.

[stephengillie]

I bet their automated system is re-inserting GA code every time it updates their stub. It probably copies the entire previous stub, GA code and all, then publishes that plus updates and fresh GA code.

From the article:

Stub stories work like this: You write the first installment like any other story. But when more news breaks, you go back to the article, insert an update at the top, and change the headline and subheadline to reflect the update. Our system updates the story "slug" when the headline changes--check the URL of this story, and you'll see words from the headline in the URL: /this-is-what-happens-when-publishers-invest-in-long-stories. But the number preceding the slug--on this article, it's 3009577--is a unique node ID which never changes. So essentially, every time we update an article, we get a fresh URL with a fresh headline, but pointing back to the same (newly updated) article.

We can check this by checking older stubs.

Edit: on checking the page source, I only see GA in there 2x - once to call a GA API from google-analytics.com, and once more to (I think) load ga.js from google-analytics.com. How many times do you see that page calling GA?

[true_religion]

I'm not seeing multiple inserts per page, and I checked their 'stub' pages as well. They only have GA in the head.

[integraton]

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

[davidp]

In Chrome's F12 tools I see three _utm.gif requests from the article itself. According to 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]

_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]

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]

That's extremely embarrassing.

[picardo]

Are you saying that as a hypothesis? Is there a link you can point us to where the code is inserted multiple times?

[waterlooalex]

Agreed. Title should be "If it seems too good to be true (Jaw dropping improvement in bounce rate) then it probably is."