Show HN: Adblock Analytics
adblockanalytics.com
adblockanalytics.com
[edit: clarified that this is a solution, I have no knowledge as to whether that is what is done.]
The only way is to have the complete tracking implementation on your server.
https://www.adblockanalytics.com/ads.js:
var d = document.createElement("div");
d.id='abaA';
d.style.display='none';
document.body.appendChild(d);
var abaA;
if(!document.getElementById('abaA')) {
abaA = 'N';
} else {
abaA = 'Y';
}
https://www.adblockanalytics.com/analyze.js:
var r = new XMLHttpRequest();
r.open("POST","https://www.adblockanalytics.com/analyze/");
r.setRequestHeader("Content-type","application/x-www-form-urlencoded");
r.send("abaI="+abaI+"&abaA="+abaA+"&abaSw="+screen.width+"&abaSh="+screen.height+"&abaBw="+window.innerWidth+"&abaBh="+window.innerHeight);
Don't see any reason why an ad blocker would block them.
That's gong to cause confirmation bias.
Since you're still relying on trusting an unknown client to run your code and submit your result instead of simply parsing the server logs, you have aren't including anybody - with or without an ad blocker (either of which may include downloading ads.js straight to /dev/null) - who decides not to run that <script> tag.
> www.adblockanalytics.com/analyze/
Time to add another "IN A 0.0.0.0" record to the local resolver.
https://www.adblockanalytics.com/analyze.js
var abaA; if(!document.getElementById('abaA')){ abaA='N'; } else{ abaA='Y'; }
var r=new XMLHttpRequest(); r.open("POST","https://www.adblockanalytics.com/analyze/"); r.setRequestHeader("Content-type","application/x-www-form-urlencoded"); r.send("abaI="+abaI+"&abaA="+abaA);
uBlock, for example is not only an ad-blocker but also a privacy enhancer. Maybe some users just don't like to be tracked.
adblockanalytics.com
But basically making external calls to any outside site leaks information (metadata). Some people really don't want want to be tracked. period.
My response is also raising a question which I'd love to hear your thoughts on.
Does "being affected" mean reduced? Because they're not losing out on ad revenue they would otherwise gain. That's the piracy argument with ads: if only everyone who used our product would pay us what we want, we wouldn't be losing so much money. You can't count browsers with ad-blockers as lost revenue. (You also can't count search engines, REST and curl, etc... as lost revenue.)
> then how can they decide if a change in revenue source is necessary?
Shouldn't a change in revenue model be driven by the opportunities of a subscription (or other) model, not by issues with advertising?
It seems like you're selling a service that will make your customers unhappy about reduced revenue, which they can't do anything about. What can a customer do differently if they find 16% using ad blockers, or 34% using ad blockers? Their ad revenue is the same regardless of the percentage. Their other revenue models haven't changed. All that's changed is that now they're mad about users with ad blockers. At best, if the percentage is going to drive a decision about changing revenue models, all they really need is a single data point, not a monthly service.
> why are you opposed to websites knowing how many of their visitors are blocking ads?
Because people aren't rational. They'll get angry about a transaction cost of the advertising model, and do all the same stupid things we saw 2 or 3 years ago: rants of moral indignation, poorly implemented content blocking, big obnoxious pleas, etc...
As thomasahle pointed out earlier, ad blocking visitors seem to be more engaged because they bounce less and visit more pages. Now this is based on a relatively small sample size, but so far the trend is holding true. That is a huge takeaway that cannot be understated. Ad blocking visitors are valuable but in a slightly different sense.
And you're right, some websites will signup for a month and cancel after they've analyzed a large enough sample size and we're ok with that because it's all about education & gaining knowledge. Prior to using our service they could only guess, now they know with relative certainty.
You are in a good position to inform them of this. Please do.
There are good reasons people have to block ads.
For a site like this I would put the tracker that's being hit by sites on a different (sub-)domain, to prevent massive traffic spikes on client sites from also taking down your own homepage.
Deleted comment
So they can now track people using your website? As first comment said, good luck not getting blacklisted...
Does your javascript snippet support subresource integrity? That would be a key selling point as pagefair's CDN was hacked and their snippet replaced to do malware redirects against users. After that incident I'm keeping the number of scripts from "startups" to an absolute minimum.
The PageFair hack was very scary and a good reminder to all companies that require the use of external JavaScript by their users. We currently don't support subresource integrity, but it's now at the top of our to-do list. Thanks for the great feedback!
I'm wondering how you can differentiate visitors from page views without it.
Also, to people who think that this very JS might get blocked by ad blockers: all of the tracking and reporting could be done (server-side) with Google Analytics nonetheless by making use of the appropriate APIs.