cvat Documentation: Add Google Analytics tag and cookie consent banner

Motivation and context

We would like to gather user statistics for the documentation website. This PR add Google Analytics script and a cookie banner to comply with GDPR requirements. This PR is a proposal to discuss.

How it should work in general:

When a user comes to the documentation website for the first time, we must display a cookie banner with options to accept and reject the analytics cookie.
While the banner is present (user yet to make their choice), we must not inject the tracking script on the page.
If user accepts tracking, we can proceed to add the script for analytics for all documentation pages for this user. The next time, the same user comes to the website we recognize them via cookie (if they did not use incognito mode) and we don't display the banner.
If user rejects cookie, we don't add analytics script. When such a user returns, we treat them as a newcomer, and we display the banner again.

Some notes about the solution, potential topics for discussion, and doubts:

Hugo allows adding Google analytics via configuration file (see Hugo docs), but this leads to the script being injected on the website build. This way when a user comes to the website for the first time, the script is already on the page. This is not correct. So, the solution is to have a separate template with all code related to GA tag and the banner. It allows to control the script injection basing on the user choice about cookies.
Following the previous: the GA tag is hard coded in the template. It may be not good for the code maintenance.
The template with cookie banner is called through the footer template assuming we have footer on every documentation page. Subject for discussion.
All CSS are subjects for discussions.
To avoid analytics pollution when running the website locally, the cookie banner includes a check for the current environment (looking for localhost, 127.0.0.1, 0.0.0.0, 192.168.*.*, 10.*.*.* in the host name). In order to test this PR locally, we should comment the corresponding logic (it's OK to have some site statistics gathered as the testing side-effect result). I could not think other way around this situation.
The solution does not provide a way to reset the cookies via website interface. I assume users can do it through the browser tools if necessary.
The solution shows banner for all website visitors regardless of their location. I don't think we should differentiate them, but it's also a subject for discussion.

How has this been tested?

Here is my plan for testing:

Temporarily comment out the isLocalDevelopment() calls in both injectGAScript() and acceptCookies() functions
Run and open the website locally
Open the page source
Search for googletagmanager.com: it should not be the part of a script element
Select Accept and search for googletagmanager.com again: it should be present in the script element. Check Networks for requests to google-analytics.com. It should include POST requests
Reset cookies for the website
Repeat step 4
Select Reject and and search for googletagmanager.com again: it should not be the part of a script element. Check Networks for requests to google-analytics.com: there should not be any

I could not find a way to test it for production with uncommented code for isLocalDevelopment() calls in both injectGAScript() and acceptCookies() functions.

Checklist

[x] I submit my changes into the develop branch
[ ] I have created a changelog fragment
[ ] I have updated the documentation accordingly
[ ] I have added tests to cover my changes
[ ] I have linked related issues (see GitHub docs)

License

[ ] I submit my code changes under the same MIT License that covers the project. Feel free to contact the maintainers if that's a concern.

May 06 '25 06:05 paveltovchigrechko

Following the previous: the GA tag is hard coded in the template. It may be not good for the code maintenance.

To avoid analytics pollution when running the website locally, [...]

It seems to me that there's a simple way to solve both of these problems:

Use os.Getenv to get the tag from an environment variable instead of hardcoding it in the source.
If the environment variable is empty, skip all the cookie-related code.
Define the environment variable in the GitHub workflow.
For development, set the variable to a fake tag value.

Jun 12 '25 14:06 SpecLad

The solution does not provide a way to reset the cookies via website interface. I assume users can do it through the browser tools if necessary.

I'm fairly sure that users have to be able to change their cookie preferences without going through the browser tools. And it seems doable - you could add a link to the footer that shows the dialog again.

Jun 12 '25 14:06 SpecLad

It seems to me that there's a simple way to solve both of these problems:

Use os.Getenv to get the tag from an environment variable instead of hardcoding it in the source. If the environment variable is empty, skip all the cookie-related code. Define the environment variable in the GitHub workflow. For development, set the variable to a fake tag value.

So, here is my updated solution:

GitHub Workflow (docs.yml): Sets GA_TRACKING_ID=G-GVSBK1DNK5 environment variable
Hugo Config (config.toml): Provides ga_tracking_id parameter for the tag default value (empty line)
Cookie Consent HTML (line 4): Only shows banner if both production mode AND GA tracking ID are configured

I'm fairly sure that users have to be able to change their cookie preferences without going through the browser tools. And it seems doable - you could add a link to the footer that shows the dialog again.

Added a footer link ("Cookie settings") that invokes the banner and allows changing user preferences regarding cookie usage.

Jun 16 '25 11:06 paveltovchigrechko