Analytics

🇩🇰 Dansk | 🇬🇧 English

Previous: Upload results

---

Will anyone use it?

It would be nice to know ahead of time if all this extra effort you're putting in will even be relevant at all. However, assuming your competition has participants that aren't me, I cannot promise that a meaningful number of people will check your division results online. What I can tell you is that people did use it at the system's debut.

Horsens OK's event in Barrit in September of 2023, which hosted the second and third divisions from the northern region, featured around 340 participants. On the day of the event, visits to the competition page reached just shy of 400, with the total exceeding 500 by the end of the following day. These are not necessarily unique visitors, but it goes to show that people did in fact make use of the offer - and, in my opinion, easily enough people to make the effort worthwhile.

Analytics

First a sort of disclaimer about personal data, since analysis data from online services can be a lot of things these days...

Personal data

The names, clubs and competition classes of participants, which are all staples of orienteering result publishing, are of course included when the client collects results, and they are stored on the server, embedded in one result file per division. The client only processes the files to prepare them for presentation, and outside of HTML sanitation for security purposes, the server does not analyse the contents of the result files, merely presenting them as a whole. Being a web server, it unsurprisingly handles HTTP requests, which can also contain some degree of identification. Specifically, data such as user agents and IP addresses are typically logged by web servers. While the division-result-server itself doesn't log these, any servers between it and the user, including proxy servers, usually do.

Beyond this, no personal data, sensitive or otherwise, is collected or stored by the client or server. User tracking is limited to a simple visit counter, which makes no identification attempts. This means no tracking of browsing histories, demographics, interests, device specifications or login statuses, to name examples of commonly-collected user data. Additionally, the server uses no cookies at all.

Data for you

Right then... User tracking is out, but what about those page visits? Those are accessed via a simple API, which the client handles with a press of the Fetch Analytics button in the Online pane. The following fields are included in the response:

Field	Details
competitionId	The ID of the competition that the analytics data belongs to
updatedAt	The timestamp of the last change to the analytics data
visits	The number of non-unique visits to the competition page. Increments by one for every page load, including reloads, but excluding automatic result updates. Visits are not incremented on competitions with the visibility set to PRIVATE
metadataUpdates	The number of explicit metadata updates. Increments by one for every successful use of the Update Metadata button. Result updates cause implicit metadata updates, which are not included here
resultUpdates	The number of result updates. Increments by one whenever results are uploaded to the competition
visitsMilestones	A list containing pairs of visits and timestamp, indicating when the given number of visits was reached

Again, visits is a measure of page loads, not people. Though likely to correlate, they are unlikely to be the same. Still, visits and visitsMilestones can be interesting ways to gauge the usage of the service at your event.

If you just want to have a quick look, the log output will usually be sufficient. However, the analytics data, which is delivered in a nice JSON-wrapping, can be accessed programmatically as well (obviously, since the client can do it). It is available at the /api/fetch/analytics/[comp_id] endpoint, where [comp_id] is replaced with the competition ID. For now, this is of limited interest, but it may become more relevant if more data points are added in the future.