51–60 of 242 posts
Earlier quoted context omitted.
page load times go up
Unless you’re doing something silly a button can’t be more than a hundred bytes or so. That’s only significant on a 90s era cell phone. Then again most browsers have a print button.
If you want to read the data behind many of the decisions, read these papers [0].
This test compares: 1. Number of visitors as recorded in Google Analytics 2. Number of loads of a 1x1 pixel served on a different domain They see higher numbers for (2) than (1), and attribute the difference to users blocking Google Analytics. I don't see them describing how they excluded bot traffic, however, and for my sites the majority of hits I get are from bots. Only some bots run JS, so I suspect their numbers…
One of the corollaries to this is that if you are basing your decisions on analytics, you are probably under-representing people who block them, who often tend to be a non-representative subset of your users. I have seen multiple projects do things like stop supporting features that their analytics “showed nobody was using” but failed to realize that a significant portion of their (often technical and very vocal) use…
War story: we turned off the “print” button on MSN because it was unused. Users in Japan complained - they were printing articles to read on the train. Turned it back on in that geo
This test compares: 1. Number of visitors as recorded in Google Analytics 2. Number of loads of a 1x1 pixel served on a different domain They see higher numbers for (2) than (1), and attribute the difference to users blocking Google Analytics. I don't see them describing how they excluded bot traffic, however, and for my sites the majority of hits I get are from bots. Only some bots run JS, so I suspect their numbers…
The author extracted the browser information from the server logs (presumably from the User-Agent header i guess?). If they were able to do this, i'd assume they also filtered out bots from the tally :)
One of the corollaries to this is that if you are basing your decisions on analytics, you are probably under-representing people who block them, who often tend to be a non-representative subset of your users. I have seen multiple projects do things like stop supporting features that their analytics “showed nobody was using” but failed to realize that a significant portion of their (often technical and very vocal) use…
A/B testing is where beloved products go to die. You can't just follow analytics. You have to understand your users.
I can't believe how ignorant people that say "use server logs" are. They clearly haven't done any online marketing or run an online business, yet they want better and cheaper products - even free if possible.
How do you think a company gets to improve and optimize their product? By surveys? I think many assume the entire analytics required for a business is just reading a few GET requests from the server logs and categorizing them by user agent.
Earlier quoted context omitted.
Just ask people!
How? In surveys? No one does those. Plus, people often don't give valuable feedback when asked questions about features they want and use... people are poor judges of what they actually want, and will list things they think they care about and then end up never using or which don't affect their choices.
We do. We have real customers do real surveys of our real web sites. In person. We even do shadowing to see how real people use our sites in their daily work.
It's uncommon in SV due to laziness and an unwillingness to talk to actual human beings. Which is dumb because there are companies that will handle this for you.
But SV is stuck in this mindset that everything can be solved by an algorithm. It can't. The tech echo chamber really needs to get over itself.
Earlier quoted context omitted.
Server-side analytics will tell you in most cases, and if they don’t, they’re easy to add in a way that makes them unlikely to be blocked?
Server side analytics are overwhelmed by bots and crawlers and other non humans in my experience
If you're running anything with an API, then unless somethings horribly wrong it's even easier: look at the number of requests being made to an API endpoint and spot check a few of the user identifiers (tokens, keys, whatever you're using) to see the variety of users.
All of this is assuming you're trying to merely investigate the volume of use of a feature, not trying to diagnose demographics. If you're trying to extract more fine-grained detail, I don't have as many answers; I hope others will chime in with constructive ways to get things like geographic demographics via server logs.