![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
siderea) wrote in ![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
dw_suggestions2017-04-10 09:09 pm
Page Statistics 2: Electric Boogaloo
Title:
Page Statistics 2: Electric Boogaloo
Area:
entries
Summary:
Native journal stats, like LJ used to do, only not horribly invasive like LJ. How many, not whom. Also integrated into the DW user interface.
Description:
Way back when, somebody else suggested, in a suggestion titled Page stats (http://dw-suggestions.dreamwidth.org/
Unfortunately, that was the end of the proposal to implement any of the LJ Stats Page here. Unfortunately, because the LJ Stats Page also had lots of other useful analytics information, that was in aggregate and didn't violate anybody's privacy. For instance, from my LJ Stats page I just discovered that my LJ typically gets about 35 daily hits to my journal's RSS feed – information that would otherwise be utterly invisible to me. Since in the past I've wondered if anybody cares about RSS, that is usefully informative to me. For another instance, I am able to see how many visitors – not, mind you, LJ users, just unique visitors – came to a given post. If I had the same stats here on DW, I would be able to see how my efforts to move my readers from LJ to here were working.
When last this was proposed, one of the questions a commenter reasonably asked was "How is it different from the Google stats feature available for paid DW accounts?"
1) It doesn't involve Google for one thing. I have two big problems with Google Analytics:
1a) It is, to me, a much bigger privacy violation than My Guests ever was. My Guests was optional: if you ever wanted not to be counted, you turned it off and you never appeared in anybody's My Guest report. I, as a reader, have no way to opt out of GA – except to use a script blocker to clobber GA, which I in fact do, because....
1b) Google Analytics' degrades site performance. I have to block the GA scripts at my browser, because otherwise, from time to time, page loads start hanging on trying to communicate with google-analytics.com. I don't want GA on my journal both because I don't want to inflict on my readers a privacy compromise I don't want inflicted on myself, and I don't want to inflict on either me or my readers the page load times GA periodically (or is it always? as I said, I block it) causes.
2) As per 1b above, GA is client-side and third party. I don't want this sort of functionality coming through *any* third-party javascript. It will always tax the user's browser and internet connection, and expose information to a third-party. I have no interest in trusting any third-party with, for example, statistics *about my locked posts* the existence of which should be a private.
3) Not having a GA account I can't say what it includes in its reports, but knowing what I do about its implementation, I'm guessing it has no way to tell you *the number of times your post appeared on other parts of the site*. AFAIK, GA only knows – only *can* know – about the concept of "webpages". LJ's Stats would give you *two* numbers: the number of unique visitors to a post's page *and* the numbers of unique viewers of your post _in all the other places it appears on LJ_, such as on friends pages, your own Recent Entires pages, your Calendar pages, etc. LJ Stats leverages LJ's knowledge of its own info-architecture to come up with stats that GA can't.
Finally, it would be great if the interface for such a thing were integrated into the general DW journal interface, such that journal owners would have a contextual stats icon/link (visible only to them) wherever appropriate, that takes them to the corresponding stats page. For instance, such a link would appear on posts, and would take one to the stats page for that specific post. One's Calendar would have it on the day, month, and year views, and take one to one's corresponding day, month, and year stats pages. And that's not something that GA or any third-party javascript-based analytics implementation could manage.
More Details
When last this came around, it became clear most commenters didn't know what LJ did provide. Here's an overview:
There are four top level categories to the Stats page that I propose are of interest to DW: Journal, Comments, Entries, and RSS Readers.
The Journal page shows stats for your whole journal, breaking it out by number of total visits, total unique vistors, and how many of those unique visitors were logged-in LJ users. It allows you to view this information by either your journal itself, or your journal plus all friends pages on which your posts appear, and it allows you to drill down in either of these views to any year (shows bar chart by month), month (shows bar chart by day), or day (shows bar chart by hour). This last allows one to get a sense of on what days and at what times of the day one's readers are seeing one's journal.
The Comments page shows the stats on numbers of comments and numbers of commenters. Like the Journal page, you can drill down by time span.
The Entries page shows the stats for a given entry (post). It defaults to the most recent entry in your journal, has a list at the bottom of your ten most recent posts with links to their stat pages, for user convenience, and a text box in which you can put the URL to any of your entries to get the stats for it (not the most convenient of user interfaces). For a given entry, it shows Visits, viewers ("Who Viewed"), and Comments. Visits breaks out by Entry Views, All Visitors and Livejournal Visitors. "Entry Views" is the other sense of "entry": when that page is the page-of-entry of a reader to LJ – what happens when somebody follows a link somewhere else, like Twitter or Tumblr or FB or an RSS reader or an email, to a post of yours. That gives one a sense of how much traffic is being driven to a post by virality elsewhere. Visits also allows drill down by year/month/day, same as above. "Who Viewed" gives a break down between the number of all viewers of the post vs. the number of the subset that are Friends of you - it shows you whether it's just Friends reading your posts or other people. Also allows drill down by year/month/day. "Comments" shows comments vs number of unique commenters for the post, with year/month/day drill down.
The RSS Readers page shows a chart of number of requests to one's RSS feed, with drill down by year/month/day.
This suggestion:
Should be implemented as-is.
31 (66.0%)
Should be implemented with changes. (please comment)4 (8.5%)
Shouldn't be implemented.0 (0.0%)
(I have no opinion)12 (25.5%)
(Other: please comment)0 (0.0%)
no subject
I'm sure the owners and staff can change their mind if they're convinced, but there is a reason GA is used right now.
I wish you luck!
no subject
DW uses Google Analytics sitewide to gather browser/OS/connection speed data in aggregate so we know which browsers we need to support and which ones we can drop support for, and we don't add the Analytics script on any individual journals (individual entry pages or the journal as a whole). People can add their own Analytics code to their journal if they want, though, which is what
Even if we did/do add any kind of DW-native stats system, we'll continue using Analytics (on non-journal pages), because it's an easy way to gather browser/OS/connection speed data without having to build our own and reinvent the wheel.
EDIT: I wandered over to check the DW Analytics results, and some interesting stats:
* 70% of people visit DW on a desktop/laptop; only 30% visit on phone/tablet.
* Chrome is the most popular browser, at 55% of our traffic. Firefox is second at 18%. Safari is third at 17%. Internet Explorer is a very distant fourth -- at 2%!
* 76% of our traffic is returning visitors; 23% is new visitors.
Etc! That kind of information helps us figure out things like "ugh, can we stop supporting older versions of IE yet".
no subject
I posted the link only because I wanted to share what was shared with me earlier, in case someone wants to get rid of GA altogether. I did not mean to suggest siderea's suggestion is no different from mine.
no subject
no subject
If it is, it's under a different name! Over the last month, I don't see it as a top-level browser ID or as a subset of Firefox.
no subject
I disagree with having an "opt out of having my stats collected" option - if it's invasive enough that that's warranted, we shouldn't be collecting it. I'm not sure if that was actually part of the suggestion, or just part of the "what LJ does" explanation ☺️
no subject
My one suggested change (and I may have missed it if you already included it in your proposal): make it possible for the journal owner to choose not to have a link to that statistics dashboard (perhaps this is something that people could do for themselves with custom styles for their journals). My reasoning is similar to the reasoning for how Inbox notification settings make it possible to avoid getting notified when someone removes you from their circle; sometimes a journal owner wants to make it harder for themselves to notice the moments when they are not very popular.
no subject
no subject
As long as this part is implemented, why not?
no subject
no subject
I suppose this would be useful also for non-native speakers of English (or Russian) as it's rather hairy to get into a conversation with another person from your own language sphere - just because, outside of commenting or writing PMs, there's no way to let them know you were visiting.
And for the most part, the best possibility to find any people from your own country at all is through the Directory Search via searching by country... It's less likely you'll do so by accident when being active in a community or commenting to random journals.
For communities, I suppose, this might also be useful, especially for small ones who aim for a specific audience, or which aren't part of any bigger fandom community (some people tend to forget such exist too).
Oh, and @
I kind of tried my way already through to find out what does that, and at least I found out it's no Firefox plugins going partially broken from time to time! But neither does browser change alter anything on that, it originates in the page loading at all...
If it's just a certain part of it, which even can't be found on all subpages (journals, profiles, own Inbox), then this would make some sense in not being a permanent issue.