Use Matomo for visitor statistics on websites in a data protection compliant manner without consent

Matomo is a free available analysis software for websites. With Matomo many statistics can be created, which are also offered by Google Analytics. With the right configuration, Matomo can be used without consent and without problems with data protection.

Introduction

Matomo is a popular solution to be able to understand user behavior on websites. In contrast to Google Analytics, Matomo can be operated without data protection problems and without consent.

Despite this, often sufficient statistics about the behavior of website visitors can be created with Matomo. In particular, it can be determined with Matomo that

• How many users have visited the website on a specific day
• Which page (subpage) of the website was called how often
• From which devices the calls originated from
• From where approximately (geographical location) the calls took place.

Most website operators don't need to know more than that. Everything beyond that is usually only useful if sufficient resources and knowledge are available to evaluate visitor streams. Especially in smaller and medium-sized companies these resources are not available at all.

Matomo has a significantly lower setup effort due to the legal issues with Google Analytics. Since no cookie popup annoys the visitor, a higher conversion rate or lower bounce rate can be assumed. This in turn increases the scope of analysis data, which leads to more robust statistics.

In order for Matomo to be operated GDPR-compliant and without consent, a few aspects need to be taken into account. Before I go into the configuration of Matomo in more detail, examples of evaluations that Matomo supports should be shown.

Visitor statistics with Matomo

The screenshot shows the currently present visitors on a website and their actions. An action is something like calling up a subpage. Furthermore, characteristics of the visitors are displayed, such as the browser used, the operating system or the type of screen.

The following screenshot shows a graph of recent visits which falls very short due to the pure test switch.

From all visits, aggregated statistics are calculated such as for example the average stay duration or the number of actions per visit. An action is roughly a click on a link.

The path of visitors from arriving at the website, on the website, and how they left the website is shown in a clear way.

The transitions show how visitors came to the website, which pages they called up there and how they left the website again. The screenshot looks a bit meager here too because the test data was minimal. Normally internal pages would also be on the left and right sides and expand a graph.

Matomo Configuration

The configuration of the analysis tool is easily possible thanks to the graphical web interface. Some settings should be adjusted in order to be as data protection compliant as possible. It does no harm to look at all settings once. This requires only a few minutes of time.

Local Installation

Matomo should be used in local operation. This means that the installation files of Matomo are downloaded and then played on a own server. The installation is especially simple for WordPress, because there is a plugin available for this. This mode of operation is also called On-Premise and is free of charge.

If you want to use the cloud solution, you have to pay attention to a few things. Especially, an DPA (data protection agreement) must be concluded with the Matomo provider. The cloud solution currently costs 29 euros per month. The money is better invested in a one-time local installation, which is also easier to control legally.

IP Address Anonymization

For data protection reasons, IP addresses should not be fully logged because they represent personal data. The degree of pseudonymization or anonymization is flexibly selectable. A two-byte reduction in the IPv4 network address indicates a high level of data protection.

Using the anonymized IP address also for preparing visits is recommended as well (set the setting to "Yes", in the screenshot you can still see the opposite selection)!

If two or more bytes of the user's IP address are masked, then geolocation will be quite imprecise. Nevertheless, determining the user's location should still be precise enough for most use cases. For many, it is simply irrelevant whether the visitor lives in Hesse or North Rhine-Westphalia.

Enabling the option "Exchange user ID with pseudonym" causes internal identifiers for visitors to be replaced by a hash value. Because hash values can be ambiguous, this increases the level of data protection. In essence, it is about avoiding person-relatedness through additional logging using the visitor ID. Google Analytics fails here, because the Client Id as a counterpart to Matomo user ID is always fully logged and thus person-relatedness is possible.

Cookie loser operation

Legally, the use of Matomo without cookies is the safest option. The drawback is that repeat visitors cannot be reliably identified as such. Double counting may be the worst-case scenario. In my experience, this consequence is irrelevant for most small and medium-sized enterprises (SMEs). After all, it's mainly about answering questions like:

1. How many visitors did the website have?
2. What are the most popular contributions and which ones have potential?
3. What's the trend?

These questions can also be answered well enough with the mentioned vagueness.

Cookies can be disabled in the admin area of Matomo.

The E-Commerce Setting serves for tracking shopping carts or product views and is primarily relevant for online shops. Tracking search targets internal searches on the website, thus not global search engines. For the latter, other means are available at the level of known search engines.

Sitzungs-Cookies

The following was valid until before February 1, 2021: Possibly acceptable would be the use of Matomo with session cookies. Such cookies exist only as long as a user closes their browser again. According to § 15 Abs. 3 TMG, this could possibly be understood as "user-oriented design of telemedia", which would speak against consent. However, an opt-out option would then have to be provided. This could technically only be realized for most by not loading Matomo at all.

The BGH ruled in Planet49-judgment that the provision in the Telemedia Act is to be interpreted in conformity with ePrivacy Directive. Thus, consent would be required for technically unnecessary cookies.

Since December 1, 2021, the TTDSG has been in effect. Since May 2024, the TTDSG is now referred to as TDDG (nothing else has changed). The relevant section is § 25 TTDSG. According to this, cookies for analytical purposes are not exempt from consent. The Art. 29 Data Protection Group also noted this in their Opinion 04/2012 on the ePrivacy Directive, which was incorporated into German law by the TTDSG, explicitly.

I therefore recommend using Matomo without cookies. The data quality is good enough and possible question marks have disappeared.

What is device fingerprinting?

Fingerprinting means that the digital fingerprint of a user's device is drawn in order to be able to recognize the user again without cookies.

A fingerprint consists of screen resolution, set language, operating system, browser and its specific version as well as some other key data. These data are not stored in the user's device at present but are determined by querying attributes that are mostly linked to hardware. The screen resolution is however stored in a configuration which again is not accessible for the browser. The browser can only determine this information by querying the currently available circumstances and thus does not access persistent storage. In an earlier contribution I investigated which information is stored in a user's device.

How is screen resolution determined?

In Matomo, the screen resolution is stored in the parameter res.

By way of example, this screen resolution (width and height in pixels as well as color depth) is intended to demonstrate that these fingerprint information are not already stored on the user's device in such a manner as referred to in § 25 TTDSG or Art. 5 Abs. 3 ePrivacy-Richtlinie.

The screen information can be retrieved directly from the browser using JavaScript on the visited webpage. For this purpose, there is the screen-object (or more precisely: window.screen). It provides all mentioned screen attributes via the window-object. The query of the screen itself takes place through system-related functions at the level of the operating system. The operating system queries the current state of the active monitor in which the browser is displayed (as it looks with multi-displays, I have not explored this, probably the primary monitor is relevant). The monitor receives from the operating system when started, the command to use a certain resolution that has been configured once or corresponds to the system standard. The resolution actually displayed by the monitor can also deviate from what is set in the operating system if, for example, the desired resolution is not supported by the monitor. In the operating system, therefore, a desired resolution is configured, but in the monitor the resolution that has been commanded since it was turned on (or the next best one) is displayed. As far as I know, the monitor stores this resolution only in the volatile memory, not in a non-volatile storage.

How is the IP address determined?

Another example is intended to illustrate that certain data are not stored in accordance with the aforementioned legal provisions on the user's end device, but rather represent fleeting data which are held additionally outside of the user's end device or dynamically (e.g., depending on configuration) determined.

The IP address is a network address. Every participant in a network like the Internet needs an address to be reachable by others. A terminal device receives its address from a responsible network server assigned. Through DHCP (Dynamic Host Configuration Protocol) addresses can be dynamically distributed, in contrast to static addresses that persist forever.

The network address is assigned at runtime. It can theoretically change at any time, especially if you are a customer of one of the better-known telecommunications providers that offer favorable access. The address cannot be influenced by the browser, it can only determine the currently assigned address to the end device. It may happen that a copy of the IP address is stored in the end device. However, the actual IP address does not result from the information possibly stored in the end device, but through the provider. The possible storage in the end device is only to be understood as an aid for work and optimization of access. If there is a Fritz!Box present, it takes care of communication with the provider. The Fritz!Box is, as far as I know and can claim for my hardware, outside my end devices. This alone makes it plausible because several end devices can share a network access point like the Fritz!Box.

How is the type of screen determined?

This example demonstrates that information about the screen and input devices is not stored in or must not be stored in the end device. Whether a screen is a Touch Screen, i.e., can be operated by tapping with fingers or a special stylus, is determined by the screen model. This property of the screen cannot obviously be fixed by changing a configuration accordingly.

The characteristics of a computer mouse as an input device are derived from the capabilities of the mouse itself and not from a specific configuration. It can at most be that with several setting options one is fixed and managed by storage in the end device. This management then serves only comfort. The user should get the same configuration when the computer is restarted.

It's also important that the browser cannot manage the mentioned data itself, such as screen, mouse or IP address. This is different with cookies, which are managed solely by the browser and would not exist without this management. The storage of cookies in itself is necessary if they are to be used. The storage of screen resolution, on the other hand, is not necessary and may only occur to enable comfort for the user when restarting the device. Furthermore, a stored desired screen resolution does not necessarily imply the actual resolution. The browser also does not access a saved configuration to determine the current screen resolution (if JavaScript logic requires this), but asks for the current state of the screen.

What about installed plugins?

Due to a hint from Markus Baersch, I have investigated the Matomo source files of version 4.8.0. There, the MIME types supported by the browser are queried. To do this, the variable navigator.mimeTypes is read, which returns a list of MIME types. Through the attribute enabledPlugin, it can then be checked whether a plugin for the MIME type exists. This plugin query is not consent-free! Please check after installing Matomo whether the tracking request on your website contains parameters such as pdf, qt, realp, java or gears.

The Tracking Request calls the file matomo.php. You can find this request by pressing F12 in the Firefox Browser, then selecting the Network Analysis menu, then visiting the website and searching for the Matomo request.

I designate fingerprint data as Habit Data. They are indeed fleeting, so they can potentially change at any time, but usually do not. So they are neither technologies nor comparable technologies to cookies, but suitable for tracking users. What is decisive is the processing duration or storage duration of the fingerprint data.

The Article 29 Working Group considers virtual fingerprinting as access to the end device (Opinion 09/2014). However, I believe that the working group, which is a predecessor of the European Data Protection Board and mentioned in Art. 9 4 GDPR, means a comprehensive fingerprint. This includes installed fonts, i.e., data that cannot be obtained directly by reading JavaScript variables. Furthermore, for the Article 29 Group, explicit access to the IP address is particularly critical, which does not exist in Matomo in the presented variant. In addition, some data used (can) for fingerprinting are available immediately without being explicitly retrieved. This includes, for example, the User Agent, which is transmitted without any intervention from Matomo.

So it falls under Device Fingerprinting my assessment not under the ePrivacy Directive respectively § 15 Abs. 3 TMG in directive-compliant interpretation (cf. BGH judgment on Planet49) and also not under § 25 TTDSG (since December 2021). Whether fingerprinting falls under § 15 Abs. 3 TMG in its original form, depends on the type and duration of use of the fingerprint data.

Matomo uses a digital fingerprint to be able to recognize users even without cookies. My test showed that a user who was recognized as a repeat visitor on Friday due to underground actions, was valued as a new user on Monday. This is data protection lawfully good, because a short recognition period can be considered a legitimate interest. At least I see it that way and assume here that neither consent nor an opt-out option must be offered. This applies in the described case of local user analysis without cookies.

Fingerprinting with Matomo can therefore be used without contradiction possibility according to § 15 para. 3 TMG (in its original meaning, not in conformity with BGH according to ePrivacy Directive) at all. The legal basis here would then – in case of no explicit access to the end device – be the legitimate interest according to Article 6 para. 1 f DSGVO.

If you want to be sure, make sure that Browser Feature Detection is disabled. This can be done using a JavaScript command. In Matomo configuration, this should also be possible directly (without programming). The parameter is called "Disable Browser Feature Detection" in English and should also be findable in German. Whether the configuration is correct can be determined in the browser: Use F12 key in Firefox browser to open developer console. Call website with integrated Matomo. In the "Network analysis" tab in the developer console, search for data transfers related to Matomo. Check the parameters that are transmitted to these addresses. In the parameters, no information about installed browser plugins should appear and also not the size of the browser window (screen resolution is probably okay, see above).

Delete old data

For security reasons, historical data should not be stored for too long. A corresponding setting for automatically deleting old inventory data is offered by Matomo directly.

The number of days after which data expires should be chosen so that it is greater than the maximum reporting period required. If the report data are anonymized, a longer shelf life is also unproblematic.

If there are old data from previous sessions where the Matomo settings did not provide for anonymization, these can be anonymized afterwards.

Conclusion

Matomo is available for free and offers numerous analysis functions that are sufficient for most websites. A local installation is easily possible. Legal conditions like those at Google Analytics do not need to be observed. An DPA (I assume this means "AV-Verordnung", a German data protection regulation) is unnecessary with a local installation. Rather, attention must be paid to the correct configuration in order for privacy problems not to arise at all.

Matomo is suitable for almost all websites as a replacement for Google Analytics. This applies especially to those who use Google Analytics simply because everyone does or because an agency has prescribed it.

Whoever wants to use Google Analytics or another third-party tool should understand the legal and technical connections exactly. This can, however, be regularly doubted, thereby predestining data protection problems.

Also interesting

• Google Analytics processes all analysis data exclusively in the US
• Google Analytics as an entry point for hackers
• Use Google Analytics without cookies (but still with consent)
• Google Tag Manager: Legal Terms
• Google Tag Manager as Tag Manager Alternative
• Legal Terms of Google Services