Nieman Foundation at Harvard
Daring Fireball’s John Gruber linked yesterday to a Sports Illustrated slideshow of baseball photos taken with the new iPhone 6s Plus. But he noted a technical problem:
In a small dose of irony, I had to disable content-blocking (long press the reload button in Mobile Safari’s location field) to get SI’s image gallery dingus to work.
In other words, the adblocking software Gruber has installed on his iPhone was also blocking the content.
Now, if a publisher chooses to do that — to block access to its content to those using adblockers — that’s its prerogative! It might be a smart choice that leads to whitelisting, or at least plants a few guilty feelings. Or it might just lead people to be angry with no positive outcomes! We’ll see.
My point here is that it should be a conscious choice, not the result of bad code.
@jbenton One of the few things most should be able to agree on is if a site doesn't work because of a JS error, that's on the site to fix.
— justen fox (@oiler) September 22, 2015
@jbenton Looks like NewRelic is throwing the JS error here, which is causing the slideshow JS to not work.
— justen fox (@oiler) September 22, 2015
@jbenton Click action is only sending reporting data to NR. Slideshow throws JS errors if DFP isn't loaded. Is either bad JS or purposeful.
— justen fox (@oiler) September 22, 2015
(Justen Fox is a senior product manager at Vox Media. Acronym decoder: JS = JavaScript, DFP = Google’s ad platform DoubleClick for Publishers, NR = analytics platform New Relic. From a little Ghostery fiddling, it looks like it’s blocking DoubleClick that breaks the slideshow. I’ve also seen some wonky, broken behavior on some other news sites.)
Again, I’m not saying publishers shouldn’t feel free to deal with adblockers however they’d like; as an industry, it’s healthy for different publishers to respond in different ways so we can compare results. But it’s worth it to run through your site with adblockers on, desktop and mobile, just to see what that share of your audience is seeing. You need that information to make sound judgments.
2 comments:
I’d argue the opposite. If the site doesn’t work with these ad blockers, that’s not the fault of the publisher. Why should a publisher go out of their way to make it easy for a user to defraud the publisher of revenue that supports the content creation, site hosting, infrastructure, etc? It’s a pretty ridiculous proposition.
You’d be spending time fixing a site for an audience that has no value to the publisher – only additional cost in the form of CDN & infrastructure.
Focus on the users that value your content enough to either pay for it, or trade ads for free access.
From a pure web design perspective, yes, of course: As a competent web dev, we all want our sites to be as bulletproof and as fault-resistant as possible. But uBlock and Ghostery and Crystal and all the rest are pulling out little, tiny, regEx’d chunks of our sites, and while it’s easy to be deeply sympathetic with the privacy and bandwidth concerns that lead people to those choices, it’s not clear when you’re whitelisting and blacklisting arbitrary aspects of other people’s code (and how that code responds to other other people’s code, on other servers!) there can be a reasonable expectation of 100% functionality.
Trackbacks:
Leave a comment