On ad-supported websites from a developer’s perspective

A big part of my job was making sure IAB standard ad tech worked on our platform, and it was always a losing battle. Advertisers don't care about making the readers' experiences the worst it can be, as long as they click on those goddamn ads. As an UX designer, that's the worst of nightmares.

Now, I don't want to work on anything that it's ad supported ever again in my life.

We were working with an agency serving a large software company in the Seattle area. They have a site dedicated to competing with other companies that make productivity software, among those a company that also has a search engine. We outlined the above workflow and successfully deployed Google Tag Manager on the site in what may be my career's biggest -#ironywin to date.

Marketers have highly complex rules for when customer events turn into when tags should fire. This is best left to them as rules and platforms are always in flux. We even sometimes use GTM variables to split test tags from different inventory sources.

I would love the future to allow for tag management to be done on a seperate web server that uses a single proxy tag that sends event streams to a service that routes the event data to all 3 party tracking. No document writes, one tag to load. Anybody know if that is or isn't possible?

And I totally buy the last point. The flip side of designing systems allowing managers and sales to add scripts optimizing "company specific performance indicators" is that they will add those scripts, which ends up in a lot of problems for the website. This stuff should be managed by developers, but it's hard - if your boss buys Ad Optimizer X, and the Ad Optimizer X comes only packaged with Tracker X, you will have no choice but to add it anyway.

I've been in that boat (and fortunately managed to abandon ship). The boss comes and says "just add this tracker code to the project". Oh, so he hired an external ad agency and set up a whole large plan, and the dev team gets to know about it only when they're told to start including random third-party scripts. I wish there was a way to push back, or at least to get info beforehand.

Some people actually talk about unionizing. I have mixed feelings. On the one hand, I'd love for us to have some leverage to push back against absurd or plain immoral demands of the management. On the other hand, I worry it'll pave the way to the professionalization of development - where in order to use a general-purpose compiler you'll have to have an engineering license, or something.

> Writers spend time researching stories and write on captivating topics. And editors and producers spend time preparing and shaping stories for their overall audience.

... to making sure the reader is distracted from content as much and as often as possible:

> Billable impressions require a rendered ad to be have at least 50% of the creative in-view to the user for at least 1 second.

No wonder clickbait flourishes. If the entire "content" (and I use the word here with derision) of the article can be digested instantly, larger fraction of time between page loads can be used to flood the viewer with ads.

I wish there was a proper way to boycott advertisers. Not just to block all the radioactive waste[+], but clearly state back that "due to your actions, I have made a conscious decision to avoid you and your products".

+: I picked the term from TeMPOraL's post. It's a good one.

Luckily I didn't do much work with ad-supported publishing sites, but I still experienced some of that pain. It wasn't unusual for a marketer to ask for 6 or more tracking/analytics scripts (that all claim to do the same thing). The scripts were usually archaic and baroque, and unable to handle common web patterns like Post-Redirect-Get or AJAX without worakarounds.

They usually had lots of parameters so that you could specify exactly what data you wanted when an event happened... But for marketers who didn't really know what they were looking for, and therefore couldn't specify, the results were of course insufficient. So the natural solution was to add yet another 3rd-party script that promises to do magic.

Of course, when you're talking about a database-backed web application whose very nature is to store data and do queries for reports, most of these scripts are obviously more than a little redundant. If the specs for the site included what needed to be tracked and what reports were needed, then the 3rd party scripts wouldn't be needed at all (except for the ones that track you across multiple sites or inject supercookies). But it's quicker and easier just to try adding more 3rd party snake oil.

Thanks for reading!