How to ‘Fix’ Online Advertising, Part 2

In Part 1, I discussed three major problems rooted in online ad technology’s architecture. Now, possible solutions.

Neither is final, but at least we have a starting point for discussion. For those of you who read this for the “sparkling wit” of my commentary, bear with me. This is serious stuff for serious times.

Any solution must be industry-wide. It isn’t something one company working alone can achieve. Many approaches are possible. Below, two possible directions, both of which address the following:

  • Media costs are too low to support the industry. The widely accepted solution is conversion to reach-and-frequency-based media buying and selling. There’s no way to implement this today due to technical barriers.

  • Discrepancies between site-side and third-party ad servers are too high. Both proposals remove serving duplication by the publisher and third-party ad servers. Only one counts impressions.
  • Inventory control systems are too unpredictable. My proposals make this more predictable by streamlining inventory control system function and selling by audience as opposed to general volume.

Let me clarify my definitions of ad servers. I refer to an ad server representing a publisher’s inventory as a “site-side ad server” (SSAS). An ad server delivering an advertiser or agency campaign on its behalf is a “third-party ad server” (3PAS).

Some basic assumptions are made in each proposal (you may disagree):

  • Reach and frequency planning and buying are desired to increase online media’s value.

    • Media planners/buyers need tools covering reach and frequency/gross ratings points.

    • Third-party ad serving is required for multiple-publisher buys.

  • Business models are as important to the architectural changes as working technology.

  • Adopting a new architecture will be a long process but must happen within two years. A plan must be achievable in that timeframe.

Architecture Today

Current architecture separates SSASs and 3PASs. Integration issues include:

  • A 3PAS is managed by the site-side system through a redirect, but site-served ads are not. This is the root of the discrepancies between the systems.

  • Advertisers pay twice to serve ads: to the publisher and the 3PAS company.
  • There’s no mechanism for a 3PAS to request the SSAS change how the media is rotated or handled. This is required to support cross-site frequency capping (a root requirement of reach and frequency).
  • Inventory control is viewed as a linked system to site-side serving. No mechanisms support views into inventory control from the 3PAS or from media planning tools.
  • Little integration exists between all systems used in online advertising, and virtually no automation exists.

Cookies: A Major Barrier

A barrier to any workable system overhaul is HTTP cookie handling. Due to cookies’ use restrictions, a solution enabling identification of unique users between publisher and 3PAS is needed. Not a privacy issue — this is anonymous. To track and value activity of aggregate anonymous users, a mechanism is needed to recognize them when they intersect with a campaign across multiple publishers.

There are two schools of thought resolving this issue. One advocates a universal cookie carefully shared across the industry with companies agreeing to a strict privacy policy. The other calls for some kind of DNS-alias-creating mechanism. Both are complex, but it’s believed resolution is possible. The solutions below assume the cookie problem is resolved.

Solution 1: Divorce Inventory Control From Ad Serving

Change the relationship between inventory-control and ad-serving systems. The 3PAS’s nature won’t change much. It still serves its own content and the site maintains control over inventory. But hierarchy changes. In essence, the site separates inventory control from content delivery. Any ad serve is treated as a redirect, whether served by the publisher or third party. The impression is tracked at the same point for either server.

Pros:

  • Media pricing will be “purer.” Ad delivery cost is separate from media cost.

  • The advertiser can have content delivered by the SSAS or 3PAS. Paying twice for serving isn’t an issue. This reduces costs.
  • The ad server — site side or third party — remains on one level, eliminating the discrepancy issue.
  • This supports the need for the 3PAS to serve its own content to track rich media activity (particularly Flash).
  • It creates more room for innovation when a third party serves the content. 3PAS can differentiate technically from others with varied capabilities for rich media tracking or other solutions, such as automated optimization.
  • Inventory control is simplified, with a more specific focus on that part of the system without concern for ad serving.

Cons:

  • Third-party serving fees are not reduced. Savings would have to be on the media side, when the publisher didn’t serve the content.

  • Publishers must trust the 3PAS for tracking or open a pretty deep API (which many are reluctant to do) for tracking integration.
  • Advertisers must accept publisher media volume numbers (impression opportunities) as distinct from the impression number given by the ad server. A business model shift, but the fairest way for all parties to be paid an equitable fee. Billing media on page views versus ad serves is an old debate.

Walk-through:

  1. The media planning tool hooks into the publisher’s trafficking and account management system and queries available inventory. It recommends inventory to the agency or advertiser based on criteria.

  2. The media planning tool exports campaign information to the 3PAS.
  3. The 3PAS traffics the campaign to the publisher’s trafficking and account management system (a component of the SSAS).

  4. A user visits the publisher’s site through a browser. A call is made to the publisher’s server, generating an HTML page.
  5. While generating the page, the publisher’s server calls the inventory control system for an ad tag. The system selects the relevant ad tag based on available inventory, confirms the user is not subject to frequency capping, and returns that ad tag to the publisher.
  6. Depending on the architecture, a call to the ad server (SSAS or 3PAS) may occur. Most likely, this step is skipped.
  7. The page is rendered in the user’s browser, which reads the ad tag. A call is made to the ad server (SSAS or 3PAS) for the creative. Methodology (including the redirect of the user) is identical for all ad servers.

Solution 2: Third-Party Servers Stop Serving Ads

Solution two removes ad serving from the 3PAS. It turns the 3PAS into a campaign management, data collection, and cross-publisher media management system. On the surface, publishers are comfortable. Their side looks much as it does now. But most advertisers will find limitations on rich media and reporting problematic.

Pros:

  • Media pricing model stays much as it is. The publisher charges a mixed cost for ad delivery and inventory.

  • Third-party ad-serving fees drop (the majority of the charge today is for ad delivery costs).

Cons:

  • This solution requires more work and trust between publishers and 3PASs.

  • Reporting timeframes are restricted to what the publisher can support. Most use log files, meaning data will not be updated within campaigns for longer periods of time than most 3PAS customers are used to.
  • There is no way to use a 3PAS to “audit” publisher activity. The publisher supplies all impression and click data. With the broader mix of 3PASs on the market, advertisers and agencies can choose one they feel is accurate rather than rely on the accuracy of the publisher’s tracking.
  • Many innovations are reduced in effectiveness or simply not possible, including rich media tracking (which requires a 3PAS to serve the creative). It relies on publisher-side solutions, traditionally less advanced than those offered by 3PASs and rich media companies.

Walk-through:

  1. The media planning tool hooks into the publisher’s trafficking and account management system and queries available inventory. It recommends inventory to the agency or advertiser based on criteria.

  2. The media planning tool exports campaign information to the 3PAS.
  3. The 3PAS traffics the campaign to the publisher’s trafficking and account management system (a component of the SSAS).
  4. A Web user visits the publisher’s site through a browser. A call is made to the publisher’s server, generating an HTML page.
  5. While generating the page, the publisher’s server calls the inventory control system for an ad tag. The system chooses the relevant ad tag based on available inventory, confirms the user isn’t subject to frequency capping, and returns the relevant ad tag to the publisher.
  6. Depending on architecture, a call to the 3PAS may occur. Most likely, this step is skipped.
  7. The page is rendered in the user’s browser, which reads the ad tag. A call is made to the SSAS for the creative.
  8. Impression and click data passed back to the 3PAS.

These solutions were assembled in my “spare” time. I’m not a programmer or an architect. I just happen to have a good brain for how technology works and an understanding of how things are configured today. My goal is to get things moving. To be a catalyst for change. Without someone taking a stab at this, I fear nothing will happen.

Related reading

nurcin-erdogan-loeffler_wikipedia-definition-the-future_featured-image
pwc_experience-centre_hong-kong_featured-image
12919894_10154847711668475_3893080213398294388_n
kenneth_ning_emarsys_featured-image
<