Set up metrics tracking and track download events #1054
Conversation
thatbudakguy
force-pushed
the
download-tracking
branch
from
1e0dda7
to
f1786dc
Compare
| cookies[:ahoy_visitor] | ||
| end | ||
|
|
||
| # Sessions last for 1 hour (default used by Zenodo) |
There was a problem hiding this comment.
can you explain why zenodo is relevant?
There was a problem hiding this comment.
Zenodo tracks view/download metrics and displays them prominently on each item deposited in the repository. It's been basically the main example of a metrics implementation for a repository that we've used since the planning phase of the workcycle.
| } | ||
| end | ||
|
|
||
| # Visitors are remembered for 2 years (Ahoy's default) |
There was a problem hiding this comment.
why are we copying ahoy's defaults? Are we attempting to make this code mimic ahoy?
There was a problem hiding this comment.
It's an arbitrary choice – I asked Amy if she wanted to choose a different value and she was OK with this one.
|
|
||
| private | ||
|
|
||
| # We're responsible for ensuring that every event is tied to a visit |
There was a problem hiding this comment.
Why? Can you expand on this?
There was a problem hiding this comment.
Without this, we aren't able to group events by session. The current specification for the metrics feature is that we want to show "unique" metrics in the same way that Zenodo does – i.e. grouping events by session, so that viewing something repeatedly in a short timeframe gets collapsed into one view. The Visit is the thing we group by to do this.
Visits also host all of the information about the user and their browser. Our requirements don't currently call for using this information, but it seems prudent to collect at least basic information in the event that we later want to examine trends.
There was a problem hiding this comment.
To answer the functional side of the "why" question, if you're using ahoy.js, it takes care of visit creation for you. Likewise if you're using the ahoy gem, there's an option to create visits automatically.
Unfortunately, in this situation we aren't doing either one: we need to send events to ahoy's HTTP API (not a local database, like the gem), but we can't send them from the client side. That's also why there are some pieces of ahoy copied here: it's a hybrid of both libraries, but in ruby.
| @@ -138,6 +138,22 @@ | |||
| entries = ZipTricks::FileReader.new.read_zip_structure(io: StringIO.new(response.body)) | |||
| expect(entries.length).to eq 6 | |||
| end | |||
|
|
|||
| context 'when metrics tracking is enabled' do | |||
There was a problem hiding this comment.
it would be great if this could be made a request spec instead. Controller specs are deprecated
There was a problem hiding this comment.
Sure, but is this PR the right place? I just needed to add a single test for the new feature.
thatbudakguy
force-pushed
the
download-tracking
branch
from
f1786dc
to
941f904
Compare
|
This works as intended in stacks, but it turns out that Ahoy doesn't want to accept requests made from the server to its API – see comments on #1048. |
Closes #1048