“Unique visitors” shows how many different visitors Matomo recognised in a period. One person with a laptop and a phone are two visitors, two people at the same computer can be one. Whether the number is close to reality depends mostly on what Matomo uses to recognise a visitor.
How Matomo recognises a visitor
Matomo has three ways to recognise a visitor, in this order:
- The User ID. If someone logs in and the website passes on a User ID, Matomo uses it as the visitor ID. Then one person on laptop and phone is one visitor. The reports also show the metric “Users”.
- The visitor ID in the cookie. If Matomo may set cookies, the cookie
_pk_idholds a random ID for 13 months. When the same browser returns, Matomo recognises it, no matter how much time has passed. - A fingerprint without a cookie. Without the cookie, Matomo builds a hash from operating system, browser and version, browser plugins, IP address and language: the
config_id. It contains a value that changes every day. And by default Matomo only looks back 30 minutes with it.
The third way is kept short on purpose. Looking back further can be configured, but according to Matomo it costs a lot of processing time, because every visit may then check a large number of rows in the database.
Why the numbers don’t add up
Matomo counts unique visitors anew for each period. Someone who comes on Monday, Wednesday and Friday is a unique visitor on each of these days, but only one in the week:
| Period | Visits | Unique visitors |
|---|---|---|
| Monday | 120 | 100 |
| Wednesday | 130 | 110 |
| Friday | 110 | 95 |
| Sum of the three days | 360 | 305 |
| Week, only these three days | 360 | 210 |
The numbers are a made-up example. Visits can be added up, unique visitors never.
For years and date ranges, Matomo does not calculate unique visitors at all by default. On large instances that would be expensive. You can switch it on in the configuration with enable_processing_unique_visitors_year and enable_processing_unique_visitors_range. For past periods the reports then have to be processed again, which you should plan for if you have a lot of traffic.
What happens without cookies
If Matomo measures without cookies, only the fingerprint with its 30 minute window remains. According to Matomo, this has clear consequences:
- Almost all visitors are new. Visits without a cookie count as if new visitors arrived. Unique visitors are then close to the number of visits, returning visitors close to zero.
- Conversions go to the last visit. If someone comes through a newsletter, leaves and buys two hours later, the purchase counts for direct entry, not for the newsletter.
- Some reports become inaccurate. Days since last visit, visits by visit number, visits to conversion and days to conversion.
- Cohorts and attribution across several channels stay empty.
Even with cookies: the limits of recognition
In practice, a cookie rarely lasts 13 months. Several effects come together, and they distort recognition considerably:
- Safari and ITP. Safari’s tracking prevention deletes all cookies set by JavaScript if someone does not use the website for seven days. Only days on which Safari is used count. If someone arrives through a link with a click ID from a domain that Safari classifies as a tracker, these cookies last only 24 hours. Matomo sets its cookies with JavaScript and is fully affected. On iPhone and iPad this also applies to many other browsers, because there they are mostly built on WebKit.
- Cookies deleted on close. Firefox, Chrome and Edge offer to delete cookies when the browser closes, private windows always do. In companies, policies often clean the browser at every sign-out, and on terminal servers and virtual desktops the profile is sometimes created anew every time.
- Refused consent. With
requireCookieConsent, everyone who declines in the banner counts like a visit without a cookie. - Several devices and browsers. Laptop, phone and work computer are three visitors. Conversely, several people can share one computer.
- Cookies deleted by the user and blockers. Many people clear their browser regularly or use extensions that delete cookies. Ad and tracking blockers often prevent Matomo entirely, and these visits are then missing from all reports.
The errors point in one direction: Matomo counts too many new and too few returning visitors, and too many unique visitors over weeks and months. A single day is hardly affected, a month clearly is. How much your numbers are affected is shown by the browser and operating system reports: the higher the share of Safari and iOS, the less recognition carries.
With requireCookieConsent both mix: whoever consents is recognised with a cookie, everyone else is not. The share of returning visitors then also depends on how many people consent. If you change your consent banner, the numbers shift without any change in your visitors’ behaviour. Which cookies are involved is described under Matomo cookies.
Reading the number correctly
- Use visits for trends. They can be added up and hardly depend on cookies.
- Unique visitors only with a cookie or User ID. Only then do they say something about people, and even then only per browser or per logged-in account.
- Compare periods measured the same way. Don’t compare months between which the consent banner, cookie setting or tracking changed.
- Don’t compare one to one with Google Analytics. The two tools count visitors differently, and consent affects them differently.
- Look at new and returning visits separately. The Frequency Overview shows how much of your number rests on recognition.
Sources
As of 10 November 2026
- Matomo: How does Matomo detect unique and returning visitors?
- Matomo: When cookies are disabled, how does it impact Matomo reports accuracy?
- Matomo: How do I improve the detection accuracy of unique visitors and returning visitors?
- WebKit: Tracking Prevention in WebKit (ITP, 7 days and 24 hours for cookies set by JavaScript)
- Matomo on GitHub: default configuration with unique visitors per period
- Matomo on GitHub: fingerprint without a cookie (config_id)