Should managers and trusted users increment the view count on a profile?

Question

Hi,

I think it would be valuable if the viewed count on a given profile didn't increment when it's the profile manager or a trusted user viewing the profile.

My reasoning is that as a profile manager / trusted user trying to improve a particular profile I often have to cross-reference multiple profiles I manage as well to gather sources and bio text that I've already posted. Each time I do this, it bumps the view count on the profiles, but these aren't "valuable" views on the profile compared to ones that might have come from searches or other feeds that indicate outside interest.

I have some profiles for which I surely account for > 50% of the views. As the profile manager, I don't care about my views, but would like to see the count of folks who are not me, and possibly focus a bit more effort on the ones that seem to be coming up over and over in searches/feeds.

Just a thought I had and I'm sure I'm not the first. Throwing it out there...

Thanks, Joe

Comments

Please note that there is no such thing as a profile "owner". Being a profile manager is very different than being a profile owner.

---

Chase, You're right. I didn't realize that word would detract from my question or I would have chosen it differently upfront. I apologize for using it. Please replace "owner" with "manager" in my question.

---

I updated the question to remove the questionable terminology. Thanks Chase for pointing it out.

Answer 1

The view count is based on statistics from the web server, which can only "see" the visitor's IP address, and has no way of identifying the user of that address. Therefore, the suggestion is impossible to implement.

Neither should you put too much weight on the view count. When I ran my own web site, I had lots of hits from dozens of different web crawlers (or search engines). Most of those hits don't mean anything regarding a page's "popularity".

Comments

If you are logged in, the server can see the cookie that indicates you are an authenticated user, so it does know who you are and in theory could check if you're on the trusted list of the profile you're viewing. However, the overhead might be quite high for the limited value gained.

---

In a way, the server actually does check if you're on the trusted list, as the page is served in two quite different ways depending on if you're on the trusted list or not. But that information is not used by a normal page hit counter,

Even disregarding the CPU cost in implementing a more sophisticated hit counter, I wonder if it shouldn't be avoided for legal privacy reasons. It's a touchy area.

---

Leif, I appreciate your answer, but I don't think you're technically correct. WikiTree knows the identity of a logged in user vs. a non-logged in user and what authenticated users can access when they're logged in. This is exhibited in access control mechanisms. Ancient websites certainly (naively) used IP address in access logs to implement web counters but modern websites like WikiTree can and surely calculate page views in their database on page load instead of scanning access logs. I guarantee WikiTree is not scanning access logs to compute their profile view statistics based on IP address.

I'm also missing your point on "privacy reasons". There's no information leak on how the view counter is implemented. All I'm proposing is to simply not increment the view count when the logged in user is the manager or on the trusted list. I'm *not* proposing a count stored alongside the identity of a given user.

Jim, comparing "current user ID" against a set of user IDs is not computationally intensive even up to millions of user IDs which is well beyond what I'm proposing. Considering most profiles have 1 manager and less than 5 on the trusted list and that the access control already happens on the profiles this check would piggyback on the milliseconds that have already been spent constructing the page.

Anyway, I don't feel strongly about this so I'm not trying to stir the pot. I don't see computational complexity as a barrier to this.

Thanks,

Joe

---

I had to dig up my old PHP scripts Yes, I did get the relevant data directly on page load, like this:

$url = $_SERVER['REQUEST_URI'];
$agent = $_SERVER['HTTP_USER_AGENT'];
$visitor = $_SERVER['REMOTE_ADDR'];

And stuffed them straight into the database. No need to check the server logs. And that is surely how most web sites do it, to this day.

I stored the data mostly for defense against greedy web crawlers, which steal a lot of bandwidth, and almost never pay back in increased search engine hits. The only search engine I granted unlimited access was eventually Google. But this is of course a digression.

---

Thanks Leif! To continue the digression (ha!): The HTTP_USER_AGENT is easily spoofable and the REMOTE_ADDR is unreliable based on edge serving in modern content distribution networks. But if you have user authentication in your system, you have a cookie (as Jim noted) that provides you with the (hopefully) cryptographically secure identity of the user making the request when logged in. The identity of the user then gives you the ability to provide access control and also the ability to choose how to audit the page view (in this case whether or not to bump the view count on a given page in the database).