In-house ad platforms drive revenue. Indeed, LinkedIn’s native advertising platform now drives $3 billion a year, and almost 10% of Amazon’s GMV comes from ads. It’s no surprise if you have built or want to build something similar.
But building, maintaining, and evolving these ad servers has taken those companies years and hundreds of ad engineers. Their revenue has come not from the creation of the ad product, but from diligence around uptime/scalability and constant additions of new features, whether that’s ad units, targeting capabilities, reporting options, or so on.
Take Twitter. They launched their ad platform in 2010, and even with hundreds of engineers, it took four years to release an ad unit for promoting mobile apps.
This unit has greatly contributed to their growth but was unlikely in their roadmap when they ideated their ad server. Without such a large team, they may never have launched it.
As you look to build your ad platform from scratch — or scale your homegrown solution — there are many aspects to consider about its long-term maintenance and growth.
A minimum viable product (MVP) may be something your team can design in a few months, but that doesn’t mean your ad platform will see advertiser adoption. It also doesn’t mean that it can handle a sudden influx in ad requests. Or that it will be compliant with current and future privacy laws. Or finally, that it can adapt to changing industry standards and user behaviors.
This article looks into why building an ad server yourself is just the tip of the iceberg — and why the pain points are not in its creation but instead in the maintenance and scaling it requires.
Rightfully so, your MVP will start simple. Often this involves:
The above will likely take anywhere from 2-3 months for most companies with a handful of engineers. What’s been built isn’t really an ad platform, though; it’s more of a content management system (CMS) with a little logic around delivery and reporting. But it’s a start.
With some early success and proof-of-concept revenue, your next challenge is expanding the number of advertisers beyond the early adopters.
This is where the headaches really begin.
As you scale and flesh out your ad product, there are two things to watch for: system integrity and advertiser demands.
In order to launch quickly, it’s unlikely you stress-tested your architecture. You may have built an MVP that can handle a million ad requests a day, but what happens if advertiser adoption exceeds expectations, and that number jumps to twenty million?
On face value, that’s excellent — there’s clearly pent-up demand. But if your ad infrastructure isn’t equipped to accommodate this strain, you’ll see slow ad load times, spiraling server costs, and uptime issues.
These are addressable, assuming you have the resources to address them. If you don’t, you’re looking at poor user experiences, rising backend costs, and unhappy advertisers who keep catching bugs. At that point, many publishers limit new advertisers so that they can fix this system before opening it back up.
This is an intelligent decision that, unfortunately, comes with a hefty opportunity cost.
If your ad system can handle the current volume, your next goal will be figuring out how to drive more revenue from it. And just launching an ad product doesn’t mean the money will come. Instead, advertiser adoption determines that.
As you look to woo external advertisers or vendors/listers you already work with, expect they’ll be picky. Without the features and functionality needed to capture them, your MVP will struggle to gain traction.
Common requests from advertisers will include:
Respectively, these features refer to a self-serve dashboard, conversion tracking, first-party data targeting, frequency capping, and complex search targeting — all important features that advertisers have come to expect from other ad platforms like Google’s, Amazon’s, Facebook’s, and more.
Without these features — or many others— you run the risk of pleasing only a few beta advertisers. It will be challenging to scale beyond that.
Ad latency hiccups will occur with every new feature. Frequency capping, for example, could be a request your advertisers demand. As a result, your team spends a month building a way to track how many times a user sees a specific ad. In incorporating this into decision making, however, average ad response times creep up 150ms due to the extra check involved.
Given that, do you keep the feature or accept the increased ad latency?
This isn’t to imply you can’t have both; just that latency is a byproduct of more complicated decision logic. The solution is to divert engineering time to optimizing the system and bringing down response times, an important project that comes at the cost of designing new features.
As you build out new features, you’ll find yourself internally debating what’s more important: delivering on advertiser demands or maintaining the ideal user experience (fast load times, no broken ads, etc.).
There’s no easy answer here.
If you’re building an ad platform, you’re now a new member of the ad tech ecosystem, which means it’s essential to stay up to date with industry news.
This includes understanding new digital privacy laws like the GDPR/CCPA, keeping an eye out on competitors’ ad offerings, and maintaining a pulse on the industry, like the current debates around third-party cookies, mobile identifiers, and unified IDs.
Failure to do so could result in lost opportunities, unimpressed advertisers, and even sizable fines.
Your platform, for instance, will need to be compliant with all privacy laws, such as the EU’s GDPR, California’s CCPA, Thailand’s PDPA, Brazil’s LGPD, and more. Failure to comply could result in millions of dollars in fees. Compliance isn’t turnkey, especially when the courts are often changing their mind.
Kevel, as an example, spent roughly 2,000 people-hours preparing our ad system for privacy law compliance, with continual maintenance of about 300-500 hours per year. Your platform’s level of complexity will determine the exact work needed but expect a significant amount of time dedicated to non-revenue-driving activities like compliance certification.
Not every publisher may hear this request, but as you work with larger advertisers (needed to scale your revenue), you’ll run into demands to see your SOC 1 report.
SOC 1 is effectively a third-party audit of your accounting and financial reporting. Understandably, large advertisers have every reason to question your performance data, especially if they can’t use a third-party verification tool like Moat.
You can thank companies like Facebook and Google who have spurned advertisers in the past by inflating results (see here and here).
A completed SOC 1 report mitigates this risk to advertisers. The audit ensures that you are being honest about your reporting data.
The problem is, SOC 1 certification will burden your organization. At Kevel, our SOC 1 audit accounts for about 300 people-hours and costs $25K per year. That’s time and money your product and engineering team doesn’t have, and it highlights just one of the unforeseen costs that go into scaling your ad server (we detail others here).
Ad tech is currently where finance was in the early-to-mid 2010s, when e-commerce growth had surpassed payments technology. Back then, small e-businesses had to either set up gateways with banks, whose software was outdated and difficult to code to, or use PayPal with their hidden fees and arbitrary account freezes.
Enter Stripe, whose simple APIs made it easy to integrate payments into one’s web and mobile app. Start-ups and enterprises like Amazon, Lyft, Shopify, and Salesforce quickly jumped on board.
Cut to now. While ad tech has historically focused on content and news publishers, the growth in eCommerce, social media, and utility publishers has led to an influx of non-traditional brands entering ad monetization (see: Walmart and Quora launching ad products).
Standard ad serving tools, meanwhile, don’t provide the customization or speed they need, while the alternative (homegrown solutions) are difficult to code and tough to scale.
To address this, a new industry is forming: ad APIs, which are doing to ad monetization what Stripe did to finance.
Rather than use an imperfect ad server or code it yourself from scratch, ad APIs provide an alternative: an ability to outsource the infrastructure aspects of ad serving (targeting, decisioning, and reporting) using server-side APIs, while still having full control over your user experience, data, and revenue.
Want frequency capping? Instead of a month, code it in days — without then having to worry about its impact on latency. Plus, a mature ad API solution will have built-in GDPR/privacy law compliance and SOC 1 already completed for you.
Such tools don’t erase the need for maintenance ad engineers, but they do drastically reduce the number needed. It also means your team can focus on building new features and ad units (the tasks that will drive new revenue) versus worrying about scalability, law compliance, SOC 1 compliance, and industry changes.
If your goal is to scale your ad product, a homegrown solution will only go so far with limited resources. Building or scaling with ad APIs ensures you can achieve your ad vision without the unforeseen costs and inevitable headaches.
Kevel is the market leader in ad APIs. Customers like Klarna, Ticketmaster, Yelp, OfferUp, Slickdeals, and many more have used Kevel’s APIs to build high-margin, high-scale ad platforms in a fraction of the time and cost as doing it from scratch.
Interested in learning how Kevel can help you build or scale your homegrown ad server? Let us know!
