Separate page metrics by hostname

[J3RN]

Closes #160

Changes

Goal

The issue I am aiming to solve is that some people (myself included) use subdomains, and want the data for the main site (e.g. j3rn.com) to also include data about the subdomains (e.g. blog.j3rn.com) such that they can have a holistic overview of an entire property.

Proposed Solution

I modified the "page" queries (top pages, entry pages, etc) to:

1. GROUP BY hostname
2. Combine the hostname and path to form the name field (whereas it was previously just the path).

This worked relatively well with the existing React code, and only a small change (outbound links) was needed.

I've tested this locally to my own satisfaction. I'm very open to feedback on any ways this can be improved!

Please describe the changes made in the pull request here.

Below you'll find a checklist. For each item on the list, check one option and delete the other.

Tests

• Automated tests have been added
• This PR does not require tests

Changelog

• Entry has been added to changelog
• This PR does not make a user-facing change

Documentation

• Docs have been updated
• This change does not need a documentation update

[ukutaht]

Thanks for the PR!

I'd like to discuss the approach before accepting this PR. 90%+ of our users are running a single site and seeing the same hostname repeatedly can be seen as clutter in the UI:

So while this works great for your use-case, I believe most of our users would not want to see their pages like this.

Also, some people who requested this feature would still want to see total page visits by default and only break them down by hostname occasionally with a filter (for example people using subdomains for different languages).

An implementation of this feature would have to account for and make sure that:

• People who only use one hostname do not get extra clutter on their dashboards
• People who use multiple hosts need to be able to select whether they want their pages broken down by hostname or not

I would suggest adding an option to the 'top pages' modal to break down the pages by hostname as well as pathname. Optionally would be great to allow the user to save it as the default view for their pages.

Another idea, the Page url label in the pages report could be a subtle clickable switch between showing pathname vs hostname+pathname. Store the preference in localStorage as with other UI switches.

What do you think?

[J3RN]

Hey @ukutaht! Thanks for taking the time to review my PR! I'd be happy to implement the changes as you've described, but I also had an alternative idea for you!

1. If the front-end detects that there are multiple hostnames, we can show a toggle between showing top paths or top hostnames in the "Top Pages" section using a toggle similar to what the Devices section uses:
   (Current Devices panel)
   
   (Mockup of same idea in Top Pages)
   
   For use cases such as "I want to see which of my domains gets more traffic," this would be ideal.
2. Make the hostname clickable, and when clicked applies a filter to scope all dashboard metrics to only that hostname like clicking a path, country, OS, etc, in the existing panels.

Here's a mockup of the whole idea:

1. Breakdown of paths (for all hostnames):
   
2. Breakdown of hostnames:
   
3. Breakdown of paths after filtering by blog.j3rn.com:
   

Of course, I'd be happy to persist these preferences in localStorage 😁

What do you think?

[ukutaht]

I think it looks neat and would be nice if it automatically detects whether the hostname selection should be shown.

However, @metmarkosaric and I have planned this space to be used for a different function. The area where you've placed pathname / hostname switch is an ideal place to allow people to select between entry / exit / all pages or something like that. I think much more people will use the entry/exit pages selector than the hostname selector.

So this is why I still think it should be hidden in the modal popup or in a more subtle UI interaction.

[bmenant]

Hi there,

@ukutaht How about adding a Domains or Hostnames selector to the Top pages - Entry pages - Exit pages selectors? It’d be pretty consistent IMHO.

To summarize:

• No change to top/entry/exit pages views.
• Add a new panel view for domain breakdown (shows pageviews per domain), together with top/entry/exit page panel.
• This domain selector and view is shown only if we’ve got multi-domains or subdomains data to report.
• Just like any other top/entry/exit pages selector, if one clicks one domain in the breakdown, the whole dashboard filters data for the selected domain (with a domain filter item shown at the top of the page).

What do you guys think?

If it sounds good to you, I can work out a new PR or work over this here one.

[vermorel]

The hostname capability is important to me as well. IMHO, displaying the hostnames is better whenever multiple hostnames coexist.

[ukutaht]

Thanks for the suggestion @bmenant. I can see how it solves your problem, although I'm not convinced it's the best place for it. What if you want to see entry/exit pages also broken down by the full URL including hostname?

I have a suggestion: how about making the Page url label a dropdown where the other options being Full url and Hostname? Should be pretty self-explanatory options. I think it preserves the UX logic a little better and gives many more options to drill into your data e.g. entries broken down by hostname or full url which would not be possible with the original suggestion.

It would be a fairly hidden feature that people need to learn but I think that's appropriate since it's a niche use-case. Maybe you can tell that we're obsessed with keeping the dashboard clean for the average use-case. WDYT? @vermorel ?

[bmenant]

@ukutaht Sounds like this label would change the group by clause, right? The dropdown’s title could be group by for example? Then, I understand that for each Top/entry/exit view I can group by:

• Page url (default): I have what I can see right now on Plausible, results grouped by path (say /foo - 4 and /bar - 3).
• Full url: results are grouped by hostname & path (say example.com/foo - 2 and jdoe.com/foo - 2 and example.com/bar - 3).
• Hostname: results are grouped by hostname only (say example.com - 5 and jdoe.com - 2).

Page url and Full url might be a little confusing at first, but one can just try them out and see (I’d find Path, Host + Path and Host stricter and maybe more conventional but that’s also a matter of taste).

With your suggestion in mind, I understand I can click that dropdown, select Hostname, find the hostname I want, and click on it to filter the whole dashboard by this hostname.

Sounds a little slow at first, but a power user could just “hack the dashboard url” and instantly see results for a given hostname.

👍 LGTM

P.S. I totally understand your obsession, keep it on! ;-)

[ukutaht]

Yes that's exactly right, the label is the group by whereas entry/exit/top pages are completely different queries on the backend.

With your suggestion in mind, I understand I can click that dropdown, select Hostname, find the hostname I want, and click on it to filter the whole dashboard by this hostname.

That's right. I think in the future we'll also have a global Filter dropdown at the top where you could navigate to Filter -> Hostname -> Select from a list. This should simplify your use-case and also accommodate filters that you can't access by just clicking on stuff in the UI (e.g. pathname starts with /blog)

Naming is always debatable, I like the direction you're thinking in but instead of a plus sign they could be formatted as:

• Path
• Host
• Host/Path

[baptisteArno]

Hey guys, I would be really interested to implement this feature.

I'm wondering:

Why wouldn't this be a great way of implementing it?

[metmarkosaric]

thanks! mostly because for 95%+ of our audience that would be noise that is not necessary to have as they only have one single domain. we're trying keep Plausible as nice and minimal as possible.

for your example it doesn't look too bad but imagine sites with longer domain names or sites with longer page paths. Top Pages report as it is right now would become less useful for all of them and it would simply repeat the same domain/page path 9 times. Top Pages is one of the most important things they look at so we cannot make it less useful for the majority of our audience

Other sites with similar usecase also want to be able to see all traffic combined but then also to be able to split and view a specific subdomain on its own so the feature has to satisfy those needs too

[baptisteArno]

Then I think maybe this could be the best of the 2 worlds:

• No difference for the 95%+ of the audience.
• Minimalist subdomain differentiation for the 5%- of us.

[metmarkosaric]

looks better for sure! how do you imagine the people that only want to select blog or app doing that with this design?

worth exploring how it will look if blog and app are designed more like a label or a highlighted word to differentiate them a bit better

[vermorel]

@metmarkosaric I would respectfully but firmly disagree. On the contrary, I observe that the majority of the people who actually run at least 1 website, run multiple websites.

I would strongly support the first option (which include the hostname) as proposed @baptisteArno. Right now, this feature is the No1 feature which prevents us from moving to plausible.

[metmarkosaric]

thanks @vermorel! sure, people have multiple websites often but why would you want to put irrelevant websites on the same dashboard? i've only heard a handful of requests for this feature out of 15,000+ sites that use Plausible

[baptisteArno]

worth exploring how it will look if blog and app are designed more like a label or a highlighted word to differentiate them a bit better

Yeah, great idea, it could be presented as a colored tag. I'll make a proposition any time soon!

[ukutaht]

@baptisteArno your suggestion works great for people who specifically install their tracker on multiple subdomains of a single top-level domain. Any ideas for the third group in this list?

• People who run plausible on a single domain (let's assume 90% of people)
• People who run Plausible on multiple subdomains of a single top-level domain (let's assume 90% of people who use Plausible with multiple domains in general: main.com, blog.main.com, staging.main.com, etc)
• People who run Plausible on multiple completely different domains which do not have a relationship like TLD -> subdomain. (domainA.com, domainB.com, etc.)

[baptisteArno]

The third group should have a dashboard for each domain. There's no point in having different domains on the same Plausible dashboard IMO.

=> If their domains are related in some way then it's a misconception from their side. Do you have an example in mind where it would make sense to have a unique dashboard for different domain names?

[Vigasaurus]

Do you have an example in mind where it would make sense to have a unique dashboard for different domain names?

Not myself, obviously, but some examples:

• google.com, google co.uk, google.ru
• discord.com, discordapp.com, discord.app

These are all technically the same application, but a user may want to track them in combination for some use cases, but be able to split down to per-hostname stats to determine if one performs better than the other/how things vary.

[baptisteArno]

• google.com, google co.uk, google.ru
• discord.com, discordapp.com, discord.app

Ok, these are legit use cases.

Are the pages views are currently being collected on a "discordapp.com" site if you install a "discord.com" tracker? @ukutaht

[Vigasaurus]

Are the pages views are currently being collected on a "discordapp.com" site if you install a "discord.com" tracker?

They would, yes. As long as the user has a unified data-domain value, the actual hostname doesn't matter - and (the full path including hostname) is still saved as part of the event data in Clickhouse.

They'd however all show up grouped just by the pathname in the current setup, with no way for a user to differentiate which hostname they came from.

[baptisteArno]

Ok, then I can't think about a more intelligent solution than dynamically displaying the page views based on these conditions:

• If page view is from the exact same configured domain: show only the pathname
• If page view is from a subdomain of the configured domain: show the pathname with subdomain as a "label" next to it (displayed here with parentheses)
• If page view is from a completely different domain: display the entire domain + pathname

• People who run plausible on a single domain (let's assume 90% of people)
• People who run Plausible on multiple subdomains of a single top-level domain (let's assume 90% of people who use Plausible with multiple domains in general: main.com, blog.main.com, staging.main.com, etc)
• People who run Plausible on multiple completely different domains which do not have a relationship like TLD -> subdomain. (domainA.com, domainB.com, etc.)

What do you think?

[Vigasaurus]

I think in theory that's fine, but personally I think having the option to split by hostname or not on the fly is still vital. And it should probably stay consistent in the format (whether it shows the subdomains style, or the external style), in my opinion.

[baptisteArno]

Ok, and any sort of filtering option should be available only after we found a way to properly list all the page views grouped by pathname and hostname.

[Vigasaurus]

Honestly I don't think this is that complex a feature from a technical standpoint, I think the main thing is just to hear out what exactly the behavior should be. Grouping by hostname when required, should just be a single change to the Clickhouse query (I can't recall how much the urls get stripped/standardized, but theoretically this is true).

[bmenant]

Just wanted to point out I still find the suggestion by @ukutaht as the best answer in term of usability and functionality.

Also, I would like to give another use-case (ours)... It’s a private platform where we’ve got hundreds of subdomains and domains plugged onto a single service platform. Internally, each domain or subdomain relates to a project, campaign or operation (whatever you call them). Each campaign might have its own theme and features... but the mere mechanism and structure are for the most parts the same from a campaign to another. The closest example I can think of is the campaigning platform application of SumOfUs: Champaign.

At a platform scale, there are times we want everything to be grouped by domains (surge of visits on the “I’ve got a problem” page, for example, which would hint at a potential issue on our platform). There’re times we want to compare how different domains (campaign/operation/project) perform.

At a campaign/project/operation scale, we usually want to filter by domain.

[anthonymf]

So @ukutaht should we reopen this to implement your solution or open a new issue?

[ukutaht]

There is an active discussion here: #160. No need to open a new issue :)