3 ms·
On the aspects of logging and analytics. Back in the dark-ages, before javascript was a thing, we relied on webserver logs and local database entries. Later cam
by lokimedes 2y ago
On the aspects of logging and analytics. Back in the dark-ages, before javascript was a thing, we relied on webserver logs and local database entries. Later came the infamous transparent pixel for cross-site tracking.
How many websites could suffice with such analytics today, I wonder?
Has Google Analytics, and the likes, sold us on learned helplessness to support their own interests of getting cross-site data from everyone to power their advertising? Perhaps my idea of tracking value is stuck in the dark-ages as well…
- baliex 2y agoTotally agree. I’ve found goaccess to be the perfect tool for this. No tracking at all on the user’s side and enough information in the logs for me to get a feel for how much traffic I’m getting. There was a post here recently about anonymising the IP addresses in the logs to be absolutely sure that you don’t end up collecting any personally identifying information (PII).
- jasode 2y ago>, we relied on webserver logs and local database entries. [...] How many websites could suffice with such analytics today, I wonder? Has Google Analytics, and the likes, sold us on learned helplessness to [...] to power their advertising? No, it's not just serving Google's own interests for advertising. The GoogleAnalytics tags & tracking is also serving the desires of the content creators and authors. Think of it as 2 different levels of data: (1) server connections data -- vs -- (2) demographics data (1) Local server logs of anonymous users will have data like ip addresses and web browser user agent strings. One can use this for monitoring bandwidth, analyzing DDOS attacks, decide on Cloudflare, etc. It's "sysadmin" type of data vs "marketing" data. Yes, one can do some limited demographic info such as ip geolocation cross referencing and/or "mobile-vs-desktop-ratio" from user-agent strings but server logs don't have rich enough data to satisfy content creators. (2) GoogleAnalytics has higher-level data such as demographics[1]. Content creators like to get extra insights into "who their audience is". Male-vs-female ratios, young/old, etc That's why a so-called "simple" minimalist website such as https://motherfuckingwebsite.com/ https://motherfuckingwebsite.com/ ... that lectures readers on avoiding useless tech ... still has the author motivated to embed GoogleAnalytics into it. (Ctrl+U View Source to see GA script tag at the bottom.) Can't web authors just blog without giving a care about fine-grained audience demographics?!? Sure they can. But many of them don't. To them, getting insights into their audience helps them shape the next article or adjust their content, etc. [1] https://www.google.com/search?q=google+analyltics+demographics+data https://www.google.com/search?q=google+analyltics+demographi...
- samstave 2y ago> Can't web authors just blog without giving a care about to wit: thats the whole reason for blogging... giving a care and hoping for audiance. (audiance - those that hear) I could dive deeper into etymology... of the web.
- samstave 2y ago>in the dark-ages, before javascript was a thing" back in your day (and mine) -- there was never such a thing as 'product manager' (read marketing exec MBA - who runs the web show) Bill hicks would have a word https://www.youtube.com/watch?v=9h9wStdPkQY https://www.youtube.com/watch?v=9h9wStdPkQY
- manuelmoreale 2y agoSo I’m in the “I don’t give a crap about analytics” camp. I don’t use GA or similar tools and I occasionally run my server logs though go access if I want to get a sense of what’s going on. From my experience, neither of the two methods is bulletproof. GA clearly can’t track people with ad blockers and server logs don’t suffer from that problem. But they do suffer from extreme noise. RSS requests, bots, scrapers, you name it. There’s a lot of crap mixed with regular humans visiting my site. At the end of the day, I think logs are fine if you just want to get a broad picture of what’s happening. I do believe people with personal blogs shouldn’t care about analytics at all. Just focus on the content and ignore the rest.
- rollcat 2y ago> [...] server logs don’t suffer from that problem. But they do suffer from extreme noise. RSS requests, bots, scrapers, you name it. There’s a lot of crap mixed with regular humans visiting my site. Looking at the raw logs is pretty pointless at any scale, unless you're investigating a specific production issue. There are analytics tools that ingest server logs, filter/aggregate the data, and make pretty dashboards. I used to use something that I found in the Debian repos long ago, can't remember the name now, coz > I do believe people with personal blogs shouldn’t care about analytics at all. Just focus on the content and ignore the rest. This.
- manuelmoreale 2y agoWell I’m not suggesting that one should look at raw logs. I’m suggesting using something like https://goaccess.io/ https://goaccess.io/
- austin-cheney 2y agoEmails still make use of the transparent pixel. It’s not about making use of archaic conventions. It’s more about hiring competent people who can perform analytics without disruption. That, though, like so much of the article, requires tremendous wishful thinking. The commercial web is always going to be slow and bloated because the standards and browsers permit and tolerate unbelievable levels of gross negligence. The people doing the work also typically have absolutely no idea what they are doing and are super happy when they can just get text to display on the screen using the worlds largest frameworks. The incompetence is so real that I refuse to do that kind of work any more. There is just so much whining and crying at the mere suggestion of mild improvements. It took half a year of unemployment last year, but fortunately I was able to find a new line of work that benefits from my prior programming experience. Maybe in the next few years AI will replace the whiners that require 10mb of code to put text on screen.