Comment by downandout | Hacker News Reader

Comment by downandout | Hacker News Reader

I have never understood this issue. Companies that are supposedly losing millions, and in some cases billions of dollars to ad blockers can't figure out how to randomize ad sizes, links, div names, etc with each page load to the point where it would be impossible for an ad-blocker to deal with it? No footprint, no blocking. It really is that simple.

The issue is more difficult with ad networks, since they always point to specific domains and run specific bits of javascript. But it seems to me that ad networks could simply offer a PHP et al script that publishers could locally host and include in their content that would basically proxy the connection between the user and the ad network. Clickthrough URL's would appear to be on the originating site, like any other content on the site, and the script would forward them to the appropriate site.

I have given this all of ten minutes of thought, and I'm on my way to a solution. I don't buy that companies with real money on the line can't solve this issue.

Most companies don't serve their own ads. They sell an iframe reference in a particular kind of page to someone else who runs their own adserver software, so there's a detectable footprint for organisational reasons.

Quite often there's more than one level of resale; I've seen five and a friend who works in the business told me he's seen even more.

(Digression: I have also heard that Ghostery (.com) makes most of its money by telling companies what ads are on their web pages.)

I understand the iframe/network issue, which is why suggested a downloadable script that publishers could host that would grab the ad server-side, reference it as a a locally-hosted image or include the text of a text ad in the native content of the page, and send all links to a local redirect script. It wouldn't be that much more difficult for a publisher to roll such a thing out than it is for them to add the iframes or javascript they use today.

That approach would be slower (oddly enough the ad people seem to care about performance) and worse, the ad server loses its cookies. When it's on its own domain it can use cookies and track people across web sites.

The alternative is that their ads don't get shown, so would you prefer worse or nothing at all?

By not using that possible proxy, they give adblockers something to work with, but they also increase the price of the ads they can sell for the rest of the audience.

I wouldn't be surprised if a lot of the recent squealing is really a sanitised form of "the loss from the adblockers has grown bigger than the gains from the increased ad prices, but noone understands our webapp tomcat CRM monster well enough to adapt."

Yes this is a major problem. Early in the life of a lot of websites you'll see user complaining about the use of auto-playing audio ads, or stupidly laggy flash video ads.

When the administrator has no clue whats being shown on their webpage. That in and of itself is a huge issue that ad companies are non-to-eager to address.

That's downandout's point. Don't use that method...use a proxy so it appears that the content (ads) come from the company's website.

If a PHP snippet is used and the connection is proxied through the server how does the ad network guarantee the server actually includes that ad with the response?

As I said, I have given this 10 minutes of thought. Obviously if someone is getting paid per click, they are a) going to display the ad and b) they will only get paid when a user clicks through, and of course once the user has been redirected to the network's servers, they can do all the tracking things they normally do. This model probably wouldn't work for publishers that are paid purely on CPM's (though there may be a solution that I'm not thinking of at 6am).

Randomizing sites is probably going to give way to delivery of content & ads through HTML DRM IMO via EME.

Reply on news.ycombinator.com