Recently I was speaking with a friend who’s heading up a new digital publishing organization that’s taking their sales in-house, and they’re shopping for all the usual trappings of ad technology, as well as standing up an Ad Ops team from scratch.
At first I thought, “good luck with that!”, but then after some more serious thought, it occurred to me what a unique opportunity he had to build a world class organization. After all, so many organizations started their Ops teams so long ago, and have entrenched platforms, and business lines to support that they probably wouldn’t work with today if they didn’t have to.
Starting a new team in this day in age still has all the downsides of inexperience, but all the benefits of learning from everyone else’s mistakes. After all, how many of us in the Ops community haven’t thought at one time or another, “if I could just blow it all away and start from scratch…”, oh how we’d do things differently.
It got me thinking – what would the best Ad Ops team in the world look like?
Has Unrelenting Discipline
The best ad ops team in the world is, if nothing else, incredibly well organized and highly disciplined in everything they do. Don’t think that discipline and organization are the same, or that one is enough without the other. What I mean by organization is that there is an established system that creates a consistent process which defines how work is done, and what I mean by discipline is that everyone on the team religiously follows that process. Consider your favorite restaurant as a metaphor for this practice – the ones that are most successful often don’t have the best food, they have good food very consistently. It’s the consistency of behavior that’s often more valuable that anything else, and in Ad Ops I tend to think it’s especially true. The best Ad Ops team wouldn’t try to make mistakes, but they wouldn’t freak out about it, either. Rather, they’d try to design a process to identify when mistakes happen, and a regular practice of correcting them.
How you find and instill discipline in your Ad Ops organization is, in my opinion, the primary job of the head of Ad Ops at any organization, and it’s a damn difficult thing. You want the error-checking process to be simple enough that anyone can do it, fast enough to complete that it can be done frequently and catch problems quickly, yet comprehensive enough that it finds as broad an array of potential problems as possible.
When I was making my first hire ever, my boss’s boss gave me some advice – he said, “hire anyone that put themselves through school or is ex-military; I guarantee they’re the hardest working people you can find.” And while I’m not sure those folks have a total monopoly on strong work ethic, I think it remains solid advice because people with that kind of background are adaptable and know how to grind. I’ve also found that anyone who was in the military before they made it to Ops is as close to a sure thing as you can get. The former is usually easy to figure out in an interview, the other less so, but they are both excellent predictors of an Ad Ops Samurai, and it’s because they have a sense of discipline ingrained within them.
I think it’s worth hiring two kinds of people for Ad Ops, no experience but high horsepower, or industry ninjas. The former are fundamentally curious, hardworking people who can learn anything but don’t know an ad server from a data management platform, and the latter are just the high horsepower folks with a few years in the trenches, the rockstars of their teams. I interview each type of person in completely different ways – if you don’t have any industry experience, I’ll ask very little about the industry beyond verifying a base level of understanding of what the company does and what the candidate finds appealing about the job. If you’re an experienced hire though, I’ll ask much more detailed questions about what you did, how you did it and why, specific to the gory details of ad operations.
Has an Organized Ad Server Implementation
The best ad ops team in the world has an immaculate ad server implementation which enables maximum flexibility, speed, and room for growth. This is true challenge to execute, because who knows what the next type of product will be, or what the next integration will require. I could write a few standalone posts on how to implement an ad server, but I’ve listed a few high level best practices below.
Hierarchy in Everything
A pillar of ad ops management is the use of a hierarchy system in the ad server implementation, both for vertical products as well as horizontal products. What I mean by vertical products is the contextual parent-child structure that’s typically network > site > section > subsection where a specific section is parent to one or more subsections, a site is parent to one or more sections, and so forth. The most common error people make here is by skipping a level in their hierarchy, often unintentionally. For example, as many traditional desktop-only publishers had to evolve their business to support video and mobile channels, they neglected to create a new variable for channel, and instead created new sites for each channel / site combination, thereby breaking their pattern. Most of the time, this feels like a shortcut; instead of having to add both a site variable and a channel variable, Ops can just add a unique site variable.
In my opinion though, this is laziness cloaked in efficiency and a shortsighted approach, as it certainly makes downstream reporting more difficult, but also sets a dangerous precedent for sloppiness. Why not create a new site for app vs. web? Why not create a new site for set top video vs. web video vs. mobile video? It sounds sensible now, but it will quickly create a confounding mess in your targeting trees. Similarly, you may not think you’ll ever want to run a campaign across multiple channels now, but who knows – maybe that will be standard practice in two years. If you fragment what should be a single variable into multiple variables today, you build in future barriers for yourself.
From a horizontal perspective, what I mean there is an audience based hierarchy, or taxonomy if you like. Hopefully you can simply replicate the taxonomy in place in your DMP (you should, anyways) so that you maintain a similar parent-child relationship. For example, one common structure is audience > demo > gender. In this case, another reason why you’d want each type of targeting to roll up to a single variable a the end of the day is so you can exclude users who have any audience variable if necessary, perhaps for reporting reasons, or so that you have separately target
Variables Don’t Mix
Another common mistake that the best ad ops team in the world would never make is to use one variable for more than one value. This happens all the time, usually when an existing variable has to get split into more than one (for example, when the 728×90 unit used to be a simple desktop concept, but is now an element that is managed specific to desktop and tablet environments), or as Ad Ops teams struggle to figure out how to onboard a new paradigm of variables (for example, when they launch a DMP). One place where you’ll see mixed variables quite a lot is with header bidding implementations, especially on publishers who use single request architecture (SRA).
Best in class Ops teams bite the bullet on things like this and don’t simply add “728×90 – tablet” as a new value in addition to “728×90” in the size or position variable. If they did that, they’d now have to remember that ‘728×90’ is specific to desktop. The right thing to do is to create a new variable called ‘channel’ (with possible values like ‘tablet’, ‘desktop’, ‘smartphone’), and maintain the ‘728×90’ value as an independent and potentially valid value across all channels.
Yes – two variables for two concepts:
"Channel = Tablet; Size = 728x90"
No – one variable for two concepts:
"Size = 728x90_Tablet"
On the other side, you can just as easily make your life complex if you use more variables than you need. Specifically within DMP-related variables, many Ops teams make the mistake of using multiple variables for something that only needs to be one. For instance, they use different values for audience types, like gender vs. household income vs. child in household status. The better way to approach this though is to simply combine multiple values in the same variable together with an “OR” statement, or a “union” expression for all you fancy SQL people out there.
Yes – one variable with multiple values of the same concept:
"Audience = age:25-54, hhi:$100K, child:yes"
No – multiple variables with a single value within the same concept:
"Age = 25-54; HHI = $100K; Child = Yes"
Enforces an Ad Spec & Tag Validation
I’ve written about what an ad spec is and how to create one in the past, and I’ll admit it’s not a glamorous task. Most people when they think of updating their ad spec probably visualize themselves as Indiana Jones, blowing sand and cobwebs off an ancient text carved into stone long ago when the world was different. That’s just the issue though, too many people have an ad spec and then never enforce it – and if you never enforce the spec it serves no purpose and you’re right to think it’s a waste of time. If you’re a publisher that has no intention of pushing back on a customer for a completely obnoxious and irresponsible tag, then by all means, get rid of your spec and stop wasting Ops’s time!
For everyone else out there, though, consider why you have this document in the first place; an ad spec is supposed to technically outline your creative policies, which you’ve predetermined as a middle ground between your users and your advertising customers.
You spec should look to cover a good deal of ground, especially in these modern times we live in. You’ll want to have dedicated sections for mobile, video, and display. You’ll want to identify the vendors you accept and those you do not accept. Which sizes you take and do not take. Try to answer common questions as well – if your video spec says creative must not exceed 30 seconds, do you really mean 32 seconds, or will you send back a creative that’s 31 seconds to the agency?
When it comes to tags you can never be too careful – Ad Ops is often the last line of defense when it comes to blocking nefarious ads from going up that secretly contain malware. Even more benign dangers like data collection pixels, or ad blocking technology should be vetted.
I know what you’re thinking – who on earth has time to validate tags against an ad spec? Not many, which is why almost everyone uses some kind of technology solution to do the work for them. The Media Trust, AdValidation, and others offer products in this space, and they’re all pretty cheap.
Has Thorough, Updated Documentation
Ad Ops is 50% industry knowledge, 50% company knowledge. You can expect your ad server and other technology platforms to give you the basics as to how their platform works, but you can’t very well expect them to explain how it works in the context of your organization, or explain how campaigns should be named, or explain what the QA process and checklist should be. This is the point of internal documentation, to cover the nuances of internal company context, not re-write DFP’s Help section. The best ad ops teams don’t store implementation procedures as tribal knowledge or oral history, they put pen to paper and explain how it works in plain English so that any user on the team can get a campaign up and running in a pinch. Better yet, they have a searchable wiki like Confluence to host information make it easy for the team to update.
Solid documentation contains step-by-step procedures, screenshots with visual cues, and an example campaign in the ad server which can be referenced for the finer details. Good documentation is also as much what to do as what not to do – it calls out the most common errors users make.
While it can be painful, documentation has to be maintained, which is admittedly a thankless task. Clever teams know it’s an ideal task to do when a new hire comes on board because it lets you use a set of fresh eyes that knows little to nothing about your business. Since a new hire has zero preconceived notions of how things should work, they serve as an ideal guinea pig to validate that things are in fact, idiot proof. The test, naturally, is can your new hire effectively train themselves with your current documentation? Think of it not as a tough-love approach to on-boarding new hires, but as the new hire’s first important responsibility. As they go through the process and follow your step-by-step processes and procedures, they’ll be unknowledgeable enough to show you where your documentation has gaps, or is confusing. And, by reviewing their work, and explaining their mistakes, they can apply their notes to upgrading the tutorials.