4 ms·
> And not just the bad ones, like Google Analytics. Even Fathom and Plausible analytics struggle with logging activity on adblocked browsers. I believe that's
by nannal 3y ago
> And not just the bad ones, like Google Analytics. Even Fathom and Plausible analytics struggle with logging activity on adblocked browsers.
I believe that's as they're trying to live in what amounts to a toxic wasteland. Users like us are done with the whole concept and as such I assume if CSS analytics becomes popular, then attempts will be made to bypass that too.
- account-5 3y agoMakes me reminiscent of uMatrix which could block the loading of CSS too.
- momentary 3y agoIs uMatrix not in vogue any more? It's still my go to tool!
- account-5 3y agoIt's not actively developed anymore so I've been using ublocks advanced options which are good but not as good as uMatrix was.
- its-summertime 3y ago||somesite.example^$css would work in ublock
- account-5 3y agoI didn't know this. But with uMatrix you could default to all websites and then whitelist those you wanted it for. At least that's the way I used it and uBlock advanced user features.
- berkes 3y agoWhy? I manually unblocked Piwik/Matomo, Plausible and and Fathom from ublock. I don't see any harm in what and how these track. And they do give the people behind the site valuable information "to improve the service". e.g. Plausible collects less information on me than the common nginx or Apache logs do. For me, as blogger, it's important to see when a post gets on HN, is linked from somewhere and what kinds of content are valued and which are ignored. So that I can blog about stuff you actually want to read and spread it through channels so that you are actually aware of it.
- morelisp 3y agoYou're just saying a smaller-scale version of "as a publisher it's important for me to collect data on my audience to optimize my advertising revenue." The adtech companies take the shit for being the visible 10% but publishers are consistently the ones pressuring for more collection.
- ordersofmag 3y agoI'm a website 'publisher' for a non-profit that has zero advertising on our site. Our entire purpose for collecting analytics is to make the site work better for our users. Really. Folks like us may not be in the majority but it's worth keeping in mind that "analytics = ad revenue optimization" is over-generalizing.
- morelisp 3y agoI'm sure your stated 13 years of data is absolutely critical to optimize your page load times.
- ordersofmag 3y agoOf course analytics from 13 years ago doesn't help us optimize page load times. But it is extremely useful to notice that content that has gotten deep use steadily for a decade suddenly doesn't. Then you know to take a closer look at the specific content. Perhaps you see that the external resource that it depended on went offline and so you can fix it. Or perhaps you realize that you need to reprioritize navigation features on the site so that folks can better find the stuff they are digging for which should no longer include that resource. We have users that engage over decades and content use patterns that play out over years (not months). And understanding those things informs changes we make to our site that make it better for users. Perhaps this is outside your world of experience, but that doesn't mean it isn't true. And we also gather data to help optimize page load times.....
- majewsky 3y agoCan you give some examples of changes that you made specifically to make the site work better for users, and how those were guided by analytics? I usually just do user interviews because building analytics feels like summoning a compliance nightmare for little actual impact.
- marban 3y agoPlausible still works if you reverse-proxy the script and the event url through your own /randompath.
- chrismorgan 3y agoThis approach is no harder to block than the JavaScript approaches: you’re just blocking requests to certain URL patterns.
- nannal 3y agoThat approach would work until analytics gets mixed in with actual styles and then you're trying to use a website without CSS.
- chrismorgan 3y agoYou’re blocking the image, not the CSS. Here’s a rule to catch it at present: ||bearblog.dev/hit/ This is the shortest it can be written with certainty of no false positives, but you can do things like making the URL pattern more specific (e.g. /hit/*/) or adding the image option (append $image) or just removing the ||bearblog.dev domain filter if it spread to other domains as well (there probably aren’t enough false positives to worry about). I find it also worth noting that all of these techniques are pretty easily circumventable by technical means, by blending content and tracking/ads/whatever. In case of all-out war, content blockers will lose. It’s just that no one has seen fit to escalate that far (and in some cases there are legal limitations, potentially on both sides of the fight).
- macNchz 3y ago> In case of all-out war, content blockers will lose. It’s just that no one has seen fit to escalate that far (and in some cases there are legal limitations, potentially on both sides of the fight). The Chrome Manifest v3 and Web Environment Integrity proposals are arguably some of the clearest steps in that direction, a long term strategy being slow-played to limit pushback.
- ben_w 3y agoThe bit of the web that feels to me like a toxic wasteland is all the adverts; the tracking is a much more subtle issue, where the damage is the long-term potential of having a digital twin that can be experimented on to find how best to manipulate me. I'm not sure how many people actually fear that. Might get responses from "yes, and it's creepy" to "don't be daft that's just SciFi".
- input_sh 3y agoNothing's gonna block your webserver's access.log fed into an analytics service. If anything, you're gonna get numbers that are inflated because it's a bit impossible to dismiss all of the bot traffic just by looking at user agents.