Best way to tell subdomains apart in one website?

[adminko-svk]

Hi, and thanks for Umami!

Setup

We run one self-hosted Umami website (v3.4.0) for a site with a very large number of subdomains. We send page views ourselves with a small fetch to /api/send (no tracker script, no cookies) to keep the pages lightweight.

What we noticed

In the Pages report only the path is shown, so / on www.example.com and / on any subdomain look identical. The hostname is stored with every event and can be used as a filter (and there is a Hostname view), but it is not visible in the Pages list.

Our workaround

We prefix the hostname to the URL we send:

fetch('/api/send', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    type: 'event',
    payload: {
      website: WEBSITE_ID,
      hostname: location.hostname,
      url: '/' + location.hostname + location.pathname + location.search, // hostname in the path
      title: document.title,
      referrer: document.referrer,
      language: navigator.language,
      screen: screen.width + 'x' + screen.height
    }
  })
});

So the same page shows up as /subdomain-a.example.com/ instead of /.

Questions

1. Is putting the hostname into url an acceptable approach, or does it have downsides we are not seeing (e.g. for sessions, entry/exit pages, UTM handling, referrer filtering)?
2. Is there a better built-in way to see pages per subdomain in one website, for example a hostname column in the Pages report, or using tag for this? (I read in subdomain support for multi-tenant application #897 that the website ID is what matters and the domain field is only used to filter referrers.)
3. Would a separate Umami website per subdomain be recommended instead, even with thousands of subdomains?

Thanks for any advice!

[AbdullahTammar]

For thousands of subdomains belonging to the same site, I would keep one website and preserve the real path plus the separate hostname. Your workaround is accepted as a path, but changes the meaning of the stored page data.

Looking at the v3.4.0 collection handler:

• /subdomain-a.example.com/ is stored literally as urlPath; it is not interpreted as a hostname. Page filters and entry/exit reporting consequently use that synthetic path. Changing the convention later also splits historical page totals between the two forms.
• UTM parameters are parsed from the query string, so your unchanged location.search preserves them.
• Session IDs are derived from the source ID, IP, user agent, salt, and optional distinct ID—not the URL path or hostname. Prefixing the path therefore does not create separate sessions per subdomain.
• Self-referrer detection compares hostnames. The path prefix does not change that behavior, and a different subdomain can still be recorded as a referrer.

I would send:

hostname: location.hostname,
url: location.pathname + location.search,

and use the hostname filter you already found when inspecting Pages. A tag would add another dimension but would not itself add hostname to the Pages grouping. The v3.4.0 metrics query groups by the requested metric, rather than automatically grouping pages by both hostname and path.

If you need all (hostname, path) pairs visible together, a custom report/export grouped by those two stored fields preserves the original data without inventing paths. Separate website IDs make more sense when you want independently managed analytics; they also change the session namespace, so I would not introduce thousands solely to fix this display limitation.