ellipsis flag icon-blogicon-check icon-comments icon-email icon-error icon-facebook icon-follow-comment icon-googleicon-hamburger icon-imedia-blog icon-imediaicon-instagramicon-left-arrow icon-linked-in icon-linked icon-linkedin icon-multi-page-view icon-person icon-print icon-right-arrow icon-save icon-searchicon-share-arrow icon-single-page-view icon-tag icon-twitter icon-unfollow icon-upload icon-valid icon-video-play icon-views icon-website icon-youtubelogo-imedia-white logo-imedia logo-mediaWhite review-star thumbs_down thumbs_up

An essential guide to changing ad platforms

An essential guide to changing ad platforms Doug Wintz

Many publishers will remember 2012 and 2013 as the years they changed or significantly altered the ad platforms running their digital media business. The contributing factors are the acquisition and winding down of Solbright, new product releases by Operative, Google, and Freewheel, and the increasing consideration of applications like Fivia, OAS, OpenX, Fattail, and YieldEx. Whether you are involved in one or several of those applications, there are several common miscalculations you can and should avoid as you migrate from one platform to another.

Defining and agreeing on workflow and business rules

Swapping out order management and/or ad servers is a good reason for publishers to reexamine their workflow. Chances are it's been months or even years since the last deployment of an order management app and a new version will undoubtedly present new capabilities.

Miscalculations: Getting formal sign off from sales, finance, and other stakeholders on business rules like pricing floors, ad products, inventory rules, and reservation guidelines all take more time than you think. Anything short of a formal sign off can create scope creep, where the business rules keep changing before, during, and even after deployment. Even then, many publishers have experienced the "head nod" where everyone is in apparent agreement with business rules -- until they actually have to use them.

Solutions: Formal sign off and a walk through of order management configuration with all stakeholders well before launch so they fully understand what their workday will be like under the new business rules and workflow.

Testing ad tags

Whether you are changing ad servers or simply upgrading, changing ad tags is a major task. This involves managing development groups that need to understand the specific functional requirements -- including how ad products and key values are incorporated into the ad code. It also means devoting significant QA resources to make sure the new (or altered) tags are rendering ads correctly.

Miscalculations: Resources are not always allocated and corralled with enough lead time. Development resources need to be allocated well in advance of any live date. QA resources need to understand which ads should be rendering on which pages; they need to be supplied with a matrix of display, rich media, video, and mobile ad products for testing purposes, and then certify that the interaction between the new ad code and the pages in a development environment is correct. The propagation of new ad code needs to be complete and cover the entire site(s) in order to maintain the current levels of ad inventory that are required by sales.

Solutions: Supply your development and QA resources with explicit use cases and testing matrix's that will help serve as a formal sign off that new code is functioning correctly and ready to be moved into production. Testing ad tags and validating the ability to serve and target according to business requirements should be a prerequisite to setting up ad products in order management (see below).

Defining and loading product catalogues

If you are changing order management systems, depending on which vendor you select, you may need to redefine your catalogue of ad products. While this may currently be something that is "out of sight, out of mind," the fact that you have to represent ad products in a new system requires a lot of leg work. What is the array of ad products on your site(s) and where are they positioned on the page, player, or screen? That's a simple question, but the answer in the form of documentation is often not available. Do you target primarily on site/section, or are there layers of more granular taxonomy that need to be represented? How about the array of key values being used? Which ad packages are in the current system and how do they need to be represented to sales moving forward? All of these things, which you didn't even have to think about before, now need to be defined carefully. Once you have defined the product catalogue, you may need to configure the order management system with those products -- another task which is time intensive.

Miscalculations: Publishers often underestimate the complexity of these tasks. In addition, they may not realize that their current packages, ranging from simple roadblocks to complex ad packages, may possibly be rendered differently in their new order management system and pushed to the ad server in a way that is contrary to their current business practices.

Solutions: Focus on ad-product definition early in the process. If you are in the position of creating ad product loaders for integration with an order management system, allow two times the time you think you need to account for trial and error in configuring the product loader correctly.

End-to-end testing

Congratulations -- you've configured your new ad platform based on hard-won approvals and sign-offs from sales, operations, and technology. Let's just flip the switch and go live! Sorry. Wrong. A mandatory practice is to create an end-to-end testing matrix to validate the interaction between order management, ad serving, reporting, and billing applications.

Miscalculations: Publishers can be tempted to cut corners, relying on the well-intentioned claims of vendors that they will support all your business requirements. The issue here is that no one knows your business like you do, and while early stage workshops may surface 95 percent of all your requirements, it's the 5 percent that are not uncovered that cause the most severe issues.

Solutions: Create a physical, literal testing matrix. Think of it as a "day in the life" that will begin when your new platforms go live. Enlist representatives from each business unit to participate. Sales should understand what it will really be like to create a proposal and order. Inventory and pricing needs to be aware of the extent to which they will need to approve and manage incoming orders. Ad ops need to see how the order is represented before and after it is pushed to the ad server. Billing needs to see how data flows from order management into its financial systems.

Campaign migration

In the case where you are launching a new order management system and/or ad server, it is critical that campaign migration be transparent to your customers, as it relates to both the continuation of their campaign on your site and the accuracy of month-to-month billing. This involves a number of stakeholders in the organization, including sales (planners or account managers) and ad operations. Several decisions need to be made. How much historical data needs to be migrated? Given the delivery of any single line item before launch, how many remaining impressions need to be delivered and scheduled in the ad server? Exactly when should the migration cut-over take place -- at any time, at month end, or at quarter end?

Miscalculations: Organizations frequently leave allocation of ad trafficking resources to the last minute. Yes, it is important not to re-traffic too early, but waiting until the weekend before a Monday cut-over is not the answer either. In addition, do you know where your creatives are? If you're a publisher that has all currently running creative and the most recent versions and click through URLs stored in a neat and orderly fashion, you're in the minority. Most often, these need to be hunted down so they can be retrafficked and that too, takes time.

Solution: An orderly campaign migration plan that is actually a "project plan in the project plan." Allocate duties amongst ad operations, sales, and inventory management well in advance. And if you suspect you will need external ad trafficking resources to help with the migration, review the vendors early in the process, obtain estimates, and include that cost in your budget.

Mobile and video configurations

Even for savvy developers, understanding the language of mobile and video configurations is difficult. Keeping track of the current landscape of SDKs, mediation layers, podding features, and engagement reporting, and which capabilities carry over to iOS, Android, smart phones, and various video platforms, is daunting.

Miscalculations: Depending on which ad serving solutions are being launched, some publishers have discovered they need to deploy a device specific SDK for every mobile/tablet platform they support with their content or apps. That's a lot of development time in terms of education, preparation, testing, and launching. Other publishers have found it difficult to keep up with the ad product requirements submitted by sales -- which have actually become a moving target. In regard to competitive separation, the synchronization between video and display assets can be challenging and difficult to manage for all use cases.

Solutions: If you are an aggressive player in the mobile/video landscape, you will need an internal product specialist to handle both media formats. It's also important to document in detail those ad product requirements. What is sales selling? What are they promising to major clients? What is repeatedly requested in RFPs? The only way to prevent disconnects between what is being sold and what is being delivered in terms of capabilities like competitive separation (for example) is to document those requirements as detailed use cases. Then, communicate the capabilities as part of your ad product specifications.  

Integration with business intelligence platforms

Several publishers have recently deployed business intelligence platforms to deliver the reports required by not only ad operations, but also by senior management as well. This is most often employed as a method of aggregating data from several applications supporting ad operations. For instance, if you have a display ad server (or two), a mobile ad server, a video ad server, and an order management platform, virtually the only way to aggregate all that data is with a reporting platform. Now, you can argue that a best of breed approach that results in the need to support several applications is overly complex, but that is beside the point. The point being -- what are the most common issues associated with this approach when switching out ad platforms.

Miscalculations: Speaking from experience, the most important advice I can put out there is "don't assume." For instance, don't assume that a vendor that claims to be data driven can actually supply you with all the data you need to fulfill your business requirements. Don't assume that just because data is presented in a UI, that it is actually present in a data feed. Don't assume that data is organized efficiently when supplied by a vendor unless that feed is documented. And even then, don't assume -- period.

Solutions: Document your data feed and reporting requirements, and then map that against the vendor's demonstrated ability to supply that data. And if data is that important to you, make the delivery of that data and the format in which it is delivered a contractual obligation.

Integration with billing systems

Whether your migration involves a total replacement of your ad platform, or is a simple upgrade, the billing file you send to finance will change. It's ironic that the last link in the "quote to cash" chain is frequently the last business unit to be brought into the migration process. Don't forget, you can close a contract, you can deliver the goods, but if it's stuck in a dysfunctional billing integration, nobody collects nuttin.'

Miscalculations: The manner in which ad packages are handled often changes dramatically as part of the migration process. For instance, a roadblock that used to consist of four separate line items may now be rendered as a single line item -- which may be more efficient to traffic -- but represents a significant change in how it is handled by a legacy billing system. Publishers that apply specific mapping between billing file and Great Plains, or PeopleSoft, or Oracle can be caught by surprise at the tail end of migration with these changes.

Solutions: As a preamble to any migration, include a deep dive with your finance department. Understand the current pain points and the workarounds they have to engage in to generate an invoice. Then, work to solve for those issues at the beginning of any intended migration, not at the end.

If you work in ad operations, it's likely that you've been on the receiving end of some of these miscalculations at least once. There are far too many moving pieces in our business and in that environment that it is difficult to account for everything. However, knowing what your fellow professionals have endured and how they coped with the problems is half the battle. Understanding this not only provides you with solutions before they become issues, but may also lend some small comfort that, hey, you're not alone.

Doug Wintz is principal and founder of DMW MediaWorks.

On Twitter? Follow iMedia Connection at @iMediaTweet.

  Doug Wintz is Founder and Principal of DMW MediaWorks, a consultancy specializing in digital ad operations and technology.  Since 2004, DMW MediaWorks has helped emerging companies set up their ad operations departments and...

View full biography


to leave comments.