Google analytics download event - writing is broken

[hackartisan]

The javascript that sends an event to google to register looks for an id that no longer exists in the view code. It also looks for a data: label that is no longer there:

https://github.com/projecthydra-labs/hyrax/blob/master/app/assets/javascripts/hyrax/ga_events.js

These need to be added to the link_to hyrax.download_path of each file in https://github.com/projecthydra-labs/hyrax/tree/master/app/views/hyrax/file_sets/media_display

[awead]

We should use a css class instead of an id. The class can then be added to any or all links that need to be registered as a download.

[hackartisan]

@awead what other links are you thinking of?

[awead]

There are some download options related to the fileset. There have been recent discussions to do away with using GA to count downloads because if anyone uses Ghostery or other similar JS blockers, the stats won't get counted. A better way to solve this might be to just count hits to the controller and store them in the database. The table is already there, I believe. However, this work should be separate from this ticket. Just adding file_download to the views under media_display would suffice.

[hackartisan]

I don't think GA should be entirely circumvented; lots of people will want to integrate into their existing GA infrastructure. If you want to use the controller, we should write directly to GA from there, e.g. using staccato as OSU has done: https://github.com/osulp/Scholars-Archive/pull/310/files

But yes, this should be another issue.

[awead]

There's an analytics working group forming now. I'd wait and see what they report back with.

[mjgiarlo]

I'm hesitant to hang up @HackMasterA's bug fix by entangling it with a WG that hasn't been chartered yet.

[jrochkind]

In general, GA is not going to be 100% accurate. I think this is probably true of all analytics in one way or another, although it's true you can work around javascript disabling with server-side events.

Although if you're using HTTP caching via a CDN or otherwise, which seems especially likely for downloads, it's server-side events that no longer capture properly, while client-side JS is better.

In the past and working with others in the industry, I think people usually consider GA's "not exact, may may miss some" to be an education issue, rather than something that can be "fixed". There are diminishing returns trying to "capture everything with 100% reliability and report it exactly accurately", you'll never get there. It may just be a staff education issue -- analytics are inevitably not perfect, they are an estimate.

[awead]

@mjgiarlo I wasn't suggesting that. There's two separate issues here: 1) what to do now, and 2) what to do later. The WG should inform the latter issue. In terms of what to do now, I was only suggesting css classes as opposed to ids because there may be multiple download links in a page. But, I won't hold up this PR over that.

[awead]

@mjgiarlo I wasn't suggesting that. There's two separate issues here: 1) what to do now, and 2) what to do later. The WG should inform the latter issue. In terms of what to do now, I was only suggesting css classes as opposed to ids because there may be multiple download links in a page. But, I won't hold up this PR over that.

[mjgiarlo]

Ah, I misunderstood -- the tyranny of trying to catch up on all the things before 🍵. Thanks, @awead!