Live current visitors counter in title
mxrlkn opened this issue · comments
Feature request:
A live counter of current visitors in the title on the selected website. Being able to see it at a glance of the tab is great I think.
Here's an example of how it looks in Fathom:
It's something I've considered but haven't yet figured out if possible with our data model.
Other solutions use IP address hashing that allows them to individually identify each user as they navigate a website. We don't use IP address hashing, which makes it impossible for us to link page views across multiple pages as one "session". All we know is whether the visitor has or has not visited the page before which isn't enough information to work with for this.
It's a trade-off between privacy and useful metrics. This is a "nice to have" feature, but imo not critical to have, so I'm not too fussed if this sort of feature never gets implemented in Medama.
I see. It could also just be "page views" instead in the title. That's actually how it works in Fathom (even though it says visitors).
I'm not well versed in GDPR etc. But wouldn't it be possible to set a unique key in sessionStorage and use that only for the current visitors live function? Not saving it in db but just in memory.
I see. It could also just be "page views" instead in the title. That's actually how it works in Fathom (even though it says visitors).
Something like this? I’m not entirely sure. "Current visitors" makes sense since you can glance at the tab while working and see it change every minute, but it might be less useful if the number doesn’t change at all.
I'm not well versed in GDPR etc. But wouldn't it be possible to set a key in sessionStorage and use that only for the current visitors live function? Not saving it in db but just in memory.
This is a bit of a murky untested territory. You’re not wrong, but it can still be argued as storing a unique identifier on the user’s device, which might raise concerns about requiring user consent, even if it’s short-lived. Opinions vary since the laws are vague and are not clear until tested in court.
A big reason why I started this project was my dislike with pseudonymization techniques like IP address hashing, or anything that can be seen as identifiers with the potential to track users across an entire website. I’d prefer to stay on the side of simplicity and anonymity, even if it means sacrificing a few features.
Something like this? I’m not entirely sure. "Current visitors" makes sense since you can glance at the tab while working and see it change every minute, but it might be less useful if the number doesn’t change at all.
Kinda. I meant more like "Current page views". I imagined something like this:
- page hit
- save that hit in memory (obj, list. w/e), clear it after x minutes
- websocket (or similar) send combined hits after each change.
So it's not 100% correct in how many are on the site. It's more like: "approximate idea of how many views currently".
This is a bit of a murky untested territory. You’re not wrong, but it can still be argued as storing a unique identifier on the user’s device, which might raise concerns about requiring user consent, even if it’s short-lived. Opinions vary since the laws are vague and are not clear until tested in court.
I feel you. But in this case you're not storing it. You could do it with just a variable instead of any storage as well. const id = createUniqueID().
"approximate idea of how many views currently".
There are two metrics we know:
- First time a visitor is visiting the website
- First time a visitor is visiting a specific page on the website
We could do a 5 minutes rolling counter for the first metric, but it wouldn't be return current visitor data for returning visitors at all. Using the second metric would inflate these values significantly instead. I can't think of any combination of these datapoints that would work together well without returning a wildly inaccurate approximate. And I definitely don't want to advertise a feature that returns wrong data.
I feel you. But in this case you're not storing it. You could do it with just a variable instead of any storage as well. const id = createUniqueID().
This would work with SPAs or any website that use the History API for routing. It would not work with traditional websites that does not use custom routing since createUniqueID() will be run on every page load. sessionStorage does persist through multiple pages at least.
We could do a 5 minutes rolling counter for the first metric, but it wouldn't be return current visitor data for returning visitors at all.
I'm talking about just the simple page view, whether or not its a new visitor.
If I reloaded any page 20 times, the "Current page views" would be 20. If another user did that as well it would be 40. So just a rolling counter for any page view from any user. after x minutes, they're gone.
This would work with SPAs or any website that use the History API for routing.
I thought it was an SPA for a second my bad. But I think the point still stands with sessionStorage as it gets cleared when they leave site. So no persistence.
I'm talking about just the simple page view, whether or not its a new visitor.
Oh, I see. I personally don't like the clutter in the document title, but I see the value in it for some people. I think it would work great as an opt-in feature, so I'm happy to add this to the backlog.
I thought it was an SPA for a second my bad. But I think the point still stands with sessionStorage as it gets cleared when they leave site. So no persistence.
I did a re-review on this and corroborated it with a bunch of other written articles since everyone has a slightly different opinion on this topic due to its vagueness. Article 5(3) of the ePrivacy Directive (the actual one responsible for all the cookie banners):
[...] the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent [...]
In other words, we would still need user consent, because it's not a matter of persistence but the actual action of storing non-functional data on a user's device and/or retrieving it.
I think it would work great as an opt-in feature, so I'm happy to add this to the backlog.
Great!
In other words, we would still need user consent
Alright, thanks for looking into it :)