Do you have a contingency plan if your script/domains start getting blocked by the very AdBlockers they're trying to track? For example, Google Analytics is already blocked by a number of plugins (Ghostery, uBlock, Disconnect, etc.)
I hope that doesn't happen because Adblock Analytics is 100% cookieless and doesn't track visitors via any method, we're only interested if ads were displayed or not, but we do have some ideas if it does happen.
They seem to only be collecting screen resolution, viewport size and whether ads are showing client side (tested by trying to load a file called ads.js that inserts a div into the dom). I assume server-side they combine this with user agent string and ip address.
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.
You are correct - no cookies or any visitor tracking is being used. We only track if the display of an ad is possible. And thanks for reminding me of the screen & window JavaScript variables. They aren't being used at all.
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.
We have no interest in tracking anyone and can't given our implementation. If you checkout our sample report (which is the same one that clients receive) all of the data is highly aggregated:
Purely out of curiosity, why are you opposed to websites knowing how many of their visitors are blocking ads? I get that you're against being tracked, but if they can't find out how their revenue is being affected, then how can they decide if a change in revenue source is necessary?
It is a form of tracking. You're tracking if the user has adblock installed. Many people install adblockers for privacy do because they don't like being a part of data that will never be used in their best interest.
We're checking if the display of an ad is possible, but the only reason we're doing this is to inform the website owner of how ad blocking is affecting them. Once they have this information, a lot of good can come from it that would benefit all of that websites visitors.
You say a lot of good would come but I think it would just make them more likely to use aggressive adblock countermeasures so deflating their numbers is probably more in line with the best interest of adblock users.
The only solace I have that the only data the webserver will have is activity on that one server rather than all of my activity aggregated and analyzed by google or microsoft.
> if they can't find out how their revenue is being affected,
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...
Truly appreciate your thoughtful response - thank you! I don't believe ad blockers are going away nor do I think it's time well spent or an effective strategy asking visitors to disable them or try to sneak ads past them. What I do believe though is once decision makers within these companies learn the % of their visitors that are blocking ads it will spur a productive discussion on what they should do about it - such as a shift in revenue strategy as you suggested.
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.
I'm the creator of Adblock Analytics and the reason I built it is because a lot of websites seem to be struggling with determining how many of their visitors are blocking ads. I'll be around to answer any questions that might pop up and would love to receive feedback - good, bad or otherwise. Thank you!!
Many site stakeholders don't realize that they have choices. They can:
1) Choose to show only non-offensive ads.
2) Prompt users to whitelist their site.
You are in a good position to inform them of this. Please do.
Thanks for posting! Would you like to talk a bit about the tech stack, biggest challenge in building frontend/backend, any marketing so far, any traction?
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.
Your tool is actively trying to determine what I user does with the page after it's served -- that's tracking. Yes, this behavior is commonplace in the industry but it doesn't mean you wont end up on blocklists because of it.
Given that pagefair does this for free and already has whitelisting agreements with adblock lists, I think your pricing is too high. The only differences I see at a glance are that you break it down into per-device stats and have a tabular view.
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.
From what I understand, PageFair is also running an advertising network to cover their costs and that's why they need to be whitelisted. Our solution doesn't display any ads or messages to the visitors of websites which use our service. I've heard their reporting is very basic compared to ours, but would love for someone to do a thorough review. We also offer an API.
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!
Off topic: What server-side Node/Express middleware would you recommend to perform analytics (now that client JavaScript-based analytics is no longer reliable)?
Personally, I think the pricing is way too high for what you're providing.
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.
We spent a lot of time discussing pricing and so far it's seemed reasonable, but your feedback has been noted. Definitely true that someone with the right skills, time & resources could leverage existing APIs or build a similar service.
