Add google analytics or similar logging for static OBO website, and anciliary static websites

[cmungall]

No description provided.

[alanruttenberg]

I'm not keen on doing so, because of tracking and privacy issues. Or make it opt-in on an ontology by ontology.

[cmungall]

Any update on thinking on this post-GDPR? E.g https://support.google.com/analytics/answer/9019185?hl=en

[kltm]

What is it that people want information on? If one wants to see how people move through pages, something like GA or Matomo is needed. If one wants to see downloads and ontology usage, plain ol' server logs are what one wants.

[wdduncan]

We operate on an "open" principle. Does this affect this principle? If so how?

[cmungall]

Good Q. We have separate tickets/stacks for ontology usage. Here the driving questions for me are more: - how useful are our per-ontology metadata pages - how useful is the front page / summary table? Do people frequently traverse from here to the per-ontology pages? - ditto for documentation such as docs on principles Having a complete picture is good but using simple easy to maintain well-understood components is probably more important. I had assume GA would be sufficient

…

On Mon, Apr 13, 2020 at 11:37 AM kltm ***@***.***> wrote: What is it that people want information on? If one wants to see how people move through pages, something like GA or Matomo is needed. If one wants to see downloads and ontology usage, plain ol' server logs are what one wants. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOL4PG4FA4ST22BZQODRMNLWXANCNFSM4BQVGE2Q> .

[cmungall]

Copying @alanruttenberg's helpful response from email:

3 recent articles on alternatives

https://mscholz.dev/post/logging/

https://plausible.io/ - pay service, cost depends on traffic. Anyone know our current level of traffic?

https://medium.com/better-marketing/why-i-switched-from-google-analytics-to-fathom-287017424069 also pay but maybe their lite version would work for us: https://github.com/usefathom/fathom/blob/master/README.md

Other suggestions from various posts - I looked at HN search results for google analytics alternative within the last year.

https://goaccess.io/
https://count.ly/ (there is a self-hosted version)
https://simpleanalytics.com/?ref=iceland-blog (service, cost depends on traffic)
https://matomo.org/matomo-on-premise/ (can be self hosted)
https://github.com/frequencyanalytics/frequency (self hosted, open source)
https://github.com/parkr/ping (there's a docker image)

I haven't assessed these yet - in part because I don't know the details of our current setup. However, I'd be open to a call in which a few of us walk through these and try to narrow down to a plausible 1 or 2.

For the pay services there's always the option of contacting them and asking if they can give us a break for being a good cause. Not worth doing, though, unless we particularly like one of them.

[cmungall]

To answer @kltm's question. This is not about analyzing the logs for PURL accesses. We have this ticket on the purl repo for that: OBOFoundry/purl.obolibrary.org#63 (there is an analogous conversation about privacy from 2015 there too...)

This ticket is about the obofoundry.org repo, which is hosted from this repo via jekyll/GH pages. We want to have a handle on how many people view the mega ontology table, how many people look at the individual ontology metadata pages, how many people look at the principles.

Given the site is hosted in GH pages, we may be limited in options, as we are not committing to hosting the site ourselves at this time. Presumably GH keeps logs of visitors. I do not know if they provide tools for analyzing these. If not, then presumably the only option is client-side js such as is used for GA

This SO question is about how to do GA in GH pages:
https://stackoverflow.com/questions/43880617/log-visitors-on-github-page

[kltm]

@cmungall Another approach might be to just deploy the site to S3 and get access to the bucket logs (which are easily turned on in AWS)--we do this a couple of places elsewhere and it works pretty well. As you already deploy with jekyll statically, you'd only have to add a bit to push it out instead of GH for that.

Also noting that we use goaccess.io for GO (quite a nice log analyzer) and have some experience with Matomo (previously Piwik), a nice GA alternative but you have a little more overhead with the hosting.

[jamesaoverton]

The idea of moving to S3 has also come up in the context of the Dashboard. I think it's worth serious consideration. Although running our own build would be one more moving part, I see several benefits:

• simplify the system, e.g. by avoiding the (brilliant) _config.yml hack
• one-step builds ensure registry/ files are always up to date
• fully integrate the dashboard
• simpler, unified logging solution
• maybe eventually migrate to Python (we don't use Ruby anywhere else)

Using GitHub Pages was a really great solution, but I think we're growing past it.

[alanruttenberg]

+1 on S3

…

On Wed, Apr 29, 2020 at 2:25 PM James A. Overton ***@***.***> wrote: The idea of moving to S3 has also come up in the context of the Dashboard. I think it's worth serious consideration. Although running our own build would be one more moving part, I see several benefits: - simplify the system, e.g. by avoiding the (brilliant) _config.yml hack - one-step builds ensure registry/ files are always up to date - fully integrate the dashboard - simpler, unified logging solution - maybe eventually migrate to Python (we don't use Ruby anywhere else) Using GitHub Pages was a really great solution, but I think we're growing past it. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB3CDR3CBNJ2PYZ3M2OOSDRPBWK7ANCNFSM4BQVGE2Q> .

[nlharris]

see also #46

[cmungall]

I am currently using a GA tag from a different project (linkml) in RO at the moment:

https://github.com/oborel/obo-relations/blob/master/mkdocs.yml

This is suboptimal

[jamesaoverton]

My preference would be not to use Google Analytics, but right now I don't have the time or resources to provide a good alternative.

[alanruttenberg]

There was another thread on this, where I also noted my preference that we not use google, and offered a number alternatives. But of course any of them will take some work. I can offer grunt labor if someone else makes decisions and points me at a task that would help. Alan

…

On Tue, Jan 11, 2022 at 1:10 PM James A. Overton ***@***.***> wrote: My preference would be not to use Google Analytics, but right now I don't have the time or resources to provide a good alternative. — Reply to this email directly, view it on GitHub <#126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB3CDWRQBYPPSGD7O7EQG3UVRXABANCNFSM4BQVGE2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[kltm]

Now that there is no proxy server running and we are directly on GH pages, all the logging solutions are off the table.
GA replacements are like https://plausible.io/ and https://matomo.org/, but either require payment to use their cloud version or additional setup and servers to run on one's own.
A good decision point would be understanding additional resources that could be applied. If the answer is "0", GA is likely the way yo go. If the answer is "a bunch of money", alternate providers could be easily considered and used in their cloud form. If the answer is "time and money", the field is wide open.

[alanruttenberg]

There is a third possibility which is not to use analytics if the seeming only choice is GA. That is what I am suggesting is preferable if an alternative is not possible (which seems unlikely). In any case, there are arguments that GA is no longer very representative, since ad blockers are so prevalent. Alan

…

On Tue, Jan 11, 2022 at 4:39 PM kltm ***@***.***> wrote: Now that there is no proxy server running and we are directly on GH pages, all the logging solutions are off the table. GA replacements are like https://plausible.io/ and https://matomo.org/, but either require payment to use their cloud version or additional setup and servers to run on one's own. A good decision point would be understanding additional resources that could be applied. If the answer is "0", GA is likely the way yo go. If the answer is "a bunch of money", alternate providers could be easily considered and used in their cloud form. If the answer is "time and money", the field is wide open. — Reply to this email directly, view it on GitHub <#126 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAB3CDX7YBD6OSRC6VZUUTTUVSPRZANCNFSM4BQVGE2Q> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: ***@***.***>

[kltm]

From above (like #126 (comment) and #126 (comment)), if only ontology download information is desired and users are transiting the PURLS, this information could be mined from non-JS/non-browser sources, like purl server logging.

[cmungall]

I updated the title to make it clear that this is just about the static pages on https://obofoundry.org/

We have tickets in the purl tracker about logging class and ontology PURL accesses (which may be the more meaningful statistic)

@alanruttenberg

There was another thread on this, where I also noted my preference that we
not use google, and offered a number alternatives.

You did indeed, in an email thread I believe, this was very helpful, I copied your suggestion to a comment in this issue (#126 (comment)), @kltm also provided some above. But my understanding is that this would either require coordinating payments or switching to a different infrastructure (we use gh pages for static hosting)

I can offer grunt labor if someone else makes decisions and points me at a task that would help.

Most welcome, but it's not clear to me what that labor would be.

My understanding of this thread is that for our current static site, the options are GA or no logging. We lack consensus on using GA, so I'm happy to close this, and reopen if we ever switch our infrastructure.

I think static sites for anciliary projects, whether ontology (COB, RO) or tools (ROBOT, ODK) should be influenced the OBO central decision, but it seems that say if we want to use GA for the RO static sites then we wouldn't use an OBO-wide GA token as such a thing will never exist, and mint a new one.