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.
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.