
On ad-supported websites from a developer’s perspective - awwstn
https://medium.com/thoughts-on-media/how-ad-supported-websites-really-work-4bf3efb83fdd
======
armandososa
I worked for 4+ years at a company that was supposed to help publisher create
enjoyable reading experiences on touch devices. We could have succeed doing
that, except no publisher is interested in their reader's experience these
days.

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.

------
reilly3000
The sanest way to manage tags is really quite simple: use google tag manager
or Opentag from Qubit. Give any third party partner the ability to write tags
and rules. Do NOT give them Deploy access. Then the dev team gets to use the
sandbox debugger to test and profile, and then publish. Because GTM has
immutable snapshots of config, rollback is painless.

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?

------
TeMPOraL
So the article first describes where a developer in a media company sits
inside the pipeline, then goes to describing politely and in a lot of
corporate speak how media companies build advanced equipment for managing the
radioactive waste they later unleash on users, and then concludes by noting
that the websites would be _much_ better if someone was to keep those pesky
marketers from touching the code.

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.

~~~
bcoates
The author's right, though, in that this is the competitive advantage 800lb
gorilla aggregators bring to the table. When some clueless manager demands
Facebook include some tracker as part of an ad buy, Facebook's answer is "no,
take it or leave it", and after a few rounds of increasingly petulant emails
with FB's bottom tier support staff, he relents, because he never really had
the option of not buying Facebook ads in the first place and he was just
posturing.

At most media companies without the market power or willingness to use the
power they have, the request would reach his counterpart on the sell side and
they'd be off to the races out-stupiding each other against the mutual
interest of their host companies.

------
bostik
The seeds of planned dissatisfaction are planted early. It goes from best
interests...

> _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.

------
Falkon1313
> "unnecessary overlapping functionality"

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.

------
rememberlenny
I'm the author of this and only noticed this post through the Medium referral
traffic.

Thanks for reading!

