Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This Is What Happens When Publishers Invest In Long Stories

fastcolabs.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: This Is What Happens When Publishers Invest In Long Stories

#31

Post by integraton »

true_religion wrote: post #27
regal wrote: post #17

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-insert…

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

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

Re: This Is What Happens When Publishers Invest In Long Stories

#32

Post by davidp »

integraton wrote: post #31
true_religion wrote: post #27

Earlier quoted context omitted.

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

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

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?

Re: This Is What Happens When Publishers Invest In Long Stories

#33

Post by waterlooalex »

regal wrote: post #17

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-insert…

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

Re: This Is What Happens When Publishers Invest In Long Stories

#34

Post by eli »

marquis wrote: post #4

Since I became wedded to my Kindle for consuming journalism thanks to the superb sites such as http://longreads.org and http://longform.org * my reading time has exploded, plus I pay for services where possible as I am in need of their curation. Since using these sites I feel better informed about the world and I have a deep, deep respect for longform journalists. I'd love to see this stub idea extend to the Kindle b…

Yup, I feel the same way. With Instapaper and my Kindle I'm spending a lot more time reading articles.

If you're interested, I recently started curating my picks here: http://esd.io/worthreading/ Some I got from longform/longreads, others I "discovered" on my own.

Re: This Is What Happens When Publishers Invest In Long Stories

#35

Post by petenixey »

I love it that these guys are experimenting with content and analytics but the stats look contradictory.

Bounce rate is 1- n_visits_with_more_than_one event/n_visits.

The default GA setup doesn't register any events except page views so "more than one event" means more than one page view.

However the charts in this article showed that while the bounce rate fell, the average pages per visit stayed constant. For bounce rate to drop you'd expect pages per visit to rise... unless there's also a new event being fired.

My guess (as suggested by some commenters here before me) is that they shipped some type of event which fires for a fraction of visitors - scrolling a certain distance down the page perhaps.

If this event fires, the visit won't (by default) count as a bounce. it will also effect time-on-site. Time on site is normally zero unless you visit another page or fire an event. In this case it's determined by the time of the last page view or event that google registers. If they did ship an "on 400px scroll" event (for instance) then for each visitor for whom the event fires for, the "time on site" will be registered as the time of the event.

For my money, I think that bounce rates for content-driven sites should actually be set by a threshold time-on-site. Most visitors don't read more than one page so it's a very weak indicator of a "bounce". Someone could read for 10 minutes and still count as a bounce which isn't a fair appraisal of a very successful article. The raw "bounce metric" makes sense for a transactional site where onepage view == no Revenue but makes little sense for a site where one ten minute read of an article is exactly what the author hopes for.

Re: This Is What Happens When Publishers Invest In Long Stories

#36

Post by coolsunglasses »

petenixey wrote: post #35

I love it that these guys are experimenting with content and analytics but the stats look contradictory. Bounce rate is 1- n_visits_with_more_than_one event/n_visits. The default GA setup doesn't register any events except page views so "more than one event" means more than one page view. However the charts in this article showed that while the bounce rate fell, the average pages per visit stayed constant. For bounce…

A content site wants them to explore and traverse the rest of the site.

An article that gets read is a success for the article, not for the publisher.

Re: This Is What Happens When Publishers Invest In Long Stories

#37

Post by true_religion »

integraton wrote: post #31
true_religion wrote: post #27

Earlier quoted context omitted.

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

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

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

Re: This Is What Happens When Publishers Invest In Long Stories

#38

Post by integraton »

true_religion wrote: post #37
integraton wrote: post #31

Earlier quoted context omitted.

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

_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(["_track…

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

Re: This Is What Happens When Publishers Invest In Long Stories

#39

Post by irollboozers »

integraton wrote: post #38
true_religion wrote: post #37

Earlier quoted context omitted.

_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(["_track…

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…

That's extremely embarrassing.
Post reply on HN