joshyi
joshyi on Hacker News
If you're using it to serve the marketing team, then yeah. We use it more for server performance and metrics that cookie-cutter JS analytics tools can't really provide.
btw, JS-based analytics are no longer as accurate for identifying "real humans" as they used to be. bots have gotten much better at behaving like a person behind a keyboard, so it's increasingly easy for them to make your analytics tool think they're a real user
It's a oneliner for us, we run Caddy at the office and just specify --log-format=CADDY --keep-last=90 --date-spec=min and a single instance is ingesting ~100M/req a month
and honestly, there's still no other tool that does what GoAccess does quite as well. Most of the alternatives are cookie-cutter, JS-based Google Analytics wannabes. And with bots becoming much smarter and more prevalent when accessing websites, relying solely on JS-based tracking isn't as trustworthy anymore. We use GoAccess to capture what JS-based analytics can't, e.g., server side perf and traffic data. It's not meant to serve the marketing team though.
We use it on our site, which handles around 100M requests per month, works really nice. In fact, we have a screen in the office that continuously displays the stats, quite nifty!
I believe JS analytics tools serve marketing well, providing estimates like who's purchasing my product or how many are reading my article.
However, for devops, relying too much on these tools can be a trap, potentially causing security and server issues without immediate detection. Our team opts for goaccess for this reason. We prioritize accurate data from logs and scrutinize traffic patterns, focusing beyond just distinguishing between human and bot counts, a task we leave to the marketing/product department.
I think many developers overlook this aspect. If you're not in marketing, it's not just about tallying human visitors on our sites. It's essential to be vigilant against possible daily attacks and avoid excessive reliance on basic JS analytics.
Even for personal websites, relying solely on JS can compromise security. We require precise data, and logs prove more dependable than JS, especially with the increasing number of tools tampering with JS data.
We should steer clear of the trap of exclusively focusing on the count of human visitors.
JS analytics are increasingly susceptible to inaccuracies as data manipulation methods multiply, leading to the production of unreliable events from JavaScript endpoints. Staying abreast of industry developments highlights a rising trend of blockers leveraging AI-driven detection, reducing the significance of JavaScript analytics in such situations.
While JS analytics may suit the needs of marketing professionals concerned with product sales and article visibility, those focused on precise traffic patterns, like daily devops, find GoAccess to be a more effective tool.
JS analytics face an escalating risk of inaccuracies due to the myriad ways data can be manipulated, resulting in the generation of unreliable events from JavaScript endpoints. Keeping up with the industry reveals an emerging trend of blockers using AI-driven detection, diminishing the relevance of JavaScript analytics in such scenarios.
I would contend the contrary. Our company consistently runs GoAccess because we are primarily concerned with unusual traffic patterns. This involves monitoring for potential attacks or abnormal bot traffic that might impact our servers, etc.
While JS analytics tools might be of more interest to the marketing team, they are not as crucial for the devops team.
If accuracy refers solely to human-vs-bot detection, there might be a point, but for comprehensive traffic analysis, access logs are unparalleled in accuracy.
JavaScript analytics are increasingly prone to inaccuracies due to numerous methods available for manipulating data, leading to the generation of inaccurate events from JavaScript endpoints. Staying current in the field reveals a growing trend of blockers employing AI-driven detection, rendering JavaScript analytics less relevant in these cases.
Same here. We’ve been using goaccess for years on a 300M hits a month. Self-host is the way to go for us.
For sure lots of issues for peloton after those accidents with kids.
We’re using our own logs with
https://goaccess.io processing over 300M requests a month with no issues.
No privacy issues to worry about using trackers.
I think it depends a lot in what you are after. Accurate results through the logs, including bots.
Or inaccurate results via JS. Bunch of services folks are using out there that blocks them.
Still, there's a lot more data outputting from goaccess with support for custom logs.
Tracking visitors at the client level deflates the actual number of visitors. On the other hand, server-side tracking provides a more accurate number with the tradeoff of not knowing for sure if the client is a human behind a browser.
We use goaccess against a pretty busy centralized log server and has worked really well for years. We don't have to worry about JS and that's always a plus. I personally like how it follows the unix philosophy.
I think server logs are more accurate, it will tell you exactly what's going on, but like you said, bots will show up as well.
On the other hand, a bunch of folks (+600M) block JS analytics/trackers so it will deflate the actual number of visitors, thus less accurate.
I agree, works really well for us. Above all, no javascript!
For us it was literately an `apt install goaccess`, picked the COMBINED log format and it's been running for over a month in prod without issues (rotating weekly).
You should post the issue on their https://github.com/allinurl/goaccess, they may be able to help you.
Doubt very much that ~2M will be a memory issue (unless you got less than ~130MB).
https://goaccess.io/faq#performanceWe're running v1.4 in production and it has been working pretty nice for us.
I think a big problem with Google Analytics is accuracy, especially with the now so popular adblockers. Log analysis such as GoAccess should be able to track these down fine since it works at the server level.
I believe tracking visitors at the client level deflates the actual number of visitors. On the other hand, server-side tracking gives you a more accurate number at the cost of not knowing for sure if the client is a human behind a browser.
Google Analytics keeps track of visitors using cookies, so if a browser has cookies or JavaScript disabled, then it won't keep track of it. This includes the now so popular adblockers and bots as well. Log analysis such as GoAccess should be able to track these down fine since it works at the server level.
I believe tracking visitors at the client level deflates the actual number of visitors (due to reason listed on #2). On the other hand, server-side tracking gives you a more accurate number at the cost of not knowing for sure if the client is a human behind a browser.
Google Analytics keeps track of visitors using cookies, so if a browser has cookies or JavaScript disabled, then it won't keep track of it. This includes the now so popular adblockers and bots as well. Log analysis such as GoAccess should be able to track these down fine since it works at the server level.
I believe tracking visitors at the client level deflates the actual number of visitors as pointed above. On the other hand, server-side tracking gives you a more accurate number at the cost of not knowing for sure if the client is a human behind a browser.
I'd say start with the basic command of goaccess and then you can add extra options to the command line as needed. We have ours on a big display at our office running real time with only the most relevant panels that fit our needs.
Overall the stats are pretty accurate, we did some tedious/manual analysis of our weekly access log and the counts displayed by goaccess are on a par with our data results.