What if publishers served ads, not JavaScript?

From auto-play audio, to mobile redirects, to slow ads, to data leakage, to fly-ins and popovers, programmatic advertising may be burning the user experience at the stake across the Internet. It’s no coincidence that the conversation quickly shifted to ad block, which is an outgrowth of the debasement of the user experience. Could these problems be solved if publishers started serving their own ads? Is this even feasible?

In the old days, publishers served ads. A deal was cut with an advertiser. Creatives were loaded into the ad server. And voila! Ads were served on the site. But something funny happened on the way to the programmatic revolution. Publishers stopped serving ads, and started serving JavaScript. Today, in the ad server, the option to select an image ad with a custom macro for click tracking seems almost quaint, a relic of a bygone era. The transition to javascript appeared benign at first. The javascript gathered some data, requested an ad from the ad exchange, and returned an ad. Simple. Little did we all realize that the floodgates had opened.

On some sites, the JavaScript intended to load a single ad can cascade into requests for more than 50 files: data trackers, metrics beacons, page analyzers, viewability auditors, and the ad itself all come through the JavaScript. More broadly, the bloat in advertising may be causing the Internet in general to slow down. According to a data collected by the HTTP Archive, over the past four years, the total requests made by the top 1,000 websites has increased by more than 40 percent, averaging almost 130 requests per page.

Contrast the JavaScript-based approach against the days when a creative and a macro were inserted into the ad server. A request for a single ad returned a single file, the ad. Perhaps more importantly, in the past, publishers had oversight over what appeared on their website. No one would insert a creative that automatically redirected users to the app store. Nor would they run video that started blaring audio without the user’s permission. Publisher control over the ad represented publisher control over the user experience.

It is possible to retain the advantages of programmatic advertising — the seamless, automated buying and selling of ads on an impression by impression basis — while snuffing out the user experience problems. But it will require changes throughout the industry. The starting point is the ad server, which must evolve from a trafficking tool into a server-side RTB platform. The ad server must provide reliable, independently verifiable, impression and viewability analytics, so that advertisers will not have to load a fleet of tracking pixels. Publishers will also need to plug in these RTB servers to a marketplace for DSPs to buy traffic across the industry. Finally, the approach to RTB needs to be updated, so that what is exchanged is not JavaScript, but ads. Real ads.

And here’s the kicker: If publishers self-hosted these ad servers that produce a better user experience, it could lead to a breakthrough in the problem of ad blocking. Ads that are served from the publishers are far more difficult for ad blockers to target. The end of the serving JavaScript represents the beginning of a new era in user experience. One request, one ad. That’s the key to ending the user experience fire, and in turn, adding fuel to the revenue growth fire.