Does this describe you?

You have done the hard part of growing an audience. You have fully functional teams to sell direct to advertisers. And you even built an in-house ad-server yourself (or duct-taped a shrink-wrapped banner ad-server) that works fine (for today). It manages your manual direct-sold deals (IOs & RFPs) reasonably well. With all of these pieces ostensibly in place, you now want to build a solid programmatic revenue strategy and execute for long-term health of your business.

The first question is, “what constitutes a solid programmatic strategy?” Let us assume you are happy with what you do on direct-sold deals; there are two things that stand-out: independence and control. You choose which advertisers you want to work with, at what rates, which users to show ads, and how many times to show ads in which geographies—all the while having full data transparency that enable you to make further optimizations. For companies passionate about user-experience, independence and control are great consideration metrics for your programmatic strategy as well.

The common myth you hear is “let’s just sign up with few SSPs and exchanges and call it a day”. Wrong! (Though it is a good start.) Signing up one/few SSPs/Exchanges/Ad-Networks and putting them behind a rotation logic is only dipping your toes into the world of programmatic. This post will guide you through and highlight few core components required in order for you to develop a robust programmatic yield strategy. Many  of which might be things you didn’t even know you needed.

First, some quick Programmatic 101: Programmatic is a term thrown around to refer to various forms of bringing in ad revenue from advertisers, vendor/partners and it also describes the style of integration with those partners to reach your audience. And, for better or worse, it is a crowded programmatic vendor ecosystem.

1. Programmatic Partner Types: DSPs, SSPs, Ad Networks
2. Other Internal Names Used: Indirect Revenue Sources, Demand Partners, Backfill Vendors etc
3. Integration Styles: OpenRTB API Standard, Vendor-specific APIs, JS tags, SDKs

Pro Tip: Always, always, always ask your partners to give you their API specifications so you can integrate them server-to-server. Adding JS and SDKs will bloat your apps. Engineers hate adding SDK/JS and (even more importantly) your users will hate it too when the additional code slows their experience.

Noe that, for the purposes of this discussion, we are leaving out automation part (do-it-yourself for advertisers) aspect of programmatic. This is achieved through Self-Serve UIs built by your team (think buying Google ads using ads.google.com) or a third party (think buying Google ads using Marin Software).

Following are technical modules that make for a robust programmatic yield/mediation system to manage your programmatic partners:

1. OpenRTB Engine: Ability to broadcast to multiple DSPs using the OpenRTB protocol that an ad opportunity exists in your site/app.
2. Server-Side Integration Engine: Many Exchanges, SSPs and Ad Networks might themselves connect with DSPs to bring ads. These partners do not use OpenRTB but instead have their own custom APIs to connect with your audience. Ability to conform to their custom specifications and making ad-calls from server side. This is the right way to integrate partners that favor Header Bidding also. The goal is evaluate all partners equally in real-time without the overhead of client side code bloat.
3. Data Aggregation Engine: Some partners don’t prove eCPM data in real-time, so you need the ability to pull it from their dashboards as frequently as possible. An overall ability to pull data via APIs and screen-scraping from every partner. If you are getting ad revenue from Facebook, Google or Twitter; you need to make them play nice (compete at same time versus getting “first look”) because perhaps their tools are biased to their ads?
4. Automated Inventory Allocation Engine: Using #3 Data from partners, building price models and trends to automatically adjust your priority; this is also known as the waterfall of which partner should be called at what point.
5. Audience Rules & Targeting Engine: A lot of partners specialize in providing ad dollars for certain set of your audience (geography, gender, interests). It is best to target those partners for that audience and reduce noise everywhere else. Also remember that your team needs precise and granular controls like you have for direct-sold deals. Examples – what if you wanted to send 1st party data to Partner A and not to Partner B? Or say you wanted to monetize only certain segments of your users (who spend less than X minutes in a month) vs everyone? Or you want to roll out a policy to show maximum of only 2 ads to users in a specific country?
6. Bidding Patterns/Price Predictions Engine: Advanced insights and recommendations based on bidding patterns/trends tied to your inventory (physical placement and at an audience level)
7. Holistic Yield Optimization / Reverse Auction Engine: This is a very important module. Ranking partners at a global level does not do any help. You need to optimize partners at an audience level. Doing this will enable you to get the best out of each of them. Ability to take price information from OpenRTB (DSPs), custom APIs (SSPs/Exchanges) and price predictions (Ad Networks) overlaid with forecasting insights to determine the best partner for every user and every ad opportunity in real-time. Modules from #3 to #6 feed into this engine.
8. A/B testing Framework: Ability to easily test new revenue partners against one-another using #5 Audience Rules Engine. Engineers hate adding tags, SDKs for every new partner. Neither the business teams should wait for engineering resources to test every new partner. It should be as simple as flipping ON/OFF switch.
9. Creative Library: Full creative assets of ads that ran on your audience with full transparency from all partners (DSPs, SSPs and Ad Networks). All stored in one place forever. You can block them or better use it as a sales intelligence tool to form direct relationships with those advertisers.
10. Cookie/User Sync Engine: ability to sync cookies/User IDs with chosen partners, so they can pay higher when they have advertisers who are looking for a specific audience that you have.
11. Quality Control Engine: Natural Language Processing and Textual Analysis to block ads and advertisers that will hurt user-experience when shown to your users.

Think about it: How did you build your audience? You did not sign-up with a few middlemen and rotate your trust, hoping they will do all the work. Instead, you owned the process. You worked with engineers, product owners and business teams to build stuff to grow your audience. You may have hired a few contractors/middlemen to help you along the way. You likely used open-source software (e.g. Redis, Django, Android, React, SugarCRM etc) wherever possible. And finally you licensed software (e.g. AWS/Data Centers, New Relic, CloudFlare, SalesForce) for areas that are important to your business but are not your core strengths.

Monetization, whether direct or programmatic is the same: You need to own your future. Either build it yourself or find a tech partner you can license it from because you need to invest the same level of energy as you did in building that hard-won audience.

Satish Polisetti is cofounder of AdsNative. He previously worked at mobile advertising startups Amobee and MdotM and received a Mayfield Fund fellowship in 2010.

Today, one of the biggest opportunities for publishers are native advertising formats–provided they roll out a native ad stack with caution. Publishers might fail to realize the true potential of native formats if they follow the path of fragmenting their monetization stack between the core ad serving platforms and real time bidding systems like they did for banners.

Centralizing the decision on which campaign/creative to be served will generate the highest revenue for publishers. However, in today’s banner ad-stack, the decision is broken into two systems: DFP/first-party ad server and network optimizers. For premium formats like native inventory, publishers should not break the above decision in the way that they did for banners because this will fail to achieve the full revenue potential offered by native advertising.

Let’s take a look at why with a little bit of history and math:

How did banner ad technology evolve for publishers?
First there were ad-servers for managing campaigns directly sold to advertisers. Publishers quickly realized they couldn’t sell 100% of their inventory so they started building relationships with networks.

Running a network isn’t rocket science (after all, it’s just media arbitrage) and, consequently, hundreds of networks popped up. It became one hell of a job to manage multiple networks until SSPs (network optimizers) came along to rescue publishers.

While publishers were optimizing their inventory, advertisers started to buy publisher’s inventory through Real Time Bidding (RTB) exchanges in addition to the old school process of cutting manual IOs and RFPs. In the process, publishers fragmented the final decision of which ad creative should be served into two completely separate silos.

Publishers would first use their own ad server to fill inventory with direct campaigns and then let the exchanges try to fill the remnant inventory. They assumed that the yield from exchanges would never exceed the yield from their direct business. If that’s always true, it makes sense to serve direct sold campaigns over indirect campaigns. Unfortunately, it’s not always true.

Where do native formats fit in?
Native inventory is premium. Assuming direct campaigns are always more lucrative could be costly and require a new ad serving model. Native formats need a modern ad stack that lays the foundation to ensure publishers make premium eCPMs irrespective whether they are selling it direct or indirect.

The ad stack should allow publishers to run direct campaigns but also auction every impression (to multiple demand sources) to compete with direct campaigns. This holistic ad serving approach optimizes a publisher’s yield by serving the right creative for every impression.

Here’s an example:

Let us assume a Publisher A has 100,000 impressions for her native formats and she can directly sell 25% of them. She wants to backfill the rest from networks & exchanges with a backfill CPM floor of $2.

1. Silo Ad-Server

The first ad-server runs through 25,000 impressions with an eCPM of $10.50 and the indirect backfill is given an opportunity to fill 75,000 impressions. The backfill exchanges monetizes at a $3.40 eCPM with 80% fill-rate.

See the revenue and breakdown below:

2. Holistic Ad-Server

But if both direct & indirect were served from the same system — a “holistic ad serving” approach — they could realize that the fill at any given price level is a direct function of how much inventory is made available, rather than the absolute impressions.

Let’s imagine the indirect backfill could monetize the publisher’s inventory at $6 CPMs. That could end up being 15% of the overall inventory they can make available. In other words, the publisher would fill more impressions at this price from indirect campaigns than direct campaigns.

Now that the system knows the eCPM from every source for every impression, it can prioritize to serve $6CPM in-direct demand than $5 direct demand.

Note: Indirect demand still has a $3.40 eCPM as in the previous case, but the publisher could realize an overall lift of 10% in this example.

Conclusion
The ecosystem around native formats is evolving very fast. It is a wonderful time to be a publisher: Advertisers want to buy direct from publishers and the number of native networks (backfill partners) are growing.  Publishers should maximize revenue by executing strategies to roll out an ad stack which helps them integrate the first party ad serving with programmatic for these premium ad experiences. And it’s going to be big!

Satish Polisetti is cofounder of AdsNative. He previously worked at mobile advertising startups Amobee and MdotM and received a Mayfield Fund fellowship in 2010.