Turning Advertising On Its Head: Dynamically Load The Content
Believe it or not, ad blockers actually work via an extremely simple mechanism.
- A website publisher who wishes to monetize her site puts script tags (or iframes) into her web page where she wishes ads to appear.
- When a user loads the web page, those script tags fire off requests to various ad servers to fetch a display ad.
- The ad blocker looks at where those requests are going, and if they're on a community-generated filter list, it blocks them.
That's pretty much it*: every request is analyzed, and if it's target has been identified as an ad server before, the request is blocked. Despite being so simple, this approach is extremely effective, because any time an ad does sneak by, all it takes is one user to report it and it too will be added to the filter list.
That's not to say, however, that there aren't ways around ad blocking.
Because it is relatively easy for a webpage to detect if an ad blocker is installed, one relatively common solution is to show a splash page requesting that the user disable their ad blocker before allowing access any content. At a fundamental level, this "feels" fair to the publisher: quid pro quo, only customers who agree to view ads can view the site. But at a business level, I question the efficacy of this approach. Undoubtably, publishers who implement this measure see some lift in revenue, as some portion of ad-blocking customers will disable their ad blockers. But I would be interested in knowing how many impressions are being left on the table. What’s the bounce rate on that splash page? How many visitors—who in most cases also cost something to acquire—decide that the trouble of disabling ad block exceeds the benefit of viewing the content?
So what is a publisher to do?
The fundamental problem with the current content/advertisment model, which makes it so vulnerable to adblocking, is that the content comes from a different place than the advertisement.
As long as advertisements are dynamically loaded, effective adblock-blocking is not possible.
So: why not compose webpages on the server, populating ad units before returning HTML to the client?
At a basic level, this is a great idea. But it does have a few major drawbacks:
- Increased server load. Delivering static markup to thousands of requests every second is tricky as is. Dynamically retrieving ad units from 3rd party servers and rendering them server-side before serving them as HTML would be a computational nightmare: by handling all of those requests and renders themselves, instead of amortizing them amongst all of their site visitors, publishers are inviting all kinds of trouble.
- Security. If a malicious advertisement runs code on a client machine, it takes out a single machine, and even that damage is usually contained to the browser. If malicious code is run on a server, it could bring down the website for everybody.
- Tracking, targeting, and retargeting. Modern display advertisements don’t work the same as newspaper or TV ads: as an internet user, you’ve surely noticed advertisements that uncannily reflect your preferences, predilections, recent searches, and online activity. This is because advertising networks collect and store data about users so that they can deliver the most targeted ads possible, maximizing their revenue.
So, at a not-so-basic level, this idea doesn’t really work. The display advertising industry is too mature to revert back to a server-rendered state.
Let’s try another thought experiment. What would it look like if instead of dynamically rendering the ads, we dynamically rendered the content?
“Wait,” you ask, “what does that even mean, and how does it get around the security, tracking, and targeting concerns?”
Imagine a service where instead of the client requesting a website directly from the publisher, it instead requests the website directly from the advertising network. The advertising network partners with a publisher, who gives them endpoints for requesting specific content.
Fully in control of its advertising inventory, the advertising network can return the website, ads and content-requesting script tags in place, to the client. Then, the client requests the content, which is dynamically loaded onto the page.
By making the content dependent on the ad-carrying webpage, instead of the other way around, this service is effectively impervious to the ad blockers we see today. Furthermore, because website visitors are communicating with the advertising networks directly, they can still store user data, and return tracking cookies.
Clearly, there are still some kinks to be worked out. For one, the publisher is relinquishing control of their website, and routing all requests to a third-party. But perhaps this isn’t so bad: after all, relinquishing control of the server does not necessarily mean relinquishing creative control. Indeed, the display advertisement industry has become standardized enough that there are really only a handful of page shapes (various permutations of sidebars, headers, footers, interstitials), and a publisher can still load whatever markup and stylesheets they want into the page to make it look as they please.
This also shifts all hosting costs onto the advertising network. While unorthodox, this also is not necessarily a bad thing: marginal costs can simply be taken out of the monthly checks cut to publishers for ads shown. Furthermore, this shifts the onus of showing quality ads and attacking click fraud onto the advertising network instead of the publisher, which is perhaps a better alignment of incentives than the current state of the industry. Publishers will own their own tracking scripts into the page, to ensure they're actually being compensated when ads are shown alongside their content.
Probably the biggest drawback, though, is that content becomes a second-class citizen: it is only loaded after ad markup is loaded and rendered. On desktops, this may not be such a big deal (though even sub-second delays can have significant impacts on bounce rates). But on mobile—the dominant medium for content consumption today—these performance dings start to add up.
I don't have a solution for mobile, but my gut tells me that's going to require another solution entirely. And certainly, there's work to be done. Would a publisher ever willingly route all their traffic to a third party? I don't know. But sitting by idly and watching ad blockers obviate online publishing is probably not the best option—something needs to give.
*Clearly, this is an oversimplification. Many ad blockers also have "cosmetic filters", which selectively hide elements from the DOM once they've been loaded. Oftentimes, though, these cosmetic filters are only applied to websites that render advertisements on the server (which usually means they are an advertising platform in themselves), such as Facebook or Google. Most ad blockers don't apply many cosmetic filters, if any at all, to online publishers who rely on third-party ad networks for monetization.