Simply put, this collection is the "rawest" and most complete record of what has happened on your website at the traffic level. It doesn't group information by session or summarize the behavior of a complete visit, but rather stores each access separately for more detailed analysis.

This makes it a particularly useful collection when you want to answer questions like:

• what URLs or resources are actually being requested,
• from which IP the requests are coming,
• which pages or resources are returning errors,
• whether there are bots or automated traffic,
• whether a marketing campaign has generated accesses,
• or whether someone is trying to access suspicious routes.

For example, this collection allows you to:

• Understand what traffic the website receives: You can see which pages, resources, or routes are being requested most frequently. This helps understand which parts of the website receive more activity.
• Detect errors: If a request returns an error code, such as a 404 or 500, this collection records it. That allows you to locate pages that don't exist, broken links, or internal server problems.
• Identify suspicious traffic: Often, accesses don't come from people browsing normally, but from bots, scanners, or automated tools. With this collection, you can detect if someone is testing strange routes, repeating requests massively, or using automated agents.
• Analyze traffic origin: You can see which country a request comes from, which IP made it, or whether it comes from another website through the referer field.
• Review marketing campaigns: If the access came with UTM or MTM parameters, this collection also records them. That allows you to know if a request is associated with a specific campaign, newsletter, ad, or particular traffic source.
• Audit access to sensitive resources: It is useful for reviewing attempts to access files or routes that shouldn't be exposed, such as internal pages, old scripts, forms, or test endpoints.

• one row = one individual access,
• a URL = the resource someone tried to open,
• an IP = where the request came from,
• a status code = what happened with that request,
• a date = when it occurred,
• a user agent = what type of client made the request.

If you want an overview of user behavior, it is usually easier to work with a collection like Visits.
If you want to go into detail and see exactly what happened on the server, the appropriate collection is Web Accesses.

Data type: numeric

This field indicates a risk score associated with the IP that made the request. Its purpose is to help detect whether the access might come from a suspicious source. In simple terms, the higher this value, the more likely that IP is related to unwanted activity, such as bots, scans, or malicious behavior.

It doesn't automatically mean an IP is dangerous, but it does serve as an indicator to pay more attention.

Example usage:

• if you see many requests from an IP with a high abuse_score,
• and they also access non-existent or unusual routes,
• you are probably dealing with automated or suspicious traffic.

This is the exact date when the request was recorded. It allows you to place each access in time. Thanks to it, you can filter by date ranges, detect peak activity moments, or analyze when an error or traffic spike occurred.

Indicates the domain or subdomain that received the request. It serves to distinguish which part of your web infrastructure that request was directed to. This is especially useful if you manage multiple domains or subdomains and want to separate the activity of each one.

Example usage:
you can see if an access went to the main domain, an administrative subdomain, an internal zone, or a specific environment.

Data type: categorical text

Shows the HTTP protocol version used in the request, for example HTTP/1.1 or HTTP/2.0. For a non-technical person, this field is not usually a priority in normal analysis, but it can have value when you want to review technical compatibility or specific patterns of certain clients.

Data type: categorical text

This is the IP address from which the request was made. This field is key for access analysis because it allows you to know from which technical origin a request came. It doesn't directly identify a person, but it does identify the connection or point from which the access was made.

Example usage:

• detect many repeated requests from the same IP,
• group errors by origin,
• review suspicious accesses,
• or identify automated activity.

When the same IP appears many times in a very short time, it's worth reviewing what it's requesting and how it's doing it.

Data type: categorical text

This is the HTTP method used in the request. The most common are GET and POST.

To understand it without technical language:

• GET usually means someone is asking to see something, like a page or resource.
• POST usually means someone is sending information, for example from a form or to a script.
• other methods like PUT, DELETE, or OPTIONS may appear in more technical or API contexts.

Example usage:
if you detect many POST requests to unknown or suspicious routes, it could be an automated attempt to exploit a form or endpoint.

Data type: categorical text

Collects the name of a marketing campaign in Matomo format, if the URL included that data. This field will only have content when the visit arrives tagged with campaign parameters. If not, it will appear empty. It serves to relate an access to a specific campaign.

Data type: categorical text

Indicates a specific variant of the content within a Matomo campaign. It can be used to distinguish versions of ads, links, or different creatives within the same marketing action.

Data type: categorical text

Stores a keyword associated with a Matomo campaign, if present in the URL. In many cases it may be empty.

Data type: categorical text

Indicates the medium through which the visit arrived within a Matomo campaign. For example, it can reflect whether the traffic came via email, advertising, social, etc.

Data type: categorical text

Indicates the specific source of traffic in a Matomo campaign. It is useful to know where a tagged request came from: for example, a platform, a newsletter, or a promotional source.

Data type: categorical text

This field indicates from which page or site the access came, if that information was available.

Simply put, it helps answer the question: "where was the visitor coming from before arriving here?"

Sometimes it will show an external website, sometimes a page from your own website, and other times it will appear empty or with -, especially when the access is direct or the origin couldn't be determined.

Example usage:

• know if traffic comes from Google, social networks, or a specific website,

• detect internal access between pages,

• or review where certain errors are coming from.

Data type: categorical text

This is the specific path of the requested resource within the website. This field is very important because it shows which file, page, or endpoint was actually attempted to be opened.

For example, it could be:

• a normal page,
• an image,
• a script,
• an administration route,
• or a suspicious URL that shouldn't exist.

Example usage:

• identify the most visited routes,
• detect attempts to access sensitive files,
• locate resources that return 404,
• review if a bot is traversing many different routes.

For simple reading, this field answers: "which exact part of the website did they try to open?"

Data type: numeric

Indicates the size of the response sent by the server, measured in bytes. It is not usually the first field a non-technical user looks at, but it can be useful for detecting very small, very large, or inconsistent responses.

Example interpretation:

• a small response could be an error page or a redirect,

• a larger response could correspond to a page or resource with more content.

Data type: numeric

This is one of the most important fields in the collection. It indicates the result of the request. That is, what happened when someone tried to access that URL.

The most common codes are interpreted as follows:

• 200: everything went fine, the page or resource was delivered correctly.
• 301 or 302: there was a redirect.
• 403: access forbidden.
• 404: the resource doesn't exist.
• 500: internal server error.
• 503: service unavailable.

It serves to answer a very practical question: "did that access work or did it cause a problem?"

Example usage:

• if you want to detect broken pages, filter by 404,
• if you want to detect server technical problems, review 500 or 503,
• if you want to measure successful accesses, review 200.

Data type: numeric

This field represents the total number of visits associated with that user context or access according to the platform's internal logic. Depending on the data source, it can serve as an auxiliary measure to identify recurrence. In many analyses it won't be the main field, but it can provide context when combined with IP, user agent, or fingerprint.

Data type: categorical text

Contains the complete URL requested. Unlike resource_path, which usually reflects only the path, url can give a more complete view of the access as it was recorded. It is useful when you want to review in more detail exactly which address was requested.

Indicates what type of client made the request. Although the value may seem technical, it actually answers a fairly simple question: "who or what made this access?"

It could be:

• a real browser,
• a search engine bot,
• an automated tool,
• a programming library,
• or an external system.

Simple interpretation example:

• if something like Chrome, Firefox, or Safari appears, it was probably a user browsing.
• if something like bot, crawler, python, curl, or a specific library appears, it was probably automated traffic.

This field is very useful for separating human traffic from technical or automated traffic.

Data type: categorical text

This is an identifier generated from several visitor data points, usually designed to help recognize the same access pattern even without a traditional session. It serves for internal analysis and to relate requests to each other when IP alone is not enough.

Data type: categorical text

Campaign name in UTM format. This field will only have value if the visit arrived with UTM parameters in the URL. It serves to know which marketing campaign an access is associated with.

Data type: categorical text

Indicates a specific variant of the content or ad in a UTM campaign. It is used to differentiate creatives, links, or different versions within the same campaign.

Data type: categorical text

Keyword associated with the UTM campaign, if sent in the URL. It won't always be present.

Indicates the medium through which the visit arrived in a UTM campaign.

For example:

• email,
• cpc,
• social,
• banner,
• referral.

It helps classify the type of channel that generated the access.

Data type: categorical text

Indicates the specific source of traffic in a UTM campaign. For example, it could represent a search engine, a social network, a newsletter, or any other promotional origin.

It is one of the most useful fields when you want to analyze traffic acquisition.

Data type: categorical text

Collects the term or keyword associated with a UTM campaign, usually used in search or advertising campaigns. It won't always be present.

Data type: categorical text

This field records an original IP when the request has passed through proxies, load balancers, or intermediate services.

The important thing to understand is this:

• sometimes the visible IP of the access is not actually the final visitor's,
• but rather that of an intermediate system,
• and this field can help recover the original IP.

It won't always have a value, and it won't always be necessary in normal analyses, but it can be important in more advanced traffic or security reviews.

You can search for the URL or route and review the status_code. If you see many 404s, the page or file probably doesn't exist. If you see 500, there is an internal technical problem.

• repeated IPs,
• strange user_agents,
• unusual routes in resource_path,
• high values of abuse_score,
• or many consecutive errors from the same origin.

• many requests from the same IP,
• repetitive or suspicious routes,
• POST methods to specific endpoints,
• and user_agent not typical of normal browsers.

This is important to avoid confusion.

The Web Activity collection records individual accesses.
The Visits collection groups multiple actions from the same user within a single visit.

Therefore:

• use Web Activity when you want to see the technical detail of each request;
• use Visits when you want to understand the aggregated behavior of a visit.

If you need to know:

• "which resource returned an error",
• "which IP requested this route",
• "when exactly did this access occur",
  then Web Accesses is the correct collection.

If you need to know:

• "how long a visit lasted",

• "where a user navigated",

• "how many pages they viewed in a session",
  then it's better to use a session-oriented collection.