The Display LUMAScape Explained

Ah, the LUMAscape, who in the digital marketing world doesn’t know it as an old friend at this point?

Display LUMAScape

First debuted in 2010 by the ad tech banker Terry Kawaja, the LUMAscape has been through many iterations at this point, adding companies, changing categories and noting acquisitions over the years.  From the very beginning this image was a hit with the digital marketing set as it provided a way to understand a complex industry, as well as a symbol for how difficult it is to work in a space so complex!  The LUMAscape was a great way for ad technology people to explain the growing industry within their own companies in a visual way, as well as understand how new companies were aligned and fit together. Kawaja & team’s image was also a solid way to understand what a whole lot of companies even did, so if you were say, shopping for a data management platform, you could get a quick sense who the four or five companies in the space were.  For Kawaja’s company, LUMA Partners, the LUMAscape was also a great way to show the sheer amount of fragmentation in the industry and possibilities for consolidation through acquisitions, on which his company specializes in advising.

Whatever the motivations, the LUMAscape is an iconic image in the digital marketing industry, and a must-know resource that Kawaja’s company has generously kept up to date for nearly five years now.  But the graphic itself only tells a high-level story and can oversimplify, as the LUMA Partner’s website readily admits, so I thought it could be useful to take this image down one more level and explain some of the nuances and sub-categories within each service.  This article describes what each category coves, what a lot of the companies on the LUMAscape actually do, as well as the differences between key services within specific categories.  For those that are new to the industry, I hope this post not only demystifies this graphic, but gives you a well-rounded sense of how the digital marketing industry functions, and for industry veterans who already know the basics there’s probably still a few things to learn. (more…)

Header Bidding Explained Step-by-Step

I’ve gone over what header bidding is in an earlier post and some of the key differences versus traditional tag based setups, but I’ve always strived to technical bluntness on this site as well, hence the diagram and step-by-step path below.  As a point of comparison, it could be a good idea to re-familiarize yourself with how ad serving works and the standard exchange redirect path at this time as well.  Note that header bidding is also sometimes referred to as ‘advance bidding’, ‘tagless’, or ‘pre-bid’ integrations.


How Header Bidding Works

How Header Bidding Works:

  1. User requests a website
  2. Header tag script redirects user to one or many SSPs (or DSPs, or Exchanges)
  3. User calls one or many SSPs in parallel
  4. SSPs conduct auction with DSPs and internal network demand*
  5. DSPs respond with bids*
  6. SSP determines winning bid value and returns to User
  7. User passes bid value into ad request and calls Publisher Ad Server
  8. Ad server determines final line item to serve and redirects User to Marketer Ad Server (let’s assume the ad server determines a pre-bid SSP line item for this example)
  9. User calls Marketer Ad Server
  10. Marketer Ad Server returns final creative (via CDN)
  11. User calls trackback to SSP

* It’s hard to tell if everyone or no one actually runs an auction with their header tags because everything happens quite fast relative to your standard exchange process.  My sense is that there is either some kind of estimation process vs. a real auction, or some fancy stuff happening with the SSP’s CDN, but without the product people or engineers from these companies actually telling me what happens it’s impossible for me to know.  Here’s hoping a few visit the comments section on this article.  The important point is that the SSP determines a value for the impression that the publisher can use in their ad serving decision process. How precisely that happens and if it’s better / worse than the standard auction process is an open question. (more…)

Header Bidding: Holistic Ad Serving Is Here

It’s been nearly three years since I first wrote about the concept of holistic ad serving – the idea of seamless yield management across sales channels, namely direct sold and programmatic – but in the last six months or so this idea has quietly gone from the drawing board to reality via a mechanism known in the industry as ‘header bidding’, ‘tagless’, ‘advance bidding’ or ‘pre-bid’ integrations because they rely on a piece of JavaScript in the publisher’s header to work. Header bidding is a revolutionary enhancement to the way publishers have historically integrated with their SSP partners, and has wide ranging implications for nearly every part of the RTB ecosystem. The future is now!

Header bidding integrations, or something very close to it have been common for years with retargeting networks like Criteo seeking ‘first-look’ relationships with publishers, but it’s only recently that the major sell side platforms started to integrate this way. The major difference between the retargeters and SSPs is that retargeters have all the demand within their own platform, while the SSPs and Ad Exchanges rely on an auction with external parties to fill impressions. (more…)

Does Lazy Loading Ads Solve the Viewability Problem?

What Does Lazy Loading Ads Mean?

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…)

Ad Ops Skills: Writing an Ad Spec

Ad Spec Blueprint

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.

For example, Ad Ops should understand cache-busting requirements for 3rd party technologies, and the intricacies of click tracking to minimize the chance for large discrepancies, and so team members know how to QA, and if necessary, correct problematic ads. For rich media technologies to function, publishers often have to include so-called bridge or gateway files in a local server directory which allows expanding ads to bust iframes, though these techniques may not always work for all technologies for asynchronous ad calls, or ad slots called with JavaScript instead of through an iframe. Ops has to understand where the site code can potentially interfere with successful ad executions and consider those factors as they define the ad spec.

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.

To list a few organizations in particular, The Washington Post, Yahoo!, AOL, and CBS Interactive all have comprehensive, cross-platform ad specs that are best-in-class. In addition to those companies, the IAB defines industry-wide creative guidelines that can help inform the necessary decisions to make in writing your ad spec.