Uses Naming Conventions
If you want to know how organized an Ad Ops person is, ask them to describe their ad server’s product naming convention, or better yet, ask them how they’d setup yours. This is a great interview question, actually. Like a basketball player’s free-throw or a chef’s omelet, the Ad Ops professional’s naming convention is a classic measure of organizational skill. Naturally, the best ad ops team in the world uses naming conventions for everything – product names, variable names, report names, usernames, it’s the first and most visible mechanism used for organization.
Good naming conventions are slippery things because they have to strike the right balance of descriptiveness and brevity. You want them to be as intuitive as possible for an outsider to pickup, yet ultimately serve the core team’s needs above all else. That said, good naming conventions have a few standard qualities:
This one seems obvious – clearly you want to use your naming convention in a consistent manner – but what I mean on this one is that you should take pains to architect your naming convention such that each parameter is always in the same place. Meaning, if you always write your convention as Site > Section > Subsection > Size, section is the second parameter and size is the fourth parameter. What seems crazy at face value but will create a nightmare for you down the road if you don’t do it is when you build a product that doesn’t have subsection value, like the ROS Sports product, if you don’t keep the size variable as the fourth item.
For example, you might have Site A > Sports > Baseball > 728×90, but be tempted to write your ROS Sports product as Site A > Sports > 728×90 when what you should actually do is write it as Site A > Sports > > 728×90. The latter option seems messier than the former option because it has that additional delimiter value, but the reason it makes sense to write it that way is so that if you need to use the text-to-columns feature in Excel to break that product into it’s underlying pieces, you won’t have the same parameter in many different columns. Do it the wrong way and every time you want to leverage the naming convention in reports, you’ll have to scrub your dataset, which is prone to errors.
Written in Plain English
This one might be up for debate, but I’m not a fan of the coded naming convention. If the audience value you want to target is ‘business travelers’ name your parameters and products ‘business travelers’ not ‘segment 507281’. I prefer to label things in an intuitive manner, and I’ll accept longer and in some cases, more cumbersome names as the tradeoff so my team doesn’t have to internalize a bunch of arbitrary data. The thing is, most of the time you need your naming convention to help you locate the right product through search, or to help you build a report that you’re distributing to a business stakeholder. In either case, a coded naming convention serves you no good and makes it more difficult to change your setup down the road and creates training barriers for new hires.
This means the order of elements in your name should move from broadest to the most specific. Do region > country > state > city > zip, not country > region > zip > city > state.
Use a common delimiter character, like a carat (^) or underscore (_) that won’t appear in regular language so that you can use the text-to-columns feature in Excel on report data and build more powerful pivot table reports.
Below are a few specific naming conventions you could use as a best practice:
Takes Out the Trash
Perhaps the ultimate sign of discipline is carrying out the practice of garbage collection, and it’s the thing absolutely no one does, much to their detriment. Garbage collection is actually a computer science term, and it refers to a program that reclaims memory by eliminating objects no longer in use by the system, or which cannot be accessed for future use. The reason garbage collection was invented was to prevent the system from grinding to a halt because of a lack of resources, since over time, all memory is consumed by the objects created in prior jobs. The same idea applies to your ad server setup getting cluttered with irrelevant and legacy attributes, your DMP overflowing with useless audiences, or your reporting system with innumerable reports that no one ever accesses but you still have to search through to get to what you actually need.
Ad Ops teams are the ultimate offenders of a messy digital workspace; they’re digital hoarders of information and end up creating a byzantine maze of crap only they know how to navigate, and even then with some difficulty. The biggest thing missing in Ad Ops teams today is an organized process to delete superfluous and irrelevant elements from their platforms. The best ad ops teams don’t have an audience in their DMP tracking a microsite for a campaign that ran two years ago, they don’t have a tree of ad units in their ad server that were removed from pages in 2008, and they don’t keep the saved ad hoc reports for the finance manager that left nine months ago ‘just in case’. They have a regular process to get rid of all that stuff! And you should, too.
On a monthly or quarterly basis, take an hour and scrub your product tree of irrelevant products; items that apply to campaign specific microsites, advertorial sections, or tent-pole events should get archived if not outright deleted. This is also a chance to catch special ad units which have expired campaigns and are now serving lots of unfilled impressions that you could monetize in another way.
Report cleanup is probably a once a year task, which makes it even easier to do. Just cover it in a team meeting by asking everyone what reports they still leverage, and archive the rest.
Has Security Processes
As a best practice, when users leave the company, they have all access from all systems rescinded, and if necessary, any shared logins and passwords within the Ops team are changed. This does not mean updating “password123” to “password 1234”, but something that’s ideally not an obvious iteration on the previous setting.
If you can, it’s just better to stay away from this altogether – handling PII is a bad idea for any department at any company unless absolutely necessary. In some cases, however, Ad Ops may need to work with PII to facilitate custom audience segments and in those cases it’s important to have a secure way to transfer the data. This is more of an issue on the buy side of advertising, where brands, retailers, and other data owners may want to create segments in tools like Facebook of specific email lists, for example, and there’s just no way to avoid it. Namely, you’ll want to get familiar with PGP Encryption, public & private keys, hash types, and other ways of eliminating or protecting the personally identifiable piece of the the PII so you can transfer files between companies in a secure manner.
This is one of the rare cases in my view where it’s a good idea to create a bottleneck and assign a specific person to the end-to-end process for each campaign so that there is a felt sense of accountability in protecting the information.
Has a Fortress Reporting Structure
The best ad ops team doesn’t report to the sales organization, it reports to the finance or technology organization; in fact I think you’d be crazy to put your Ops team under sales. What’s absolutely clear to me having worked in this industry for many years though is that Ad Ops cannot effectively do their job under the sales organization because there is an inherent conflict of interest. The sales organization at any company is unsurprisingly the most political segment of the business in my view, and it’s very difficult to align Ops to work toward the company’s best interests vs. the noisiest salesperson’s best interest.
I often feel that Ad Ops is complicit in irresponsible deals and optimizations because they are pressured by the sales organization, and are usually treated like second-class citizens by sales leadership, who understandably value the employees that close deals and help them toward quarterly quotas more than those that implement and operationalize those deals. Whether its having little to no air cover for honest implementation errors or no backing on reasonable response times for campaign setup, an Ops team under sales will burn out more quickly and have lower morale than one that sits under an independent org. It’s just the psychology of being in that department.