Traditionally in web design, a browser calls a web server, which returns all the HTML necessary to render the entire page to the browser in a source code file. Now that file may contain redirects and references to other web servers that the browser has to call in order to fully render the page, but the general idea has been that browser fully loads the whole page for the user as quickly as possible. Such that, if the page is extremely long, contains lots of images, or what have you, the whole thing is rendered at once, irrespective of the user’s navigation. In other words, the browser renders everything, whether the user ever views that content or not.
“Lazy loading” (sometimes also known as “just-in-time loading” on the other hand, is a relatively new method of web design that renders the page on an as-needed basis, just as the user is scrolling their browser down to that piece of content. If you’ve seen pages that contain an “infinite scroll” design, you have the general sense. The content available to the user isn’t all loaded at once, because it would take forever; rather, the page renders as you the user scroll to it. If you don’t scroll down, the content isn’t rendered. So lazy loading any web content, ads included means the web server only provides the necessary source code to the browser as the user needs it. (more…)
While not the sexiest topic in the world, writing and maintaining an advertising specification document, or ad spec, is among the most important responsibilities of any Ad Ops team. Ad specs define the nitty gritty details for what ad formats, functionalities, and technologies a publisher can and will support as a matter of business, and help streamline communication with agencies, clients, and internal sales teams. Just as important, maintaining a detailed ad spec keeps publisher Ad Ops teams organized when it comes to campaign QA, and consistent in their communications with internal and external teams.
If you’re a large organization, a well thought out ad spec keeps your business scalable, enabling even the most junior team members to respond to detailed technical questions and requests from the sales organization, which means decision making stays fast and distributed, even at high volumes. For small organizations, thinking through ad spec requirements is practically a right of passage in becoming a serious digital publisher, a landmark task that forces your company to move from ad hoc decision making to rational business practices and policies you can use as you grow.
Who Should Write the Ad Spec?
In many cases, the ideal ad spec for the publisher at large is written with competing priorities in mind that balance the wants and needs of the sales and marketing teams with those of the engineering and development groups, not to mention what the Ad Ops team can realistically manage to support at scale. The Ad Ops team should absolutely own the ad spec document, but it’s unwise to make ad spec decisions in a vacuum, without input and advisement from outside teams. Just as it drives the Ad Ops team crazy when other departments make decisions that impact their world without having a seat at the table, Ops ignoring teams with a downstream interest in how the ads impact the site performance in general is a recipe for trouble.
The most productive approach is to define boundaries and a framework that the broad group of stakeholders can agree upon, and then let Ad Ops handle the due diligence on what ad technologies can reliably work within those limits.
Big Picture Stuff
From a technology side, I would submit you start the ad spec process by defining guidelines on latency and uptime – these metrics have the most noticeable impact on the user experience, and chances are, overall pageload time is what your web development and IT group care most about in terms of how ads affect their jobs. Latency means how long it typically takes a 3rd party technology to respond to a request, such as an ad request, and uptime means how often the technology will actually respond to request. These are metrics typically outlined in service level agreements (SLAs) in technology vendor contracts, which Ad Ops won’t get from 3rd party technologies, but can at least ask for as part of their due diligence in approving or certifying 3rd party ad servers or rich media vendors. For example, knowing if the 3rd party technology has geo-located collocation facilities, meaning their servers are physically housed in diverse locations and at the high-speed fiber optic connections of an ISP, should separate the men from the boys so to speak. Internal technology teams can not only help provide acceptable levels of performance, but can also weigh in with the right questions for Ops to ask in their evaluations.
In terms of sales and marketing, clearly outlining all the potential products, their configurations, and how they are represented in the marketplace should be the first step. What ad sizes, formats, and functionalities will customers want and expect? Going through this exercise can help compile an exhaustive list of products, which Ops can then use to define acceptable attributes like file size, expansion limits and directions for rich media units, and what types of creative is supported where, and for what platforms. This is particularly important in today’s environment, when most digital publisher not only support desktop display advertising, but mobile, video, and tablet as well. Perhaps mobile video units are only available for application takeovers, not mobile web, or maybe the file size limits for standard media are set at 40K, but interstitial units can go up to 100K. Different rules for different products not only help the sales organization move signed contracts into campaign execution quickly, they can serve as QA cheat-sheets for the Ops organization in campaign setup.
Getting In the Weeds
Once you cover off on the basics, it’s time for Ops to really dig in, and start testing various configurations to ensure the ad spec works. That means understanding how to protect against large discrepancies that can seriously effect customer invoices, discovering the outlying factors that can break ads on the site depending on specific site section code, and understanding how to keep the company’s advertising in compliance with privacy policies, and industry best practices.
Finally, Ops should keep up to date with industry trends best practices as defined by trade groups like the IAB, DMA, DAA, and NAI to keep the ad spec current. In years past, the IAB started certifying 3rd party tracking mechanisms to comply with a so-called bots & spiders list, which impacts publishers and means that non-human traffic isn’t counted in ad server reporting. More recently, trade groups have defined self-regulatory policies for transparency around user tracking, and acceptable 3rd party opt-out mechanisms. Being aware of these kinds of services and developments may or may not impact the ad spec directly, but can often inform the necessary diligence the Ad Ops group requires to approve new partners, audit existing vendors, and maintain a professional reputation in the marketplace.
Make Your Ad Spec Darwin-Friendly
Like most everything in digital advertising, change is inevitable, and the ad spec is no exception. The best Ad Ops teams think of their ad spec as a living document, and one that must regularly evolve. A few years ago, many publishers didn’t have a mobile business, and certainly didn’t have a tablet business; today however, you’ll find ad specs with detailed sections for each. Similarly, outdated information can be retired off the spec – it may have been all the rage in 1998, but who really sells the 468×60 ad format today? Publishers have to update their ad spec to conform with updates to Flash, contemplate new technologies like ad verification services, and regularly update to keep their ad specs current in the marketplace.
This is a good thing, because it pushes Ad Ops to plan for the future, and stay solution oriented. When faced with a new technology, ad format, or vendor functionality, Ops should ask how to add it to the spec rather than if it should be added. Plan a semi-annual review at minimum of your ad spec, and even better, quarterly review with internal stakeholders. In many cases your Ops team might find that they need to involve other teams to update the ad spec. For example, to enable mobile rich media units, Ops may need to work with IT to update the application code with an SDK, and partner with IT to ensure that the technology functions correctly before rolling out the update. Sales may have feedback that customers are increasingly asking for new creative sizes. Things are constantly in flux, so regular reviews of the ad spec can help keep Ops on the overall company’s roadmap, both on the technology side and product side.
Ad Specs in the Wild
It would likely take an entire book to detail all the decision and elements in a successful and professional ad spec; instead, it’s far easier to look at what others have done for all the technical specifics. Thankfully there are a number of companies that publicly post their digital ad specs, which is incidentally, highly recommended to simplify the communication between internal and external teams.
Digital Publishers and Advertisers that have access to a Data Management Platform (DMP) can bootstrap their own data modeling, or lookalike model capabilities with some simple index-based approaches. That is to say, if you can understand both the total population of users for every segment and for any specific segment, how many users of every other segment overlap in that target segment, you can build a fast and easily understood audience model with a little legwork. It’s not the rocket science approach of a regression model or black box algorithm, but it works, and it’s pretty easy for people without a degree in data science to execute once you figure out how to get the right data out of your system.
How to Do Lookalike Modeling Yourself
The first step to building a lookalike segment is to first define what you are trying to model, that is, what audience you want want more of. This will be your ‘target’ – for our example here, let’s consider the following audiences:
% of Total
Let’s say we’re trying to reach females. Unfortunately, we only have 20,000 we can identify, out of a total population of 100,000. Now let’s assume that our content isn’t skewed to one gender or another, and therefore there’s clearly some users in the 80,000 other users that we can expect would be female. But we need to find a signal within that group that directs us to which other audiences are likely to be female. (more…)
The most popular article on this blog is one of the very first ones I ever wrote – How Does Ad Serving Work. What I probably should have titled it though was How Does Ad Serving Work on the Web, because there are a few important differences when you’re talking about the mobile ecosystem.
Server Redirects vs. Client Redirects
For the most part, it comes down to the interaction between a client and a server – in desktop environments, the user’s browser, or the client in technical-speak, does most of the work fetching and redirecting information, which is ideal for lots of reasons. For one, redirecting the client gives each platform in the ecosystem the ability to drop or read a cookie, which helps with downstream conversion tracking, frequency measurement, and audience profiling. Secondly, it facilitates client-side tracking of key metrics like clicks and impressions for billing purposes. Client-side tracking is the preferred methodology for advertisers because it measures requests from a user instead of from a server, and is therefore a more accurate measure of what a user actually saw. This process requires more work from the browser, but that’s OK because high-speed connections and unlimited data usage is pretty much the norm these days for home and office connections.
In mobile environments though, connection speeds really matter. Many users are on slow enough connections that if the browser or app was responsible for fetching the ad the way it does on desktop connections, the user is likely to abandon the page before the ad finished loading. Because of that, you often see more of the work being done in the cloud for mobile ad serving, independent of the client. So instead of the browser calling a server, and then being redirected to another server, the browser tends to call a server, which then calls other servers, which can talk to each other through the ultra-fast fiber-optic landlines instead of the cellular network. (more…)
Certainly one of the biggest opportunities in ad tech today is integrating real time bidding (RTB) systems to core ad serving platforms such that ad serving decisions are made from a single system. This vision of a fully integrated monetization stack is known as holistic ad serving, and it’s going to be big.
Holistic ad serving consolidates what is today a fragmented marketplace, modernizes the publisher ad serving stack, and lays the groundwork for advertisers and publishes to transact guaranteed campaigns over RTB infrastructure. In other words, it provides a way for publishers to transition from a world of manual campaign implementations to accepting and trafficking campaigns programmatically without having to manage the balance between two systems.
Tactically, holistic ad serving is a seems like a basic change – instead of filling direct campaigns first and then letting the exchange try to fill whatever is left, the idea is for publishers to call to the exchange marketplace and get a bid for every single impression, thereby allowing RTB demand to compete directly with the traditionally sold campaigns with guaranteed goals. By at least getting a bid for every impression, the publisher’s ad server can understand the benefit or cost of filling an impression with a direct campaign – it has all the information. Holistic ad serving also opens the possibility, on an impression by impression basis, for an RTB campaign to trump a direct campaign. (more…)